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 corporate ladder).

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 it.

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.

Despised 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 did.

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 Aqua.

Learning what your app is supposed to do is the answer.