[
Lists Home |
Date Index |
Thread Index
]
"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 sucked 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/
|
