Running's a pretty good time for me to mull out the day's issues, and today's topic was user interfaces. I've been doing my dangest to make sure I code the engine for my first sideline app so that it works independent of the GUI, so I've been coding the engine on my desktop and the GUI on the laptop (mainly just so that I can have a change of scenery - both with respect to the location and with what I'm working on). Eventually I'll slap 'em both together and make a release.

Of course this means I've got two sets of issues to worry about at one time, and I'm faced with getting the GUI right without even quite yet knowing how well, or even exactly how, the engine's going to work. Possibly not the best method for making sure I don't have to recode bits of each, but the point being that I am already thinking about interfaces.

UIs seem to run the gamut from VIm to iTunes. You can't use vi or VIm without having taken a while to read the directions and learn the quite esoteric commands. The learning curve is high and, much to my chagrin, it took me about 10 years from my first use of vi to decide to take the time to learn more than :q! and how to change my preferences in the app to use pico.

iTunes is quite nearly the opposite. Most users can fire iTunes up on their Mac and start using every bit of the program without looking at anything resembling a manual. Pop in a music CD and iTunes automatically changes one button from "browse" to "import" and you're ripping tracks. Sure, if you want to change the quality of the mp3 that are made or the location of your music collection you'll have to familiarize yourself with the preferences panel, but 80% of its users I'd have to imagine never need to change a setting.

Menus are a neat way to combine the two. They essentially serve as an on-demand reference system for your application. How do I save again? I think that's under File... And poof, after taking a look you recall that Ctrl-S also saves and you can either start using the keyboard shortcut or go back to the menu if you'd like or forget again. Menus also let you navigate with the mouse if you're mouse oriented, though they aren't, of course, quite as good as well-done icons.

But menus aren't exactly standardized from one app to another, much less from OS to OS. Sometimes finding the danged menu item that resizes an image, as a random example, is so tough to find you're better off using another program. Icons have their own problems, and like a door with a sign that says "Push", icons that need their use printed below them weren't very well-designed icons from square one on.

Mozilla is a mammoth program that combines the worst of all worlds. Ctrl-T to check for new mail? That's vi-level intuitivity. "But that's a menu item!" you say? Who thought to put it under "File"? Not what I'm used to for whatever reason in email clients today. You probably have your own set of expectations for certain apps, and there are so many "features" in Mozilla it's got to go against at least one of your expectations somewhere.

But the worst problem with Mozilla is its use of preferences. That's the tops of anti-intuitive. There's a file where I have to know what line to add to get pop-up ads to stop being shown? Sure, now that's an option that can be modified in the preferences, but it didn't start that way. Or how about...
user_pref("pref.browser.smartbrowsing.disable_textbox.add", false);
What the heck does that do? And if I wanted to substract an "enabled smartbrowsing textbox", how would I have guessed this is the name of the pref with which I'd do it? I'll try not to make any sweeping generalizations about open-source programmers, but this is ugly. For my vimrc file, I understand having something this esoteric. For my browser? Email client? I don't think so.

For a recent VB application at work, we actually used up half our screen real-estate to provide instructions for the application. As the app moved to different sections, the directions changed in lockstep. For our particular needs it was a good compromise, but is a bit of an extreme case for a "typical" app.

At the same time, things that try to protect you from dealing with the dreaded preferences GUI or *shudder* the preferences file can be just as bad. Ever tried to start a sentence with a lower-case letter in Microsoft Word? How about trying to type VIm? Word loves to change capitalization, and doesn't always learn when you retype the "error" three or four times. Having to dig through its preferences to turn off this sort of behavior is a maddening exercise best compared to navigating a house of mirrors. Even if you try your best guess at how an app should respond to make things easier for users, you can end up putting them in a straightjacket of unappreciated "features".

So what's the right compromise? Heck if I know. But these were today's thoughts while taking a run, thinking about how to finishing designing a GUI on my iBook.