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

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.

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.