Posted by editor
on August 1, 2003 at 10:37 AM PDT
Usability comes from understanding a problem domain and the user's needs - no API can give that to you.
Years ago, I worked at CNN
Headline News as a Writer / Associate Producer, which pretty much
meant I was an editor, except they paid me the Writer/AP salary (the
editors, in turn, were really producers, etc., up and down the
At the time, the de facto standard for newsroom computer systems
was "Basys", which wired dumb terminals to a mainframe, and let users
view directories, edit files in those directories, print, and roll
text up a teleprompter.
The commands in Basys were cryptic, and learning the keyboard took
a long time. At CNN, the numeric keypad was repurposed into a
collection of cursor-movement and text selection keys. Even if you'd
been touch-typing since age 10, it took a while to get the hang of
Then one day, they installed new Windows desktops in the newsroom,
with a new GUI Basys client (I think it was from Avid, who bought
Basys). Now the directories could be browsed in a familiar "tree"
format, text could be managed with familiar mouse gestures, and it was
in eye-pleasing colors instead of 10-year-old, burned-in dumb-terminal gray.
And we all hated it.
Threatened to quit if they didn't get rid of it.
To the software engineers, this must have been outrageous. I can
imagine them saying
Don't you see how much better this is? You can see the heirarchy
of the directories! You can copy-and-paste from other applications!
You can have many windows open for your source stories instead of
wrangling a simple emacs-style split! You can ditch the keypad!
What they didn't understand was that the crummy terminals were
crude, but once mastered, they were very, very, fast. Remember
how fast Data on Star Trek could operate the flat-panel
controls of the Enterprise? We were faster than that. Select-word,
bangbangbang, del, typetypetype, readreadread, scrolldown,
readreadread, scrollup, arewecool, yeah, save, print!
Having to manage windows and mouse around might be easier for the
novice, but it absolutely strangled the expert. A top speed with the
GUI was nowhere near the top speed with the dumb-terminals.
And this is is the important part: editing speed turns out to be
the absolute number one priority for a newsroom system. If a GUI
costs me five seconds, it might mean that I can't get a breaking story
to an anchor in time to read it.
So while the GUI was fine in and of itself, it totally failed to
meet the users' primary needs, and was quickly abandoned.
This is one thing I was thinking about when I read Philip Brittan's
weblog on usability in
Java apps . Not that I disagree with him at all; I just want to
reinforce the point that good-and-bad in a GUI doesn't necessarily
derive from the merits or deficiencies of the GUI API.
That newsroom GUI could
have been written in Swing, MFC, or Aqua and we still would have hated
it, because the underlying concept was completely wrong.
Philip makes this point when he quotes the CIO who implies that
open-source apps seem to do no usability work, and I think implies
that many Java GUI's are developed the same way.
But the comparison to Windows applications is a trap. Don't assume
that mimicking existing apps on Windows or any other platform is a
valid approach in and of itself. Here's why:
I remember a few years ago, I was at a company where a product manager
- and apparently this was his entire output for a month of work - did
a little five-page document saying how great Microsoft Outlook's GUI
was, and how that should be a model for our application.
Problem is, our application wasn't an e-mail client, it was a
networked media browser/distributor. Sure, in the broad view there
are some concepts that carry over, like seeing items (e-mails or media
clips) in some sort of broad view and then getting a detailed view
through a double-click or a paned approach. But that's after thinking
in the abstract. I think he really wanted it to look and behave as
much like Outlook as possible. Even though that didn't really make sense.
It reminded me of the novel The Fountainhead, in which the
hero, Howard Roark, is an individualist architect who understands
that form follows function, that there's a right way to build things
in order to be what they're supposed to be. However, many around him
insist on ruining his designs by making unrelated, even dangerous
additions, trying to bring in other ideas because those ideas have
worked before (and as a means of tearing down Roark's individuality).
To them, you put greek columns on a log cabin, simply because many
great buildings have greek columns.
You probably see where I'm going. A good GUI has given features
if, and only if, that's the right thing for that application. You
don't use MDI just because Office does (well, it used to), you use it
if you think that's the right way to handle having multiple documents
open. You don't do modal dialogs because they're easy, you do them
because you absolutely cannot allow anything in the app to continue
without getting a response from the user.
In one recent monitoring app, I ditched the simple JTable approach
of our prototype in favor of a list with multi-line cell renderers,
even though it wasn't easy to code. I got the idea from the download
managers of the OmniWeb and Safari browsers, which showed me why the
table approach of IE's download manager sucks so much. Like them, I
didn't need table columns to vertically line-up the things I was
displaying, and using custom list cells, anchored with a colored icon on
the left that showed the item's "priority", allowed me to use fonts
and size to make the most important fields more readable at a glance,
instead of getting buried like they did in the table. Plus, the
layout could ensure that the media names didn't get cut off like they
did in the table. Did I do this because I like OmniWeb and Safari
better than IE? No, I did it because the multi-line list approach
made more sense for what I was doing than the table approach
Knowing the right way to do a GUI comes from knowing
what the app is supposed to do and how it will be used. Without that
knowledge, the GUI is doomed.
Maybe you can know it up-front, maybe
you'll find out through prototyping and feedback (something that
Extreme Programming does well), but you have to own the problem
domain if your GUI is going to make any sense at all... or be
defensible when someone tells you it has to look like Outlook,
or use tabs, or have a slide-out "drawer" like all the cool Mac OS X
apps do now.
So Swing isn't the answer, and neither is SWT. Or MFC. Or
Learning what your app is supposed to do is the answer.