[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: markup, UI (Re: Attribute Order)
"Simon St.Laurent" wrote: <snip/> > Agreed. Programmer education on UI means teaching them about UI, and > not about APIs. Programmer education for markup means teaching them > about markup, and not about APIs. Good markup tends to emerge from > those cases where the product is large enough for the development team > to include people whose job is specifically markup design and testing. > In most other cases (and even in large products where emphasis isn't > given to markup design), the markup is a disaster. Programming and UI design are also rather different skillsets, though. I don't think it is reasonable to expect that anyone who is a competent programmer can also be a competent UI designer. Some people are just good at certain things and not at others. I used to work as a Mac/Unix developer within an MIS organization. The UI always fell to the programmer as just another programming task, and we had a lot of UIs that [expletive deleted] as a result. The few that proved themselves skilled at such tasks quickly started getting drafted into projects to clean up the UI. I built one UI on a project, and from then on always found myself put in the role of back-end server integration guy on every project. I thought it was a decent UI, but apparently some others felt differently. (I don't mind, though. I like doing the integration stuff.) Even when just focusing on technical tasks, though, I think there are different skillsets. Data modeling was usually a big part of those projects (and was typically treated with more rigor than the UI design), and we found that some programmers were good at data modeling and some weren't. So teams had relatively specialized roles, and we balanced the teams with people with complimentary skills (ideally). I think markup design fits in with this. Organizations need to understand the need for a defined role for the markup designer and treat it with the same seriousness as most professional organizations have come to treat data modeling. But I think the focus of certain influential tools vendors of pushing tools that simply treat XML as a serialization format for objects is redirecting focus to some extent and delaying this realization. On the other hand, if there were more and better tools for dealing with schemas in useful ways other than just validation, that might direct some focus back to modeling. The XSD Eclipse project [1] looks kind of intriguing, though I've only taken a cursory look, so far. When developers have tools that leverage a schema to actually help them implement an application rather than a situation where writing a schema is just another task that needs to be done, I think you'll see a lot more interest in modeling. [1] http://www.eclipse.org/xsd/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|