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)
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.
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.
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
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
Interesting article, or set of opinions.
The major stumbling block I see in free desktop software is it's inability to innovate much further than win32 or MacOs, but there's a reason for that.
It's called familiarity - to innovate too far, would be to alienate users, so it has to be a gradual process.
KDE and Gnome have improved enormously, but they are still lacking the cohesive feel that win32 and MacOS desktops have. IOW, things like keyboard shortcuts, copy and pasting text between applications etc. are virtually universal between all different applications.
The question should be asked, are features like transparent window borders, animated icons, slide-out-menus really neccessary for a productive desktop ?
Shouldn't more development time be put into creating an efficient, robust and stable work-horse desktop and less time on the fancy bits ?
There's another aspect to this - the UI 'hobbyist' or 'tinkerer' - the very people who support and participate in the development of free UI's sometimes seem to loose the most important idea behind a good UI - the end user. Much time is spent on the idea that 'total customisation' should be the end goal - is this flawed thinking ?
How many people really want to customise thier UI to the 9th degree ? - surely the majority of people simply want a plain and effective UI that helps there productivity ?
More customisation = more code = more bugs = slower UI
A slashdotting - you get the stick first and then the carrot !
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
Me
The guys at work had a chuckle at the iarchitect.com User Interface Hall of Shame. If companies like Microsoft weren't featured it wouldn't be half the fun!
Everyone enjoys a scape goat; I noticed that a lot of university professors also reference this site in their online GUI course notes!
Anyone know of any other good "chambers of GUI horrors".
Torturé par la fenêtre.
consider coffee a lubricant that helps one penetrate the coding zone
Why? Because I use Windows NT all day long at work, so that's what I'm used to. Like the qwerty keyboard, 'doze UI may not be the best, but is what most people are most familiar with. This is not a silly attempt to generate flames. I think there is some merit to just conceding the "look and feel" battle to M$ and concentrating on areas where there is a competitive advantage, like security, or just developing quality free software, with no privacy-transgressing EULAs.
Of course, tinkering with window managers and desktop setups is still a fun pastime. :)
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.
Didn't the Gnome Usability study done by Sun cover a lot of the shortcomings of the current GUI? It showed that the GUI was indeed created by geeks for geeks.
The report can be found here.
Okay, I was thinking about this offline and I wanted to add that there's a perfect opportunity here for an OSS startup:
Give it a cool name like "SimpleFace" or something non-frightening like that (i.e. real words).
Then this company would do three things (complying to KISS):
1) Create a set of rules and guidelines for GUI applications along the lines of Apple's Human Interface guidelines. Include all of the most recent theories and practice. Publish this online. Use versions so that people can tell what's the latest draft, etc.
2) Certify apps that comply to the SimpleFace rules. Open Source Software gets certified for free. Certify non-free software for a fee. They get to put a SimpleFace smile icon on their web pages or boxes.
3) Create a set of classes - both online and corporate training - based on the guidelines. Some for free, others for a fee.
Once momentum started building on something like this, corporations would be more willing to switch to OSS software if they knew that training was going to be minimized because the apps that use the SimpleFace guidelines would be easy to use for those already familiar with other SimpleFace apps.
SimpleFace could also actively participate in the other projects as a GUI testing center. Whereas the rest of the OSS crowd might not pay attention to usability and design issues, SimpleFace would be there to help out. Providing feedback, suggestions, or even app dev for those interested.
Why am I thinking "startup" and not just "movement" or "organization?" because I think that something like this is needed now before the OSS movement loses any more momentum in the UI race from companies like M$ and Apple. (Under the theory that a startup could move faster than a committee.) How many Unix heads do YOU know that are switching to Mac OSX because their GUI is awesome? Lots.
-Russ
Me
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.
The article lists these issues as why Free Software UI sucks.
Hello? Where is the #1 reason?
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.
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.
[
The real problem is age and how "applications" are taught in schools, the enterprise and classes.
Schools teach children to use applications specifically. No one sits down and explains to them the concept of a file and actions that apply to a file (open, save, save as, print...) or editing (copy, cut, paste, etc.. )
If the process of educating people in the realm of computer use included a more abstract view of computers and how they work, the average joe schmo wouldn't need to "relearn" every time a new UI design came out, they'd be able to reason through it.
We moved our 8 year old daughter and 14 year old son from Windows to SuSE and Gnome, respectively. With the exception of not knowing the names of applications that do what she wants, she can get around just fine because we've taught her the basics, without being specific to an OS. She knows how to manipulate files and open applications, she understands that web browsers and can use IE, Netscape, opera or Galeon with equal ease.
This ease of adaptation is partially due to commonlality of UI implementation across applications and platforms, and partially due to their education @ home, which focuses on exploration and understanding the computer rather than a specific application.
Of course, if schools/enterprises did that, M$ would lose its edge because users would no longer be frightened to death when presented with a word processing app other than Word, or a browser other than IE.
I don't have a solution, but I certainly admire the problem.
IMO the UI of KDE is getting too complex (I know it better than Gnome). So the task is to clean it up, give useable defaults and simplify it. Especially the KDE-menu and the KontrolCenter should be cleaned up.
But what should be removed? What is a good default? Let's ask the user. KDE could collect information on what is used and how the prefs are set, and send it back to the developers.
I think noone would have a problem with that as long as: The info is anonymous, only sent with explicit consent, and it is stated clearly what information is sent.