Slashdot Mirror
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.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
In a previous posting, I sum up what I think are the main reasons why Linux won't make it to the desktop just yet. Wrapping up my arguments nicely, the article was scored down as a troll.
-- Rolf Lindgren, cand.psychol
Develop a good UI and let experts in the area choose it and you will find that there are few people who disagree that it's the best. UI design doesn't come down to personal preference, it is based on common traits that almost all people share. People only have one locus of attention, it is easier to use an interface that makes the options visible in a clear manner rather than making you guess at it, the time taken to hit a target is directly related to the distance distance to the object and the size of the object, etc, etc. It's all been documented, go do some reading on it.
Maybe libglade is what you are looking for. Glade generates an XML description of the UI which is used to generate the UI code. Libglade reads the XML file at runtime to generate the UI instead, so you can tweak that XML file without having to touch your code.
/Janne
Trust the Computer. The Computer is your friend.
Since mpt's (Matthew Thomas) website seems to be down, I'm mirroring his first 9 points here:
There are another 5 points that he added today, but weren't in the google cache.
If you're interested in his writings, please check his site after it comes back up from being slashdotted, as he clarifies some points that upset some people.
"Why Free Software usability tends to suck"
I've been having a discussion with someone from IBM about whether it's ever possible for for Free Software to have a nice human interface.
In theory, I think it is possible. But in practice, the vast majority of open-source projects are also volunteer projects; and it seems that the use of volunteers to drive development inevitably leads the interface design to suck. The reasons are many and varied, and maybe one day I'll turn this into a long and heavily-referenced essay. But in the meantime, here's a summary.
1. Dedicated volunteer interface designers appear to be much rarer than their paid counterparts -- and where they do exist, they tend to be less experienced (like yours truly).
2. First corollary: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.
3. Second corollary: Even when dedicated interface designers are present, they are not heeded as much as they would be in professional projects, precisely because they're dedicated designers and don't have patches to implement their suggestions.
4. Many hackers assume that whatever Microsoft or Apple do is good design, when this is frequently not the case. In imitating the designs of these companies, volunteer projects repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.
5. Volunteers hack on stuff which they are interested in, which usually means stuff which they are going to use themselves. Because they are hackers, they are power users, so the interface design ends up too complicated for most people to use.
6. The converse also applies. Many of the little details which improve the interface -- like focusing the appropriate control when a window is opened, or fine-tuning error messages so that they are both helpful and grammatical -- are not exciting or satisfying to work on, so they get fixed slowly (if at all).
7. As in a professional project, in a volunteer project there will be times when the contributors disagree on a design issue. Where contributors are paid to work on something, they have an incentive to carry on even if they disagree with the design. Where volunteers are involved, however, it's much more likely that the project maintainer will agree to add a user preference for the issue in question, in return for the continued efforts of that contributor. The number, obscurity, and triviality of such preferences ends up confusing ordinary users immensely, while everyone is penalized by the resulting bloat and reduced thoroughness of testing.
8. For the same reason -- lack of monetary payment -- many contributors to a volunteer project want to be rewarded with their own fifteen pixels of fame in the interface. This often manifests itself in checkboxes or menu items for features which should be invisible.
9. The practice of releasing early, releasing often frequently causes severe damage to the interface. When a feature is incomplete, buggy, or slow, people get used to the incompleteness, or introduce preferences to cope with the bugginess or slowness. Then when the feature is finished, people complain about the completeness or try to retain the preferences. Similarly, when something has an inefficient design, people get used to the inefficiency, and complain when it becomes efficient. As a result, more user preferences get added, making the interface worse.
Where a project is heavily influenced by a company under commercial pressure to ship a usable product (such as Netscape, Eazel, or Ximian), you'd expect the interface to improve as a result. But in such projects so far, it would appear that the opposite has happened. I think this is partly because the companies involved aren't large enough to employ designers who are both smart and stubborn, and partly because the business model of the companies involves maximizing the revenue (rather than the user satisfaction) gained from the interface.