5 Oct 2007
Ten Ways to Make More Humane Open Source Software
A lot of bandwidth has been wasted arguing over the lack of usability in open-source software/free software (henceforth “OSS”). The debate continues at this moment on blogs, forums, and Slashdot comment threads. Some people say that bad usability is endemic to the entire OSS world, while others say that OSS usability is great but that the real problem is the closed-minded users who expect every program to clone Microsoft. Some people contend that UI problems are temporary growing pains, while others say that the OSS development model systematically produces bad UI. Some people even argue that the GPL indirectly rewards software that’s difficult to use! (For the record, I disagree.)
Meanwhile, as these arguments swirl, I’ve been quietly relying on OSS to get my work done. As a professional developer, I spend my most of my time interacting with three programs, all of which are free and open source. I chose each out of dozens of alternatives precisely because I think each of them has the most humane interface in its category. Some OSS isn’t just usable, it’s more humane than the closed-source alternatives. One the other-hand, there’s plenty of OSS which is downright painful.
In an effort to understand usability in the OSS world, I’ve researched the stories behind my favorite — and least favorite — OSS programs. I’ve found a fascinating variety of personalities, design philosophies, and project organizations. Although I’ve only scratched the surface, there are already themes that come up again and again. Because everybody loves top-ten lists, I’ve distilled my observations into a top-ten list of OSS “do”s and “don’t”s.
- Get a Benevolent Dictator
Someone who has a vision for the UI. Someone who can and will say “no” to features that don’t fit the vision.
- Make the Program Usable In Its Default State
Don’t rely on configurable behavior. It adds complexity, solves little, and most users will never touch it anyway. Usable default behavior is required.
- Design Around Tasks
Figure out the tasks that people want to do with your software. Make those tasks as easy as possible. Kill any feature that gets in the way.
- Write a Plug-In Architecture
It’s the only good solution I’ve seen to the dilemma of providing a complete feature set without bloating the application.
- User Testing, User Testing, User Testing!!
Without user testing, you are designing by guesswork and superstition.
- Develop Without A Vision
“When someone suggests another feature, we’ll find a place to cram it in!”
- Join the Clone Wars
“Closed-source program X is popular. Let’s just duplicate its interface!”
- Leave the UI Design Up To The End User
“I’m not sure how that should work. I’ll make it a check box on the preferences screen.”
- Make the Interface a Thin Veneer over the Underlying Implementation
“But it’s got a GUI now! That makes it user-friendly, right?”
- Treat UI Design as Babysitting Idiots
“They should all quit whining and read the manual already.”
The Good Stuff
Earlier I mentioned the three OSS programs that I use because of their superior interfaces. This triumvirate of usability consists of:
Emacs, Firefox, and Python do very different things, have very different styles of interfaces, and came to exist in different ways. Yet, their history has some striking parallels.
Firefox: Why I Love Its Interface
(Note to Opera fans: Yes, I know Opera is better than Firefox, had all of Firefox’s features first, and can cure cancer. But it’s not OSS so it’s outside the scope of this article.)
Tabs. Integrated Google search bar. Incremental search within a page. Plugin architecture. Ability to undo closed tabs. Pop-up windows disabled by default. Short menus. Small preferences screen that doesn’t require clicking on “Apply”. Convenient address bar autocomplete. Responsiveness. Clean interface. All of these things are important, but none of them is new or unique to Firefox. It’s not a breakthrough, it’s just a refinement of everything that has come before, an elimination of numerous petty annoyances.
I can put Firefox on my relatives’ computers to save them from the security flaws in IE, and I never have to explain how to use it. Never! Firefox is entirely usable for basic web-browsing purposes immediately upon installation. There’s an enormous range of extensions, themes and so on for those who desire more features or customization of the UI, but if you don’t want to tinker with it, you don’t have to.
Firefox: How did it get to be so good?
Before writing this article, I didn’t know who to thank for Firefox’s interface, so I did some research. The central people behind the Firefox project were Blake Ross, Dave Hyatt, Ben Goodger, and Asa Dotzler. I read their blogs, and discovered that the simplicity and focus of the Firefox interface were no accident. Before the Firefox project had a name, it had a manifesto, and it has remained practically unchanged since then.
“From the very beginning of the Mozilla and Firefox projects, one of the questions we’ve always asked ourselves is “what’s painful about the web” and then we went about finding ways to take away that pain. Tabbed browsing, integrated web search, pop-up blocking, session restore, software update, all of these features, and many more, were designed to make painful, difficult, or just plain sucky things a little bit less painful, difficult or sucky.”
Blake Ross, in a post entitled “The Firefox Religion”, says:
“Firefox has humble origins in a product that — if everything went as planned — was designed to be invisible to the person using it. I remember sitting on IRC with Dave, Ben and Asa painstakingly debating feature after feature, button after button, pixel after pixel, always trying to answer the same basic question: does this help mom use the web? If the answer was no, the next question was: does this help mom’s teenage son use the web? If the answer was still no, the feature was either excised entirely or (occasionally) relegated to config file access only.”
This group got started on Firefox because they were frustrated by working on Firefox’s predecessor, the Mozilla browser. Here’s Ben Goodger, way back in 2003 before the Firefox project began, in a blog post called, “Why The Mozilla Browser Sucks”:
“Despite best efforts, today Mozilla’s collection of preferences remains one of the largest, most unwieldy and ultimately least useful of any in a browsing application… Really what is necessary is either a small group of developers with a well understood and focused vision, or a set of UI specs up front.”
Here’s Ben Goodger again, writing in “Inside Firefox”, in a 2006 post entitled, “Where did Firefox come from?”
“There was no organized vision for the [Mozilla] browser UI, and the ability to make changes was too widely distributed: anyone could make any change or addition to the UI as long as they had two other reviews. There was no clear plan for improving the resulting clutter. There was no vision… In practice, these statements resulted in effectively locking everyone but the Firefox team out of the Firefox source code. We railed against the inefficiencies of past UIs. We were unnecessarily harsh, and polarized opinions.”
Mozilla, the project which accepted every user-interface feature, became a bloated mess. In order to make the browser useful, the team had to simplify — and to simplify, they had to say “no” to anything that didn’t fit the vision, even at the cost of angering other developers. OSS development can’t be about handing out gold stars for trying hard. They were willing to make sacrifices in order to simplify the UI. The result was the first web browser in a decade to take a serious bite out of Internet Explorer’s market share.
What’s more, the Firefox UI continues to improve. In version 1.5, closing the front tab took you to the next tab to the left, which was arbitrary and momentarily disorienting. In version 2.0, closing the front tab takes you to the tab that you were using most recently before that, which is more often what you really want. Once again, Inside Firefox explains why this decision was made:
“Here at Google, we did some usability studies on the tabbed browsing feature. Our usability analyst designed a study to see how well people responded to tabs and how easily they were able to switch between them and close them… [We] found people were surprised by the z-index used by the virtual stack establed [sic] by the tabbed browser. “
I’d be willing to bet that most OSS projects do not go so far as to perform studies designed by usability analysts. I’d bet further that most UIs would be greatly improved if they did so.
Now you understand where my list of five “do”s come from. Firefox had a benevolent oligarchy: Ross, Goodger, Hyatt, and Dotzler. It was designed around a single task: “Does this help Mom use the web?” It is usable in its default settings but can be extended through its plugin architecture. And the UI was fine-tuned according to the results of user testing. Now let’s take a look at my other favorite OSS projects and see how many of these factors they had in common.
Emacs: Why I Love Its Interface
Neal Stephenson, in his essay “In the Beginning was the Command Line”, calls Richard Stallman’s Emacs the “thermonuclear text editor”. If Firefox is an evolution — a refinement of the best of the web browsers that came before it — Emacs is a living fossil: a relic from six years after the dawn of time (1976). It has an interface resembling no other program created since. It’s focused entirely on the task of editing plain text documents: no fonts, bold, underline, or other formatting. Because most of what I write is Python code, C code, or HTML, that’s fine by me.
Emacs was one of the first text editors to be WYSIWYG, full-screen, and real-time. We take these things for granted now, but in 1976 the idea that you to enter the letter “a” into the document by typing the “a” key, without first having to enter an “insertion command”, was a major innovation. Emacs is extremely efficient because it allows me to reposition my cursor, search through a document, move to other documents, cut, copy, and paste chunks of text, and so on, all without ever having to take my fingers off the home row of the keyboard. There’s a menu bar, but I’ve never used it.
Finally, Emacs is powerful. If I want to, I can use Emacs to write new Emacs commands, save them, assign them to key-bindings, and start using them in my editing, without even having to restart Emacs. I can also change nearly any aspect of Emacs’ behavior by writing the appropriate LISP statements into a .emacs file. I rarely have to, though, because Emacs is highly usable in its default configuration, and already has commands for nearly everything you could imagine.
This power and efficiency comes at the price of learnability. When I got started with Emacs, I simply had to buckle down and spend a day memorizing the keystrokes for the common commands. Only some have good mnemonics meaning that a lot must be learned by rote. For this reason, I would hesitate to recommend Emacs to normal humans. Normal humans have better things to do than memorize command keystrokes. Once I was over the initial hump of learning, I found that the commands work so consistently that now I never have to think about them: Emacs respects my habituation.
Emacs: How Did It Get to Be So Good?
Stallman’s 1981 paper to the ACM conference on Text Processing contains some fascinating stories about the development of Emacs. Of particular relevance to modern-day software development is the following:
“The development of EMACS followed a path that most authorities would say is a direct route to disaster…
EMACS could not have been reached by a process of careful design, because such processes arrive only at goals which are visible at the outset, and whose desirability is established on the bottom line at the outset. Neither I nor anyone else visualized an extensible editor until I had made one, nor appreciated its value until he had experienced it. EMACS exists because I felt free to make individually useful small improvements on a path whose end was not in sight. While there was no overall goal, each small change had a specific purpose in terms of improving the text editor in general use, and each step had to be individually well designed and reliable. This helped to keep things on the right track. Research projects with no users tend to improve the state of the art of writing research projects, rather than the state of the art of writing usable system tools. The individual commands of EMACS benefited from a stage of unregulated experimentation also. When the display processor and the capability for extension were created, many users began to write extensions, which developed into the complete editing environments of which EMACS is the most recent.”
This might give the impression that “unregulated experimentation” was all that was necessary to create Emacs. However, in Sam William’s biography of Stallman, “Free as in Freedom“, we find out that wasn’t the case:
Two years after the explosion, the rate of innovation began to exhibit dangerous side effects. The explosive growth had provided an exciting validation of the collaborative hacker approach, but it had also led to over-complexity. “We had a Tower of Babel effect,” says Guy Steele. The effect threatened to kill the spirit that had created it, Steele says. Hackers had designed ITS to facilitate programmers’ ability to share knowledge and improve each other’s work. That meant being able to sit down at another programmer’s desk, open up a programmer’s work and make comments and modifications directly within the software. “Sometimes the easiest way to show somebody how to program or debug something was simply to sit down at the terminal and do it for them,” explains Steele. The macro feature, after its second year, began to foil this capability. In their eagerness to embrace the new full-screen capabilities, hackers had customized their versions of TECO to the point where a hacker sitting down at another hacker’s terminal usually had to spend the first hour just figuring out what macro commands did what.
The chapter goes on to describe how Stallman and Steele solved the “Tower of Babel effect”: They worked together to identify the most useful macro commands from all of the different macro packages floating around, and forged them into a single unified interface:
In the course of developing a standard system of macro commands, Stallman and Steele had to traverse a political tightrope. In creating a standard program, Stallman was in clear violation of the fundamental hacker tenet-”promote decentralization.” He was also threatening to hobble the very flexibility that had fueled TECO’s explosive innovation in the first place. “On the one hand, we were trying to make a uniform command set again; on the other hand, we wanted to keep it open ended, because the programmability was important,” recalls Steele.
This forms a striking parallel to what the Firefox team did to simplify the Mozilla.
Emacs had a Benevolent Dictator: Stallman (aided by Steele). It is focused on the single task of editing plain text for developers. It’s usable in its default state and has a plug-in architecture in the form of LISP extensions. The only thing that’s missing from this picture is user testing. I’m inclined to go easy on the Emacs team, since after all, in 1976 computers weren’t yet in common use by non-technical people. Nobody would have imagined that Emacs would have users who were not also developers. So instead of user testing, its interface was refined by experimentation and by the process of hackers “eating their own dogfood”. The resulting interface is great in power, efficiency, and consistency, but poor in learnability. Perhaps if they had known how to do proper user testing back then, Emacs would be learnable as well.
Python: Why I Love Its Interface
Wait a minute — should Python even be on the list? It’s a programming language, so it may seem out of place on this list of user applications. Programming languages are interfaces just as GUIs and command-lines are. Programming language are a way of giving instructions to a computer, just like a GUI or a command-line. Programming language design is user-interface design.
A few months ago, I wrote an article explaining why I think Python is an excellent interface for beginners and experts alike. Python gives you a clean, straightforward, elegant way to transform your thoughts into executable code, with a minimum of formalities, jargon, or “gotchas”. Other languages do this too, but Python beats them, in my opinion, because of its consistency. In Perl, there’s More Than One Way To Do It; in Python, there’s exactly one way. Python is as close as it comes to a one-to-one mapping between thoughts and code. For this reason, Python code tends to be much more readable than Perl code.
Python fans like to say that Python comes with “Batteries Included”. When you install Python, it comes with a standard library that handles most of the things that a typical program needs to be able to do, and importing things from libraries is a snap. There’s an interactive interpreter that makes experimenting with the language easy and fun, and a program doesn’t need any artificial cruftaround it in order to function. For example, the Python program that prints “Hello, World!” looks like this:
print “Hello, World!”
All these features make it extremely easy for novice programmers to get started with Python, without getting in the way of experienced developers.
Python: How Did It Get to Be So Good?
I had the good fortune to meet Guido von Rossum at the 2007 Euro Python conference in Lithuania and was very impressed by the depth and clarity of his thought, as well as his willingness to accept or reject ideas on their pure merits regardless of who thought of them. He was wearing a name tag that said simply, “BDFL“: “Benevolent Dictator for Life”. As such, Guido has the authority to reject proposed additions to Python which would dilute the quality of the language.
Guido’s philosophy is that if there are two ways to do something, we should pick the better way and eliminate everything else. It’s the application of the principle of monotony to language design. It’s so important to Python that Guido’s plans for Python 3000 include breaking backwards compatibility to remove redundant constructs — for example, reduce(). Favoring simplicity over features is not an easy path: Guido mentioned that his email in-box is full of letters from people begging him to keep reduce(), despite its proven redundancy.
Part of Python’s vision is readability. From an interview with Guido in Linux Journal:
“That is one of the things I’ve always had as part of my philosophy: it’s much more important that you can read someone else’s code than how fast you can produce your own code… That is actually one of the big differences between the Perl philosophy and the Python philosophy. Perl gives you lots of different ways of doing things which makes it much harder for the reader.”
Jef Raskin defined a “Humane” interface as an interface that is “responsive to human needs and considerate of human frailties”. Python’s philosophy, which values readable source code, is an example of how software can be considerate of human frailties. (The “frailty” in this case is that source code is hard for humans to read.)
A good way to learn more about the design philosophy behind Python is the article “The Zen of Python”. I especially like the idea that “Special cases aren’t special enough to break the rules”, and that “Flat is better than nested” — two ideas that apply to many UI design problems outside of language design.
Python’s Benevolent Dictator is Guido. Python is based around a focused design vision that keeps out extraneous language features and syntax. Python’s equivalent of a plugin architecture, the “import” system, is among the easiest to understand of any language I’ve used. Finally, it’s easy to get started with Python because it’s usable in its default state — the “batteries are included“. Only usability testing is missing from this picture (it’s hard to say what exactly usability testing would mean in the case of a programming language.)
The Bad Stuff
Now I turn from the good examples to the bad examples. In order to have concrete examples, I’m going to have to single out certain well-known OSS apps for interface criticism. My goal is not to trash anyone’s favorite program. I think these apps are amazing achievements, I have respect for the developers, and I want them to continue to succeed and improve. The best way for them to improve is by putting more emphasis on designing for usability.
Mistake 1: Develop Without A Vision
The easiest way to make a bad interface in your OSS project is to ignore it. Bad interfaces are the natural state of software: You’ll get one unless you work hard to avoid it.
The difference between the Mozilla and Firefox was that Mozilla was the result of developers contributing every web-browser feature they could think of. It only started to become humane once the Firefox team applied a unifying principle — “Does this help Mom surf the web?” — and pared away features that didn’t fit. It’s not enough to duplicate what has come before; even in an established category, a product still needs a unifying design, based on a clear vision of what users need to accomplish.
Example (don’t shoot me): Open Office. I am impressed by its power, feature-completeness, and its compatibility with Microsoft’s proprietary file formats. But the first time I tried to use it, I was intimidated by its interface: the rows of cryptic icons, the proliferation of preferences screens, and the enormous range of menu choices. Each check-box on one of the preference screens is a hidden mode that alters the program’s behavior. I wasn’t sure which subset of the program’s commands might be relevant to my task, or how to discover them. I couldn’t figure out how to turn off the on-by-default features that were getting in my way.
Curious about how OpenOffice got to be the way it is, I took some time to browse around the information available for its contributors. That UI design is not a top priority for the project can be seen on their how to contribute page. They ask for help with programming, marketing, QA, translation, and graphics, but there is no category on the page for either UI design or usability testing. Their page on User Interface Specs deals only with skin-deep things like the appearance of icons and making sure widgets look like OS-native widgets. Nothing there shows concern for how new users can learn to use the software, about how the software can make users’ tasks easier to accomplish, or even a clear idea of what those tasks might be. I can see no unifying principle on the order of Firefox’s “does this help Mom surf the web?”.
I don’t know what’s going on inside the heads of the OpenOffice developers, but I suspect the culture around the project doesn’t emphasize UI design. This clearly affects the end product. OpenOffice.org may be powerful and full-featured, but those features are difficult to discover and hard to use.
Mistake 2: Join the Clone Wars
OpenOffice.org is a free replacement for Microsoft Office. GIMP is a free replacement for Adobe Photoshop. Many high-profile OSS apps get started because there’s a need for a free version of some popular closed-source app. You might think that if you’re writing one of these, your UI design has already been done for you. You might think you can just copy the basic design of the closed-source app, make a few improvements, and be done. But you’d be wrong.
I’ve already described the frustration I felt upon my first encounter with the OpenOffice interface.
“Stop whining”, you might say. “OpenOffice isn’t any worse that Microsoft Office, just different. Make an effort to learn it, and you’ll find that it’s just as good.”
I’m sure it is, but that’s exactly the point. OpenOffice is not any worse than Microsoft Office. But Microsoft isn’t a very good target to shoot for. All of my complaints about OpenOffice apply to Microsoft Office too. People use it because they have to, not because its interface is humane or pleasant. Open-source could do so much better than Microsoft at producing humane interfaces. But we can’t get there by duplicating Microsoft’s crummy designs.
Chasing after the GUI of a closed-source program is a thankless task anyway. Out of all the new users who try your software for the first time, some are familiar with the proprietary equivalent and some aren’t. A habitual Photoshop user has habits formed from years of using Photoshop. GIMP looks just similar enough that the Photoshop user is going to try to use some keyboard shortcut or other trick that he knows, and it’s going to fail because GIMP works differently, and the user is going to get annoyed at GIMP. Ironically, the closer GIMP gets to Photoshop, the more Photoshop users will expect it behave identically, and the more frustrated they will be at the small remaining differences.
Meanwhile, users who (like me) have never used Photoshop, and who come to GIMP without expectations, wonder why it’s so complicated. What do the icons mean in all of these floating panels? What’s the difference between a “selection” and a “path”? I suspect that some of these things might be features added to satisfy the Photoshop fans, but they don’t mean anything to me. I just want to take a doodle that I scanned in, erase some stray lines, add a caption, shrink it, and save it as a .jpg file for use on my website. I don’t know how to do this, and the GIMP UI doesn’t give me any clues.
Trying to duplicate the GUI of your closed-source equivalent won’t satisfy users of that other program and it won’t help newbies like me. It’s a fool’s errand.
If you want to know how to take over market share from Microsoft Word, look at Google Docs. It’s not trying to be a free clone of Word. Instead it offers a simple, unified, streamlined UI (all the essential features, none of the cruft) along with a compelling feature that Word can’t match: the fact that your coworkers can read and edit the latest version of your document from any computer with a net connection.
Mistake 3: Leave the UI Design Up To The End User
To quote the KDE Manifesto:
“KDE puts the user in control of the look and feel of the desktop. KDE provides a wide variety of theming possibilities so that users can create an environment that is most comfortable for them.”
The “kitchen sink” approach to UI design comes from noble motivations. There’s an idea that the best UI is the one the user is already familiar with — a good idea, as far as it goes. But in real life, users come from many different backgrounds. How can you please them all? Let each user recreate his or her preferred, familiar interface. Choices are good, right? If the user can customize exactly how the interface behaves, then it should be an ideal interface for everyone. Right?
Another attraction of the “kitchen sink” approach is that it neatly avoids arguments about UI design. If a project doesn’t have a Benevolent Dictator in charge of the UI, such arguments can be hard to resolve. If the developers can’t agree about whether behavior A or behavior B is better, the project may be paralyzed. A compromise seems to offer a way out: We’ll just add a check box on the preferences screen so the user can choose between behavior A and behavior B. Problem solved — or is it?
In reality, too much customization can make an interface harder to use.
Back when I first installed Linux on my work laptop, I used KDE (the K Desktop Environment), because that’s what came with the distro I had. I’m sure that if I got all the settings just right, I can make KDE into a duplicate of my Mac. But wait — is that what I want to do? After all, some things about the Mac annoy me. Maybe I can make KDE into something better than my Mac. All I had to do was try out every possible combination of custom settings long enough to get a feel for it, then decide whether each option makes the interface better or worse.
I didn’t get any work done for a whole week because I kept tweaking my KDE settings. And I still hadn’t learned how to use KDE effectively or efficiently. How could I learn it, when its behavior was constantly changing?
Frustrated, I switched away from KDE. I wanted something simpler, I thought. Usually, all I need is a bare-bones window manager, since I mostly just use Emacs, Firefox, and Python. So I installed fvwm. As it turned out, I spent just as much time customizing fvwm as I did customizing KDE, because its default behavior wasn’t very nice, and it had plenty of customization options of its own. I remember fiddling with one option that made window focus follow mouse cursor position, so background windows would pop up even if I didn’t click on them. I saw both good points and bad points of this, so I kept going back and forth, trying to make up my mind, and of course this meant that I couldn’t get used to either behavior.
So, the first problem with customizability is that users don’t always know what they want. I didn’t! This was before I worked for Humanized and before I had any training in interface design. Some users might think they know what they want, but actually create a bad interface through customization just because it’s what they’re used to. The second problem is that even if users do know what they want, they still have an interface they have to learn before they can get started: They have to learn the interface customization interface! The third problem is that it’s very difficult to learn a moving target. And finally, there’s the “Tower of Babel effect” that Stallman and friends discovered in the development of Emacs — if every installation works differently, it’s hard for users to help each other.
The number one reason why people want to reconfigure the interface is because the default behavior is not usable. The sign of a good design is that most people never feel any need to change the settings. As long as the defaults are good, then people can sit down, learn the default behavior, and start getting work done right away, instead of wasting two weeks tweaking their interface like I did.
Creating the right set of default behaviors — consistent, learnable, and efficient — requires hard choices. Making these choices is the responsibility of the interface designers. The buck should not be passed to the users.
Mistake 4: Make the Interface a Thin Veneer over the Underlying Implementation
Many well-meaning OSS developers assume that they can turn a command-line utility into something “user-friendly ” simply by putting a GUI front-end on it. An example can be found in the excellent article, Why GNOME Hackers Should Care About Usability, by Seth Nickell. The program is called GDiskFree — a graphical front-end to a command-line program that tells how much disk space is in use. Somebody went to the trouble of writing code to display the fraction of disk space used as a speedometer-like dial, but created a completely misleading display by forgetting to label which side of the dial is “used” and which side is “free”. Ironically, the command-line utility was more usable.
When the interface is a thin veneer over the underlying implementation — as in a web form which simply mirrors the underlying database tables — the user is forced to learn the implementation details of the software in order to use it. Eric S. Raymond ran into exactly this problem when trying to use CUPS, the Common Unix Printing System. He wrote a classic rant about it, called The Luxury of Ignorance: An Open-Source Horror Story. It is required reading for anybody who works with interfaces.
In order for the nice, user-friendly autoconfiguration stuff to work, you have to first edit an /etc file. On a different machine than the one you’re trying to set up. You have to read the comments in configuration file to know that you need to do this in the first place… This kind of crap is exactly why Linux has had such trouble gaining traction among nontechnical users — and it becomes less forgivable, not more, when it’s surrounded by a boatload of GUI cotton candy that adds complexity without actually delivering friendliness to the user.
Eric’s conclusion is that an interface should allow users “the precious luxury of ignorance”. Users shouldn’t need to know the difference between a JetDirect print queue and a CUPS print queue in order to print documents, because that is an implementation detail. Software that requires such knowledge is fundamentally unusable, no matter whether the interface is command-line, GUI, web-app, or telepathic.
Mistake 5: Treat UI Design as Babysitting Idiots
Meet “Brock Hacksworth”, an OSS Developer. (Resemblance to any real persons, living or dead, is strictly coincidental.) Brock is working on a software project called ZIYASP (”ZIYASP Is Yet Another Software Project”). Brock is a brilliant developer with lots of good technical ideas. But he has no respect for anyone not intimately familiar with the internal workings of Linux. His attitude is easy to spot because when someone posts a to a forum saying “We should make our interface easier to use”, Brock responds like this:
“People complain about our interface just because it’s not exactly like that horrible Micro$oft program that they’ve been brainwashed into liking! Making something ‘easy to use’ means making a dumbed-down GUI for idiots who refuse to read a manual. All these whiners should either RTFM and learn how to use the command line, or they should shut up and go away.”
Brock is making three mistakes. First, he’s assuming that “improving the UI” is code for “make the UI more like Microsoft’s”. Second, he’s assuming that UI improvements are something that only novice users benefit from. Third, he’s assuming that non-technical users are dumb.
Non-technical users are not idiots. They’re doctors, physicists, writers, and other smart people who have important things to do. They don’t have the time or the inclination to learn the implementation details of your software. When Brock insists that they should, he is greatly overestimating the importance of his own software in the lives of his users.
User errors are a sign that the interface is inhumane, not that the users are dumb. To dismiss these errors as signs of user stupidity is to ignore the very information that should be telling you how to improve the design. “The status quo is good enough” is not an attitude that has ever lead to progress.
UI improvements are not just good for newbies. “Power users” can still benefit from improvements to the efficiency and consistency of a UI. Besides, even a stereotypical “power user” like Eric S. Raymond is still a newbie when it comes to unfamiliar software like CUPS. Quoting Why GNOME Hackers Should Care About Usability again:
I am convinced that GNOME is not the epitomy[sic] of a perfect advanced user’s / hacker’s desktop environment. We like the flexibility, but there are many times that the GNOME environment is awkward, and even some ways in which it is extremely inflexible. The Usability Project is trying to concentrate on issues that will make it a better engineer’s desktop, because we believe that in most cases improvements made for the hacker community will benefit everyone. Everyone saves when a needlessly cluttered interface is straightened out, or a much used feature is made more accessible. Everyone saves when the menu system is navigable, or icons are clearly recognizable. Everyone saves when they can expect pressing the “Enter” key to have a consistent effect in all dialogues…
“Improvements made for the hacker community will benefit everyone”. Smart words! Remember, even the beloved Unix command line was a user-interface innovation at one time. If Brock had been around back then, he would have argued against interactive shells. He would have said, “they should quit whining and just learn to use eighty-column punch cards!”
If you made it this far, congratulations, and thanks for reading. If you disagree with my individual points, that’s fine, but I hope I’ve at least given you something to think about.
I didn’t talk much about the last of my five “Do”s: User testing. All of the other “Do”s and “Don’t”s, all of the other design principles and interface ideas, are all just theory. The scientific method says that theories must be mercilessly tested against reality through experiment. User testing is that experiment. Like a scientific experiment, it’s non-trivial to set up and run a good user test. It needs to be carefully designed to minimize uncontrolled variables and observer bias. “How to do user testing” deserves to be the subject of its own series of articles.
For now, I’ll just give this warning: using your own software (or “eating your own dogfood”), as most OSS projects do, is necessary but not sufficient. The program’s own developers are too familiar with the program’s workings to be good judges of how easy the interface is to learn. Unless you get some newbies to use your program and carefully observe what trips them up, you run the risk of making a program like Emacs — powerful and flexible, but hard to learn.
I am hopeful for the future of usability in open source. (I’m not the only one. I highly recommend reading the article The Rise of Interface Elegance in Open Source Software, by Steven Garrity.) OSS has proven that it can deliver stable, powerful operating systems, superior server-side software (the LAMP stack), excellent programming languages, and popular web browsers. The last arena where OSS has yet to gain widespread acceptance is user-facing desktop environments and applications. This is the arena where good UI design is the most important and also the most difficult to do well. But with projects like the GNOME desktop environment and the Ubuntu Linux distribution putting more and more emphasis on designing for usability, it may not be long before I can finally recommend Linux desktops to my non-technical friends and relations without reservations.
This is not a conclusion, but a starting point for discussion. I’ve oversimplified things in my quest for common threads. I’m very interested to hear your thoughts on this topic, especially if you have first-hand experience! Have you worked on open-source software projects before? What approach to UI design did your project take? What’s your opinion of the resulting UI? What “Do”s or “Don’t”s would you add to my list? Which ones would you take away?
by Jono DiCarlo