User Interfaces in Free Software

Havoc Pennington wrote a piece on creating good user interfaces, with special attention toward GNOME 2. See also the advogato thread.

Comments

Worth reading

[stew77]

Now, that is finally a good article on OSS UIs. In a lot of places, UIs are misunderstood as fancy graphics shell with lots of features and options. Unfortunately, this is the direction I see KDE running.

A lot of people do not understand how themes and options do decrease the usability of the UI. If you are able to improve the UI significantly by changing a few options or applying a skin, then there was something wrong with the whole thing in the first place. People should not waste their energy on themeing engines or messy options dialogs (my favourite horror is the KDE control center) but focus on one UI style and make that the best. Rather one perfect UI than a dozen so-so ones.

These posts highlight the problem

[saphena]

The attitude of free software nerds towards useability is often the defining limitation of the spread of free software.

The fact that it's free should not mean that you should have to be a nerd to use it. Good useability is probably more important than correct functionality.

User Interface Design principle

[prankster]

To quote Bertrand Meyer from his monumental book Object Oriented Software Construction:

Good user interface designers follow a more prudent policy. They make as limited assumptions about their users as they can. When you design an interactive system, you may expect that users are members of the human race and that they can read, move a mouse, click a button, and type (slowly): not much more. If the software addresses a specialized area, you may perhaps assume that your users are familier with its basic concepts. But even that is risky.

Which lead to the following design principle:

User Interface Design principle
Do not pretend that you know the user; you don't

My Rules

[rbeattie]

As obvious as these sound, here are my rules for a good user interface on the work I do, whether it's a web page or a GUI app:

1) Keep It Simple Stupid
2) Think Like a User (the dumber the user, the better the UI)
3) Make it LOOK better than it WORKS

The last rule is true because if the app looks like crap, no one will be happy, but if it looks GREAT and works so-so people (users, your boss) will be excited and give you more time to get the bugs worked out. This is my main problem with someone like Jakob Nielson's whiny biatching... the app has to be simple, but it's got to have good design too. Colors, buttons, subtle eye-candy, well balanced spaces, etc. Usability is key, but design is always first.

Anyways, many of the people who work on open source software seem like the people who CAN'T STAND USERS. And by users, I mean the stupid, stupid people who might use their software. It seems pretty weird, but it's true... Maybe a little less antipathy for the newbies would go a long way to helping OSS GUI design.

-Russ

Re:My Rules

[TheAJofOZ]

the generally snobby 'RTFM, dumbass' attitude that is ingrained in many OSS programmers.

Every time you hear someone tell a user to 'RTFM', note the question down as an area of your app that you think is good but probably needs to have a UI redesign. The more the question is asked the more it needs a UI redesign.

Re:Copying the Microsoft/MacOS route ?

[Anonymous Brave Guy]

Much time is spent on the idea that 'total customisation' should be the end goal - is this flawed thinking ?

Yes.

The goal should be the exact opposite: the have a system so intuitive and powerful that customising it is entirely unnecessary. Of course, you'll never reach that goal, but it should always be the target.

Your post was right on the mark.

Hello? "Know Your User"?

[Speare]

The article lists these issues as why Free Software UI sucks.

• Not enough software designers to get the work done.
• Too many cooks spoil the code's architecture.
• Free software doesn't innovate, just copies.
• Volunteers only want to do cool stuff.
• Volunteers don't do boring details.
• Maintainers cave in and add misguided features or code rather than endure flamewars.
• People want their own features to point at.
• Workarounds are introduced during the devel process and never removed.

Hello? Where is the #1 reason?

• FREE SOFTWARE DESIGNERS DON'T UNDERSTAND THEIR USERS' GOALS.

Sure, developers write things for themselves. Developers write things for their co-workers. But do developers of Free Software really go out and research the goals of their users?

In looking at Linux user interfaces, I see that most tools merely tie some toolkit strings onto the underlying code so that it can be manipulated. The current thinking seems to be that if the underlying driver can do something, expose that ability directly on the command line or in a preferences dialog box.

A great case-in-point is cd-burning software. Type (cdrecord --help). The typical GUI wrapper is just the Gtk equivalent of (cdrecord --help). A massive soup of options with little help for people who don't know what a leadin is, don't care what a TOC is, don't understand how the lovers Romeo and Joliet got into CD-burning, and don't understand whether they want to fixate the disc or not.

Instead, turn it over.

• Who are the intended users?
• What are their goals?
• How would they like to get their tasks done?

Make some archetypical example users of your application. Nate the newbie. Seth the secretary. Judy the junior admin. Devin the developer. Whoever it is that needs your help to accomplish their goals, get to know these people.

A useful CD burning tool doesn't need to expose everything the driver can do. Add music files here. Add data files or folders here. Might you want to add more files at a later date? Burn the disc.

In Alan Cooper's words, "don't make the user feel stupid."

A user interface needs to start with the user, and proceed to the interface.