[
Lists Home |
Date Index |
Thread Index
]
At 11:06 AM -0400 6/22/03, Simon St.Laurent wrote:
>UI work was a strange and alien concept for most programmers, who kept
>it as simple (and often cryptic) as possible. Over time, toolkits
>emerged to let programmers create user interfaces more easily, though
>the results weren't always pleasant for users. Over time, UI work has
>shifted from "make it easy for programmers" to "make sure it's easy for
>the users".
I don't buy this at all. Yes, the story you tell happened, but not
for the reasons you cite, and without any significant implications
for XML work.
User interfaces were atrocious despite the toolkits because
programmers didn't know squat about user interface design. When the
toolkit sucked it was because the people who wrote the toolkit didn't
know enough about writing user interfaces. It had nothing to do with
a trade-off between making the toolkit easy for users or easy for
programmers. In fact, the opposite is true. Toolkits designed by
people who actually understand human-computer interaction are easy
for users AND easy for programmers. The classic example here is Apple
and the Mac Toolbox.
In many cases, however, the interfaces still suck and the programmers
still don't know they're doing something wrong. This has nothing to
do with the APIs, and everything to do with programmer education and
skills. Today on Windows and occasionally Linux there are decent user
interfaces in those few cases where the product is large enough for
the development team to include people whose job is specifically user
interface design and testing. On most other products, the UIs are a
disaster.
Macintosh programs to this day are still easier to use than Windows
and Unix programs because Apple has spent a great deal of effort
teaching its developer community the right way to do things. It's
virtually impossible to learn how to draw a menu bar on the Macintosh
without simultaneously learning what should be in the menu bar and
where. On Windows and Linux, I daily encounter programs that screw up
very basic concerns like what belongs in the file menu and which menu
items have which menu shortcuts.
Maybe there is a lesson for XML here: a developer who understands XML
will design both APIs and XML vocabularies that are easy for authors
and consumers. A developer who does not understand XML will design a
confusing mess that annoys everybody. The experts will still be able
to use the confusing mess to make decent software (just like UI
experts can create usable software on Windows). The non-experts will
be able to make a confusing mess using even the best API. What's
needed is both a good API and good education about how to use XML.
Neither alone is sufficient.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Processing XML with Java (Addison-Wesley, 2002)
http://www.cafeconleche.org/books/xmljava
http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA
|
