Free software and good user interfaces

What is "Good UI"?

As far as I can tell from user posts on mailing lists and magazine/webzine reviews, to your average technically-inclined Internet resident a good UI means you have a lot of features, or alternatively that you have a lot of snazzy graphics, or alternatively that your UI is just like one that the commentator has used in the past.

I don't have any genius definition of "good UI"; I'm not a UI expert. But it clearly doesn't mean snazzy graphics or featuritis. In the end when I think good UI I think of MacOS classic: clean, simple, consistent, productive. You focus on your work or play and the GUI isn't in the way. OS X adds the cool graphics too, but those aren't the part that makes it a good UI, just the part that makes it fun.

Another element of good UI is attention to all the little details: good error dialogs, setting up keyboard navigation, dealing with relayout when a window gets resized, accessibility, internationalization. People don't usually know how to evaluate these aspects of a UI, unless they're experienced UI designers or GUI programmers.

I suppose I have a Cliff's notes approach to good UI and the real UI designers will laugh, but ah well. It's a decent heuristic. ;-)

So anyhow, when I talk about a good UI that's a vague definition of what I mean.

The Question of Preferences

The most-often-mentioned example of bad free software UI is "too many preferences." This is pretty much my pet peeve; I was inspired to write a whole window manager on the premise that current window managers suffer from preferences overload.

A traditional free software application is configurable so that it has the union of all features anyone's ever seen in any equivalent application on any other historical platform. Or even configurable to be the union of all applications that anyone's ever seen on any historical platform (Emacs *cough*).

Does this hurt anything? Yes it does. It turns out that preferences have a cost. Of course, some preferences also have important benefits - and can be crucial interface features. But each one has a price, and you have to carefully consider its value. Many users and developers don't understand this, and end up with a lot of cost and little value for their preferences dollar.

[...]

So how do you decide which preferences to have?

On hearing that preferences have a cost, some people get upset that we're going to remove every preference, or that their favorite one is gone, or whatever.

Step back for a minute and think about the preferences problem.

For any program, there are literally an infinite number of possible preferences. Each one has a cost. A program with infinite preferences is therefore infinitely bad. But clearly some preferences are genuinely useful and important. So the UI developer's job is to choose the useful subset of possible preferences.

An argument that "preferences are good" or "preferences are bad" is clearly unproductive. Only an argument that draws a line between when a preference should exist, and when it should not, is a meaningful argument that impacts real-world developer decisions.

The traditional, de facto free software line between when a preference should exist and when it shouldn't is "a preference should exist if someone implements it or asks for it." No one is going to seriously defend this one though. At least, no one who's maintained an application and seen the sheer number of non-overlapping feature/preference requests you typically receive can take this one seriously.

Just as Linus rejects most kernel patches these days - but probably took more of them back in the Linux 0.1 era - as free software matures, more preferences will be rejected.

So how is the decision made? It's a judgment call. I try to go through some questions like these:

• Ask questions to find out what's really bugging someone who requests a preference. What is the annoyance or inefficiency that prompted them to ask?
• Can said annoyance be made to go away for all users without requiring a preference? If so, just do that. You may have to think about the big picture of the UI to figure out how to make it Just Work.
• Is the annoyance or inefficiency really significant, or did it cost them 1 second doing something that users do once per week on average? If it's just some trivial thing, then the extra feature or preference probably costs more than it's worth, even if you can't make things Just Work.
• Does any other OS have this feature or preference? I'm all for innovation, but if no one else is doing something, you should think it through twice to be sure there isn't a reason they aren't doing it. If you're appropriately humble you'll probably find that a lot of thought and user testing has gone into the currently popular platforms.

The main point is to set limits. Figure you have some fixed number of slots for preferences; is the preference in question worth "spending" one of those slots? Once spent it's hard to free a slot up again. Keep in mind that preferences have a cost, and demand that each preference have some real value.

Why all this obsession with preferences anyway?

I find that if you're hard-core disciplined about having good defaults that Just Work instead of lazily adding preferences, that naturally leads the overall UI in the right direction. Issues come up via bugzilla or mailing lists or user testing, and you fix them in some way other than adding a preference, and this means you have to think about the right UI and the right way to fix problems.

[...]