This is an abridgment I made of the superb articleFreesoftware and good user interfaces byHavoc Pennington.       –Jcid

Free software and good user interfaces

What is “Good UI”?

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

I don’t have any genius definition of “good UI”; I’m not a UIexpert. But it clearly doesn’t mean snazzy graphics or featuritis. Inthe end when I think good UI I think of MacOS classic: clean, simple,consistent, productive. You focus on your work or play and the GUIisn’t in the way. OS X adds the cool graphics too, but those aren’tthe 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 withrelayout when a window gets resized, accessibility,internationalization. People don’t usually know how to evaluate theseaspects of a UI, unless they’re experienced UI designers or GUIprogrammers.

I suppose I have a Cliff’snotes 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 ofwhat I mean.

The Question of Preferences

The most-often-mentioned example of bad free software UI is “toomany preferences.” This is pretty much my pet peeve; I was inspired towrite a whole window manager on the premise that current windowmanagers suffer from preferences overload.

A traditional free software application is configurable so that ithas the union of all features anyone’s ever seen in any equivalentapplication on any other historical platform. Or even configurable tobe the union of all applications that anyone’s ever seen on anyhistorical platform (Emacs *cough*).

Does this hurt anything? Yes it does. It turns out that preferenceshave a cost. Of course, some preferences also have importantbenefits – and can be crucial interface features. But each one has aprice, and you have to carefully consider its value. Many users anddevelopers don’t understand this, and end up with a lot of cost andlittle 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 thatwe’re going to remove every preference, or that their favorite one isgone, or whatever.

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

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

An argument that “preferences are good” or “preferences are bad” isclearly unproductive. Only an argument that draws a line between whena preference should exist, and when it should not, is a meaningfulargument that impacts real-world developer decisions.

The traditional, de facto free software line between when apreference should exist and when it shouldn’t is “a preference shouldexist if someone implements it or asks for it.” No one is going toseriously defend this one though. At least, no one who’s maintained anapplication and seen the sheer number of non-overlappingfeature/preference requests you typically receive can take this oneseriously.

Just as Linus rejects most kernel patches these days – but probablytook more of them back in the Linux 0.1 era – as free softwarematures, more preferences will be rejected.

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

  • Ask questions to find out what’s really bugging someone whorequests a preference. What is the annoyance or inefficiency thatprompted them to ask?
  • Can said annoyance be made to go away for all users withoutrequiring a preference? If so, just do that. You may have to thinkabout the big picture of the UI to figure out how to make it JustWork.
  • Is the annoyance or inefficiency really significant, or did itcost them 1 second doing something that users do once per week onaverage? If it’s just some trivial thing, then the extra feature orpreference 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 forinnovation, but if no one else is doing something, you should think itthrough twice to be sure there isn’t a reason they aren’t doingit. If you’re appropriately humble you’ll probably find that a lot ofthought and user testing has gone into the currently popularplatforms.

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

Why all this obsession with preferences anyway?

I find that if you’re hard-core disciplined about having gooddefaults that Just Work instead of lazily adding preferences, thatnaturally leads the overall UI in the right direction. Issues come upvia bugzilla or mailing lists or user testing, and you fix them insome way other than adding a preference, and this means you have tothink about the right UI and the right way to fix problems.

[…]

Havoc Pennington