[
Lists Home |
Date Index |
Thread Index
]
elharo@metalab.unc.edu (Elliotte Rusty Harold) writes:
>>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.
I disagree utterly, which I doubt is surprising, but lets run through
some parallels in your argument.
>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.
Most markup today sucks because programmers don't know squat about
markup design. Fortunately, markup design arrived at about the same
time as the first GUIs and had a longer lead time before falling into
the hands of the programmers, so there's already been a good deal of
discussion on quality practice, but it's not pretty.
As for the Mac Toolbox, you can still write lousy interfaces with it.
I've done so, though fortunately the evidence has never been made
public. :) (I've done lousy interfaces in HyperCard, too.)
>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.
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.
>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.
It's harder to find a single company whose markup designs are exemplary,
though there are certainly consulting firms whose records demonstrate
that it's possible, given the kind of priority which Apple gave UI
design on the Macintosh.
>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.
But the notion of a "good API for XML" depends heavily on your
understanding of XML. I don't think we yet have the Macintosh Toolbox
(which wasn't that pleasant an API by the time I reached it in 1992) for
XML, but neither do I think most programmers care enough about the
markup to realize they need such a thing - much as they didn't realize
they needed such a thing before the ubiquity of GUIs forced them to
learn.
I'd like to see markup design treated with at least the same respect as
GUI design. In the absence of a strong champion - there's no Apple for
XML - it's likely to take a lot longer. Instead of competition with a
leader, the driver will probably be frustration, but hopefully we'll get
there anyway.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
