Ten Ways to Make More Humane Open Source Software

Commentary Software Development

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.

The List

Do

1. 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.
2. 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.
3. 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.
4. 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.
5. User Testing, User Testing, User Testing!!
   Without user testing, you are designing by guesswork and superstition.

Do Not

1. Develop Without A Vision
   “When someone suggests another feature, we’ll find a place to cram it in!”
2. Join the Clone Wars
   “Closed-source program X is popular. Let’s just duplicate its interface!”
3. 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.”
4. Make the Interface a Thin Veneer over the Underlying Implementation
   “But it’s got a GUI now! That makes it user-friendly, right?”
5. 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:

1. Firefox
2. Emacs
3. Python

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.

Asa Dotzler says:

“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!”

Conclusion

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?

Couldn’t agree more, except that I shudder at the thought of emacs. But let’s not start that flamewar all over again… :P

Excellent piece, Jono.

I don’t know if I agree with everything, but I think your arguments are valid. It makes me want to get involved in helping OOo with their UI design, since I have such high hopes for it.

Canonical has made great leaps in the Linux Desktop usability, but there’s still quite a ways to go. Let’s hope they don’t slow down their momentum.

Great read! Thanks.

Thanks for a great article. Your articles on UI are really valuable to me as a web developer. I get as much or more out of them as those from A List Apart.

What I really want to see is a spreadsheet program that intuitively persuades you to store your data intelligently. The functionality of VLOOKUP() should be intrinsic to using the program, not one of the harder functions to discover how to use. Isn’t limiting redundant information good for everyone, not just people who design databases? I’ve seen too many rows of identical — or more importantly, slightly non-identical — information, that the foreign key was invented to replace. Everybody who deals with information should effortlessly be able to use good data design, not just the SQL-savvy.
I was so disappointed when I started using OpenOffice and found the spreadsheet program eerily cloned nearly every quirk of Excel I had already learned to work around. I’m convinced that a good spreadsheet program could help the economy, judging from how much time I’ve personally seen wasted on Excel.

Maybe it exists, does anyone know what it is?

In opposing the “leave it all up to configuration” idea, you are missing the intended audience.

KDE will always come pre-configured with any distro installed, for example. One who builds KDE from source and configures it from scratch wants that degree of freedom and the staggering number of options.

An end user can just leave it alone in the state it was distributed.

Postfix, as another example, just needs the concept of “leave it up to configuration” to provide it’s benefit.

Software doesn’t need to, and in some cases must not, have preoccupations about it’s intended way of use. That may or may not be the objective of an extension to it.

Problem with Firefox UI is that they did rather often re-change the layout in the preferences dialogue.

This is not unique to Firefox. Gimp did it too.

I dont really recall Photoshop doing it, but since I do not like surprises, why are these changes forced upon the users? :(

I agree that default options are important, but I *hate* if there are changes which make my life (at least until I adapt) harder than it used to be …

I really wished somebody with your vision was put in charge of OpenOffice development.

Unfortunately UI design really seems to be an afterthought, and even obvious and non-intrusive small improvements take years in OpenOffice.

Great article. I particularly agree with the suggestion that improvements in UI for “power users” tend to be good for everyone, and vice-versa. Firefox is a great example of this principle, as it is loved by self-proclaimed “power-users”, yet we can still delight in installing it for our parents.

“When someone suggests another feature, we’ll find a place to cram it in!”

Maybe ask Bryce Harrington how he makes Inkscape work, then..? Because they have a very liberal policy of incorporating contributions.

Something to think about, because it clearly works for them. I’d look at their whole philosophy as a whole, rather than “how can I cram this into the one UI development process that will work..” ..!

I think Jono sidestepped an interesting question in his re-telling of his KDE experience: Why did he feel the need to play with those settings?

Fact of the matter is that most KDE users don’t spend a lot of time playing with those settings, and that most OSVs find that flexibility a huge boon.

But what made Jono feel compelled to spend a week (or whatever it really was) tinker with things at the expense of his productivity? One might suggest that Jono lacks the ability to regulate his own behaviour to his own detriment. That could be … but it might not be the answer either.

Perhaps the answer is that the defaults, which do very dramatically depending on which OS you use KDE on, were fundamentally unsatisfactory and lacking in demonstrating a clear set of goals.

Personally, I’d bet it’s a combination of both of those issues.

Jono does link to Humanized’s own third rule in that bit which talks about not providing configurability …. when they can. I think this is interesting in that the “when you can” gets more and more difficult when your audience gets more and more general.

So one might write software for a specific audience only and avoid that. Is general audience software actually possible then?

Open questions, perhaps. Then again, 100s of millions get along just fine with software designed in ways that Jono here dissents against. Interesting, that.

I’m highly sceptical of the benevolent dictator approach as well. It’s a similar conversation between dictatorship and democracy: one is efficient and clear but prone to error due to limited decision making capacity, the other is innefficient and and must be nearly constantly guided to maintain vision but is remarkably robust in the long run. We’ve rejected dictators in governance, but not in things like large software design? An important connection, beyond obvious questions of sustainability, is that software is more and more a part of the social fabric of many modern societies.

There are many points I agree on in this article, however I think there are many of the usual shortcut answers provided that are hardly useful and even detrimental in nature.

In the specific case of KDE, I think the project certainly did lack a directed vision … 5 years ago. Thankfully things can change; and it hasn’t required a dictator, benevolent or otherwise.

Jono, thanks or writing on the subject. :) It inspired me to write some responses:

===
“#1 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.”
—
I disagree. It’s not nessasary for their to be such a person. The important thing is that their is a vision and that it’s clear. People make errors, they also die. Their ideas and vision will not die.

===
“#2 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.”
—
I agree, but each user is different and the interface will thus be usable to some and not others. Trying to nail down a specific interface that works well for the large majority of people will water the interface down. It’s more important to allow the software to be usable for a community. The community will likely be your own community.

===
“#4 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.”
—
Not only a plug-in architecture, but a way for people to change, and possibly redistribute different configurations of the software easily. Gnu/Linux Fedora 7 has made a way for people to create custom distributions.

===
“#5 User Testing, User Testing, User Testing!!, Without user testing, you are designing by guesswork and superstition.” As well as, “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.”
—
Real world testing is the best because it too complex of a situation to think about every user of the software, and the environments of the software. As you said in reference to Emacs, “So instead of user testing, its interface was refined by experimentation and by the process of hackers “eating their own dogfood”.” The key thing here is that the user’s were aware of their freedom, and fully capable of making modifications. This isn’t so much different than software that is used by people that don’t develop. If their aware of their freedom, they can hire people to improve the program, create a different branch of the software, or contribute ideas to the developers of the software. A great example of user’s who are not developers contributing to the development of their software is the current GIMP user interface brainstorm at: http://gimp-brainstorm.blogspot.com/. On an aside note: I would like to see a Emacs that was easily learnable, but I’m sure I can get the documentation and learn it, since there are good rewards.

===
“Open source software” & OSS”
—
Free software is a political movement that is not only about producing software that’s source code is ‘open’, but it’s vision is a free society & free software. The term OSS gives too much emphasis to the source code being available, and not enough emphasis to freedom. You can use any term that you want, but by calling it free software it means that the user’s freedom is the grand vision; having the source code available is one part of that, but not the entire vision.

There are many different free software licenses out there to choose from. The strongest, and most popular free software license is the GNU General Public license. The MIT and BSD are two other’s that are fairly popular, but are also much weaker in supporting a free society, and free software. Both MIT and BSD-modified are compatible with the GNU General Public License so they can contribute towards the vision of a free society/software, but their weakness is that they also support a non-free one. MacOSX is based on the BSD operating system, and is not free software, as it’s roots lie in. Firefox is tri-licensed under the MPL, the GPL, and the LGPL. Emacs is licensed under the GPL, but was was originally licensed under the Emacs GPL. which is a decedent of the Gnu GPL. Python uses the Python License, which has been recently been made compatible with the GNU GPL. More about free software licenses and their relationship with the GNU GPL: http://www.fsf.org/licensing/licenses/index_html#GNUGPL

===
DON’T: #3 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.”
—
I disagree. I am a KDE user and love the fact that I can customize my interface. What I would love to be able to do is to distribute my customizations, with other people like myself so they can benefit too. That I have not figure out how to do. Being able to customize the interface is important, and being able to share those customization with others is probably even more important for a project to succeed in many communities. Each person will likely have some different needs, and will probably want to rearrange things their own way that is optimized for the workflow, or hell, even just for a specific project. 100% customization is essential, as well as being able to share yours with others, that may not know what they want yet, like your experience with KDE.

===
“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.
—
In this situation communities of people would form around standard customizations to help each other, like languages.

===
“The sign of a good design is that most people never feel any need to change the settings.”
—
Yes of course, but there can be little things such as just the arrangement of menu’s and icons that people will always feel comfortable, and want to do.

===
“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.”
—
The user should be able to have control of it, if and when they come to the realization that they would like it to be different, otherwise they will HATE it.

===
“ZIYASP (”ZIYASP Is Yet Another Software Project”)”
—
GNU (Gnu’s not unix”) :P

Eating the dogfood:
Can you please make the editable field in the post area larger, or at least allow us to change the size. Also it would be awesome if we can some of the same formating options that are seen above. :) The live comment is awesome.

As someone who has had the frustrating task of administering and training users in a (commercial) asset management database system with astonishingly poor usability, I greatly appreciate your work. Whilst the product in question has a benevolent dictator leading development, it fails on all other counts:

1. The GUI is a clone of Microsoft Outlook(!) because “users are familiar with it”. What asset and publics work maangement has to do with emailing and calendars, I am yet to determine. :-(

2. It has extraordinary levels of customisation meaning every site has different configurations (though it is only used in only about twenty companies around Australia and New Zealand), to undertake a task.

3. The user must jump between different screens in different modules (all of which have different layouts and different interaction methods).

4. The icons are (mostly) unlabeled and obscure. There are also some text buttons with no icons. They can be at the top, bottom or side of the screen. There is no consistency.

5. It relies on external programs such as Access to generate reports and Excel for some input and

6. Much Sys Admin level administration has to be done by delving into the actual underlying SQL tables to alter values, most of which are undocumented.

7. It has never had usability testing. This is not even a vague priority at the company, who now have delusions of breaking into the US market

8. There has been no effort to determine how an average user would utilise the software. The excuse is that each compan has different business processes so they add different fields to each screen to please everyone, even if half the functionality is unused by 19 or the 20 companies.

To change the subject, I am curious about how you would suggest OpenOffice be fixed. GoogleDocs does not have the power features needed by some people who require advance word processor capabilities, for instance. If we take the approach of selecting a general user for a word processor, who will it be? A mother making shopping lists, her son doing homework, someone writing technical documents, a post graduate writing a lengthy dissertation, a novelist or someone who requires limited typesetting and DTP functions?

Some markets (like the academic one) are relatively small ones and could not justify a specialist word processor, especially as it is a market that requires many specialist, “power-user” features. Abiword, for instance, just doesn’t make the grade.

Maybe a good specialist tool in this area is LaTeX but what about other niche markets that are currently serviced by a general word processor. Are specialist plug-ins for each market the answer?

In my personal, subjective experience, the most usable software I ever encountered was the (closed-source) Lotus SmartSuite. It would be interesting to learn more of its development as I found its usability and elegance to be truly phenomenal yet the Suite remained general-purpose, with a wordprocessor that was high-powered and flexible.

Hi!
Thanks for your nice article. At this point, I want to address the problems you pointed out for OpenOffice.org. Although I share some of the things you mentioned, there may be hope ;-)

Since the begin of this year, a new project was initiated to work on usability issues / new features. This project allows contributors to work together with the core team of Sun. Find more information on this “User Experience Project” at ux.openoffice.org

Thanks for reading!
Christoph

One thing that’s not so much about the common user but more something that could push OSS in companies is its conf-hell. The best example might be the complete lack of GPO-support in 99% of all OSS applications. If the developers for OSS would think about not only making life easier for the user (which is THE most important thing to model an application around and your “do” list covers it perfectly) but also for the poor guy that has to give pc support to this user in a corporate environment, this would suddenly give certain OSS apps a HUGE advantage over commercial product (staying with the GPO example: commercial products often support GPOs).

Hell, which company could refuse a completely GPOd Firefox?

One app to add to the good list: Stickies
( http://www.zhornsoftware.co.uk/stickies/ - even though it’s not OSS :) )

We’ve rejected dictators in governance, but not in things like large software design?

Actually, it’s not dictators in general, it’s a “benevolent dictator”. Enlightened despotism is regarded as a near-perfect (albeit utopic) form of government, for exactly the same reasons that it’s beneficial to a software project. The analogy between society and a large project is quite pertinent, but projects are micro-societies with diminished scopes, where the utopical despot becomes practical.

Ray Schamp who wants a better spreadsheet
program might want to take a look at resolver,
http://www.resolversystems.com/

I’m reading through the article again to try to find anything you say about OSS that isn’t equally applicable to traditional commercial/corporate software development. I don’t think I’ll find much — this is good stuff for everyone building software.

Excellent article. Thank you.

I would add something more about dealing with user feedback:

“Do Try to Understand User Feedback.” Once a project has reached a certain point, more and more users (non-technical users) start to use it and want to improve it. But often, users don’t speak the same language as developers. They may submit feedback that doesn’t make sense to the developers at face value, but the developers should really try to interpret why the user submitted the feedback.

If the user requests feature X and feature Y already provides that, don’t ignore the user or tell them to RTFM. Be courteous and inform them of feature Y and note that it is perhaps not discoverable enough. If many people request feature X, perhaps there is a problem with how feature Y is presented.

Excellent post. I’m going to set aside a bunch of time to follow through your references - but does your Stallman story not violate the “do not develop without a vision” rule?

While I couldn’t agree with you more, Jono, about user interfaces in software applications and user interfaces in general, I have to make this remark: programming languages are more than user interfaces.

A programming language is a means to capture algorithms — how a task can be done or a solution to a problem achieved. While you can say it is an “interface” to tell the computer what it should do, this is a very limiting approach, akin to saying that English is only used to tell other people what to do. (And just for the record, I really dislike making allusions between natural and programming languages, but I couldn’t think of anything better.)

The problem programming language design tries to solve is not how to control a computer, but what kinds of means of abstraction and combination are most useful in solving problems and communicating the solution to other human beings. If you can use the same means to instruct a machine to find out the solution to an instance of the problem, the more the better.

However, module interfaces are a completely different matter, because they are very much user interfaces. (Depending on which school of thought you come from, replace module here with class, package, library, or any other name that refers to a separate, reusable source code unit.) What functions it exports, how those functions should be called, what they are expected to do, what kind of values they return, and how they affect the global state — this is where principles of user interface design are usable and pay off. (Again, replace function with whatever similar concept you like, such as method, procedure, subroutine, or what have you.)

In the Perl community, the written and oft-repeated rule is that it doesn’t matter if the implementation of a module is horrible, fails often, and contains countless errors as long as the interface is solid and well-thought out. This is because if the interface is good, you can always fix the implementation behind it or even change it altogether, and the users of the module need not do anything; but if the interface is bad and you change it, something is going to break, even if the change is good. Good module interfaces as extremely important for this reason and no less for usability reasons.

In fact, your Do’s list is directly applicable to designing module interfaces: design around tasks, have sensible defaults (i.e. just instantiate the module — no more configuration parameters than are necessary), have someone have a final say in what goes in and what doesn’t, and test with users (i.e. programmers using the module). A “plugin architecture” doesn’t make much sense in this context, although you could interpret that as decoupling data presentation from implementation and abstracting behavior to modules that you can then give as parameters to the module or its functions (while still leaving a good default behavior in the absence of such a parameter).

I think you did forget one form of configuration posibility, as xine-ui allows 3 different ways to be configured, easy, advanced and expert (in this one you have to understand the internals of the program at the same level as the programmer).
I love simpleness, as you, but not always. And I want to have both.

Google Docs? Forgive my hollow laughter. |t’s a nice idea but it’s crippled by the minuscule file sizes it allows, and by not allowing PDFs. I wanted to use it to coordinage with various people on an illustrated book I’m writing, It was too big a Word file only 12 pages in!

“I think you did forget one form of configuration possibility, as xine-ui allows 3 different ways to be configured, easy, advanced and expert (in this one you have to understand the internals of the program at the same level as the programmer).
I love simpleness, as you, but not always. And I want to have both.” -rosco

Great point…. Being able to configure you’re configure options is awesome. Even to go to the point where the configuration has packages that you can load to give you even a higher level of precise control.

Kudos! I never knew the history behind Firefox’s OSS development, but it is neat to see how the logic was developed into such a great application. As a web developer, I use both Firefox and Python (though not Emacs). I absolutely agree with your view on UI, and I think you hit the nail on the head. Great article!

OK I don’t care about a flame war: emacs is god awful, try pico/nano, you’ll see. Emcas likes to use key command names like Meta and Hyper — you keyboards that haven’t existed in twenty years… and just try and find where to enable option as meta in OS X (hint: Command-I) Although Command is also known as open-Apple — you know the clover leaf highway interchange symbol ⌘ and just try to find where to make that stupid sumbol on your keyboard (you can’t) — oh god I just realized we’re doomed to tech inertia, we won’t get rid of this crap for years!!! :)

I did not ready through all the comments and don’t know if my response is a duplicate, but I still want to give it a try:

I have to violently agree with your statement regarding python: IT SHOULD NOT BE ON YOUR LIST AND DISCUSSED IN THIS ARTICLE!!

As you correctly mentioned, python is a programming language and while you correctly could argue that it is some sort of UI, I think you added it incorrectly into the category of UI you wanted to discuss.

And furthermore: discussions about programming languages are almost like religious wars which we definitely don’t want to have here. I could probably argue as well that Ruby, C# or even Java also fall into your category of “humane” interfaces.

BTW. I find your wording a bit strange: I would never use “humane” in conjunction with machines or computers. Even if they are made by humans, these things are the most inhumane things on this earth, although they still try hard changing this fact.

Finally: despite my agreement/disagreement with some parts of your article, it is still a really good article. :)

Mistake #3 (Leave the UI Design Up To The End User) has been a nightmare for me to deal with when it comes to building web apps, because it’s a mistake everyone wants you to make.

Is there a client in the world who doesn’t wish he could just update his own website himself? Of course not. But the second you hand over the reigns, the design of the site is in peril.

You can create a CMS that limits clients to only editing blocks of text, thus keeping the design intact (they’re only editing markup). But then they want to add styling. And then they want to add images. And you find that the quality of the final product degrades proportionally to the amount of freedom you allow.

It’s possible of course to design an app that can make a limited number of design decisions competently in your stead, but as the system gets smarter it quickly becomes more expensive than the designer was to begin with.

It can sound snobbish and elitist, but most non-designers simply shouldn’t be making design decisions, and its in their best interest to take that freedom away from them.

In a world where everyone is a designer, everything looks like MySpace.

That rant ended up being only loosely related to the topic, but ultimately I agree wholeheartedly that the more freedom the user has, the more freedom he has to hurt himself. Perceived freedom is the key.

I was doing a UI for a simple system that allows customers to purchase products via a touch screen. I quite rapidly drew up the whole thing using gimp and were almost ready to ship it off for programming.

Luckily I decided to test it on a couple of friends and coworkers first..

I ended up drawing every single use-case, printing it out, hanging it on my wall and having 20+ people press the paper as if it were running on a real touch screen.

The amount of problems appearing in the simple UI were horrific.

I made more than 20 drawings, which were printed and hung up.

The result came out perfect and it is intuitive and simple. I know the programmer would never have questioned the UI, my boss neither, but the end-user would have again and again.

It could have been an OSS nightmare ;)

Firefox has a good interface? That’s news to me.

It’s a very reliable browser, that has done great things for OSS - but it has a terrible and ugly interface.

Whenever I start Firefox, it feels as though a two-year-old has been put in charge of drawing icons and windows, with crayons.

It completely lacks elegance and subtlety.

Can we just retreat to the days of GeoWorks? At about the time of Windows 3, it addressed & solved every issue of form & function that you & your readers have cited. Easy install on any of several DOS versions including MS. Choose Beginner to learn the basics. Move to Intermediate & find added functionality. Then on to Expert, but never really made you feel inept. Then watch GeoWorls move in on Microsoft & get crushed by bundling - BillyG bragged about his success: “Look what happened to Geoworks”. Then move to Windows 95 & lose interest in computers. Then on to ME & XP, suppress the Microsoft stuff & bring Firefox & NVU & StarOffice to the fore. Blast away a bunch of buttons & icons & it starts to look a little like GeoWorks all over again. Then install Ubuntu, dual boot at first, & WOW! It’s simple again! Just like Geoworks!…albeit on a much more powerful machine. Ubuntu’s Mark Shuttlesworth should team with GeoWorks’ Brian Dougherty as GUI oligarchy to the OSS world.

Almost stopped reading after the Firefox, Emacs, Python list, ’cause like some other people I strongly disagree. (And the article is a rather long)

But the points you make are very valid, and a slight re-ordering and change of words (”superior”) might have made it even better. (And kept the comments clean)

> For example, the Python program that prints “Hello, World!” looks like this:
>
> print “Hello, World!”

Only in Python versions below 3.0, because:

> […] 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 […]

Redundant constructs like the ‘print’ statement, which is replaced by
a function with somewhat different semantics. So, in Python 3.0, your
example above will need to be written:

print(”Hello, World!”)

Still quite simple, of course.

EMACS? You can’t be serious… EMACS isn’t quoted for no reason as Escape Meta Alt Control Shift

lol. now thats an amazing article. not often i see something that catches my attention and keeps it all the way through (at least on the web)
funny how when we ask for somthing “better” they hear “microsoft/mac” when what we mean is “microsoft/mac” isnt good enough. we want to fly and they(microsoft/mac) keep telling/showing us the laws of areodynamics.
(ps, yes i do have dislexia)

i wonder how you feel about zoho and meebo…

One thing I think would help would be more of an effort to sell usability to developers.

Most articles on usability (including this one) seem to be written in a way that perhaps isn’t actually *calculated* to discourage developers from having anything to do with them, but always seems to have that effect.

Developers seem to respond best to logical argument, usability people seem to always argue on emotional argument, and “we know best because we work in usability”.

Jono,

I couldn’t agree more, you’ve hit a subject very close to my heart. Software should exist to simplify life, not just for its own ends.

Interesting read. Although I would want to bring attention to Inkscape as an other example of brilliant implemented usabillity

Excellent article. But please notice that starting January 2007, OpenOffice.org has added a new project called User Experience (ux.openoffice.org). The UI project you mention in the article only focusses on the visual aspects. From what I’ve seen on the UX mailing list, the people in charge seem aware of the issues you raised. Let’s hope they will have the ability to evolve OOo.

Hey, nice article and good research (something most articles are missing). While I agree that lots of UIs are designed very badly, I disagree that building an UI after a “vision” without configurations would be a good idea. Because then you will end up having a dozen programs doing the same thing, just with different UIs, and often just slight differences that could be configurable, but the people with visions decided to not have them that way. I like my close button for windows to be in the upper left corner, thats just how I can work more productively. While its ok to have sensible defaults, things were people start to argue about should be configurable (if possible of course). Although I find gimps interface horrible (its generations away from photoshop) I think its good to let them offer all the tools that they have. While it doesn’t give any intuitive idea of what it does, all those features are needed by someone who does more than just scan something, erase a few lines and save it as a jpeg… In a vision, don’t forget that there are other peoples too…

GIMP is a free replacement for Adobe Photoshop.

This is simply wrong. This is not what GIMP developers are doing. Check facts, dude

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.

Then don’t use GIMP. It’s too professional for you.

I don’t get it: you write a great article and then you add these silly statements. Why?

Great post! Not only do you serve your opinions, but you also have done valuable research.

Here are my thoughts:
- Considering OpenOffice: I definitively agree. OOo just functions like MSO

hmm, something gone wrong. have written a very long post, but only the first 5 lines appear. trying again.

Great post! Not only do you serve your opinions, but you also have done valuable research.

Here are my thoughts:
- Considering OpenOffice: I definitively agree. OOo just functions like MSO

please delete my above posts. they didn’t work because i used <. now here it comes:

Great post! Not only do you serve your opinions, but you also have done valuable research.

Here are my thoughts:
- Considering OpenOffice: I definitively agree. OOo just functions like MSO up to2003, which also has a bad interface. Maybe there was a UI vision when the first of these word processing programs where developed, but soon it was put aside in favor of implementing every feature possible and cluttering the interface.

In my opinion, the UI of MSO 2007 is quite a revolution. Sure it has flaws, and somebody who is used to using MSO upto 2003 is confused in the beginning. But the new interface is very well designed. You say you should concentrate for your program to do one task. I think you could also say: It can accomplish some adjacent tasks, but you should do it with a different interface, specially designed for that task. This is what I think MS Word 2007 for example does very good with its “task modes” (ribbons). (Sure, slightly offtopic discussing MSO here because its not OSS. But i think the MSO engineers have done a lot of UI testing and also have thought a lot about their interface.)

Sadly, OOo only wants to implement every feature of MSO upto 03, instead of having a vision for a great UI which not only makes users think of “aha, a cheap alternative to MSO” instead of “wow, a great alternative to MSO, much easier to use and much faster to accomplish my task”. I’m curious if OOo 3.0 then will be cloning the UI of MSO 2007. That’s not how OSS should work.

- From a UI perspective, I do not think Photoshop is great for infrequent users. Sure, it meets the requirements of professional users, but also because professional users (graphic designers) are used to it.

- I’m also unsatified with the development of some OSS desktop environments, especially of KDE. One of the most important things to make a software usable are good defaults. That’s why Windows 95 was a revolution (everybody could use it without applying a 100 preferences), and also why so many people now like OSX (also extremely simple with quite a good default behaviour).

While I think Windows and OSX UI is not perfect, they are still usable from a starting point. I don’t wanna abolish preferences totally, but I think developers should think very well about the default behaviour of a software (usable and sensible for beginners, hidden preferences for pros and hackers). That’s also why I would recommend linux beginners Gnome, not KDE, and that’s also why in my opionion most commercial linux desktop sellers (Redhat, Novell/Suse) deliever Gnome as a standard desktop: because novices are not confronted with 1000 menu items, checkboxes and other preferences, but with a quite resonable and simple UI.

Most users don’t want to spend hours tuning their desktop. Most people also don’t buy cars where you have to adjust everything before you can drive (like force of brakes, gas injection etc - I’m not very into cars *g*.)

I surely know that user testing is expensive and that small OSS projects can’t afford it. But they should at least try to think about what a user is using it’s software for or/and ask a UI expert like you.

- An example for sensible default, but slightly unimportant and offtopic: Search on the linux command line. In most cases you want to search downwards from the current directory for the name of a file. “locate $filename” does it simple, with reasonable defaults. “find . -name $filename” maybe can do more, but for novices, it’s even a hurdle to remember these simple options. (It’s offtopic, because no normal user should ever be in need to use command line for searching.)

- All in all the widespread ignorance of UI design in OSS is one of the big reasons why Linux hasn’t made it to the desktop of average users, instead for example Firefox, which in my opinion is the greatest success story of open source. Nobody should feel like he has to read a manual before using a software. Everybody could use firefox, even if he had used IE before, which in some terms is different. (From the commercial side life: Nobody is in need for a manual for example of the iPhone GUI. Almost everybody understands it, even if she has never used something like that before.)

- Another point concerning Linux distributions. In my opinion, a distribution not only aimed at hackers, but also at normal people, should only have exactly one application for one task. Ubuntu does this very good, and thats also the reason of its widespread use. While Debian is a great piece of (stable) software and I am really thankfully for their developers and I would use it on all my servers, I would never recommend a “normal” user a full installation of debian (10 mail clients, 10 IM clients etc). And if some user who is comfortable with another program that is not in the default Ubuntu (ex. Thunderbird instead of Evolution), it should be and is easy for him to install his preferred application. I think this is far from being an interface nazi. This is the great concept of opinionated software, where you try to make it as easy as possible for most users by making hard decisions for them and leading them by the hand while also allowing hackers to adjust it.

- A last point, also at answer to pipedings: These rules only apply to applications for “normal” users. If applications like postfix and apache have a lot of options, it’s not that bad, because they are suited for administrators who really should know the software. It’s also not bad for libraries like example ffmpeg to have thousands of options, because they are made for developers. But these rules apply for end user software. Example for the example of ffmpeg: ffmpeg should have every possible option for encoding movies, like format, bitrate, resolution etc. But developers of a end user gui for ffmpeg should make simple options like “convert to psp” and “convert to ipod” (they can make an advanced menu where you can specify your exact needs if you really need it).

- And as an answer to Aaron J. Seigo: Your comparison is untrue. Even in a democracy, people elect their representatives to lead the state. What would happen if every citizen could write a law if only it was “reviewed” by two others? Legislation would be cramed with even more features than now and would be “unusable”. But that is what happens to some software (maybe OOo, old Mozilla, etc.) So every software project should have some leading group with a direction and a vision, elected or dictatory. And there’s also another difference: If you don’t like the dictator in your state, you can quite do nothing. But if you don’t like the dictator in an OSS software, you could just fork it (”clone” your state and establish a new one) and establish a democracy in your forked version and convince the developers to emigrate. I hope you know what I mean, even in my bad English ;)

- And again to Aaron J. Seigo about the point that OSV should apply good defaults to KDE themselves: The problem here is then that “KDE is not KDE”. If you use KDE on Kubuntu, it works differently than KDE on Suse or on Mandriva. Very bad, also from a trademark point of view. So end users are not only confused when they are forced or decide to switch desktops, but also when they switch between different versions of KDE.

Thanks again for your great post, Jono, and excuse me for my faulty postings. You have made good points, and I hope many OSS developers read it!

Excellent article, thanks.

Two things needs emphasizing over all else: put the most commonly-used functions at the top of the menus (and/or in the toolbar); and make the default behaviour the expected behaviour (even down to naming it by the name the users call it). It’s astonishing how hard it is to so some of the most required things in some interfaces, even when you’ve RTFM.

I’m currently researching the usability of interfaces to structured text (eg editors for XML and LaTeX) as my PhD topic, and have come to the conclusion that there are *none* suitable for use by the average author without significant training, because they do everything the expert wants instead.

Myself, I use Emacs, of course :-)

I always enjoy usability articles, but so often they exhibit a flaw. The failure I see in this article is, one again, the idea of customizability.

It’s true that the tower-of-babel effect is detrimental if allowed to run amok. It is important also to note that when Emacs was “standardized” and brought to heel it was done without removing one iota of the configurability that had previously made such a mess.

Why, then, do usability experts always insist that KDE, for example, should trim down the amount it can be customized? I am a firm believer in good, usable /defaults/, clean preferences, sparse menus and all that. However, I am not a fan of rejecting options for the sake of usability.

Some options are certainly not as essential as others, but which those are vary greatly depending on the user. The essential feature is therefore allowing the user to decide which features are essential. Allowing is not requiring; again, a well formed set of defaults would mean that few users will ever attempt to change settings.

If a user should attempt to change settings then I have no problem with placing the most common or frequently-used settings in a simple, easy and clean preference dialog. But the settings for less-common features should not be relegated to a Registry, gconf or some obscure non-commented config file. Configurability must be a first-class citizen, even if it means every preference dialog has an Advanced button which spawns a scary, complex preference dialog.

Options are essential to freedom. How many users leave Windows entirely due to the frustration with the way it behaves? I certainly can never return to Windows and can never use Mac OS X purely because of the inability to make them work the way I like.

The GIMP UI is a good example. It is a highly usable interface well suited to its purpose. The GIMP developers have not, to my knowledge, attempted to clone Photoshop’s UI, despite the implication of this article. Instead they designed a UI which is, especially in the case of GIMP 2.x, fantastically customizable for any image-manipulation workflow.

The two things that GIMP lacks are discoverability and good defaults. The defaults are okay, but an impediment to quick use. The primary flaws in the GIMP’s usability are that most distributions ship with GTK menu keybinding editing turned off and sub-standard window managers (read: Metacity) which fail to manage the GIMP’s many windows well. These are things for which you can hardly blame the GIMP.

If the GIMP developers were to revisit the UI choices and redesign, something I understand they are considering, they could hardly come up with a superior design. The major thing they might accomplish is a more discoverable default state. Anything further would mean feature *and usability* regressions for all those who use the GIMP more than casually.

Options are essential to freedom. How many users leave Windows entirely due to the frustration with the way it behaves?

Not many. Otherwise Linux would have a much bigger market share. Your assumption that everyone wants to have an incredible level of configuration options is wrong. Only very enthusiastic computer users want to explore everything (others would prefer to explore everything about their car or bike or food). Moreover, your assumption that freedom = more choice is wrong, and you should’ve really read the links Jono pointed to in his article. Overwhelming choice (as in KDE) results in less of the choice being used. In the case of KDE, there are so many (unimportant) options that it’s getting difficult to find the important options. This is the actual problem.

I think the best solution is to have only essential options visible in the preferences and the rest accessible via an integrated search interface (could be extended to rarely used functions, in general). Personally, I have three categories for customization options:
* Personalization: customize to match personal taste and style without making you more productive (e.g., background color of a window, fireworks or raindrops on the screen)
* Optimization: increase efficiency by adapting UI to user’s daily work and capabilities (e.g., adapting toolbars to personal needs)
* Operational: required to make the product work, at all (e.g., proxy settings in Firefox)

Operational preferences should be easily accessible, but they should be replaced by automatic mechanisms whenever possible. The most important optimization preferences should be accessible, too, but they should not make it easy to degrade productivity. The remaining set of options should not be shown directly to the user and the personalization options often are totally useless and waste the user’s time (though, if computers are your hobby you will probably disagree). Note, I do recognize the fact that some personalization options make you feel much more comfortable with a product and could be considered optimization options. For the “invisible” options, I’d like to have a search field in the preferences dialog where I can type what I want to change (instead of being overwhelmed with choice I don’t want), but the search algorithm should also try to match related words in case I don’t know the exact feature name (e.g., when typing “activate” then also “enable” will be matched, when typing “network” I will also get “proxy” settings).

Contrary to what some people make us believe, many consumers don’t even want to have a lot of choice in *all* situations of their life. The stereotypical view “choice = good, no choice = bad” is not as black&white as many people seem to believe. There is something between “lots of choice” and “no choice”. Reality is much more like this: “freedom+happyness” means to have the *possibility* to choose and then get what you want when you want it.

From a different point of view, “freedom” means the freedom to *NOT* have to choose and not be bothered with choice unless we choose to have choice (i.e.: don’t overwhelm us with lots of options that have nothing to do with our goals).

If the GIMP developers were to revisit the UI choices and redesign, something I understand they are considering, they could hardly come up with a superior design. The major thing they might accomplish is a more discoverable default state. Anything further would mean feature *and usability* regressions for all those who use the GIMP more than casually.

You’re assuming that there is only one single way to display and access information. By using a better conceptual model you can create a much more powerful and at the same time much simpler interface than by simply stuffing more functions into the menus of your application. There are a lot of nice ideas for improving GIMP. Please at least read the blog about GIMP’s UI improvement project before you claim that it’s impossible to improve GIMP beyond better default settings. Note, the ideas presented on that page won’t necessarily be implemented, but they at least collect important problems and suggest possible solutions.

In case I misunderstood your last point and you meant that simply hiding a few customization options won’t result in much improvement then I somewhat agree, but I still think that by overwhelming with non-essential options you take away focus from options that matter and that should probably even attract the user’s attention in order to make him more productive by adapting the interface to his needs.

[…] Very interesting piece to read. Enjoy. […]

The ABC programming language, Python’s immediate ancestor, was developed with “extensive usability testing”. (Search for “guido van rossum abc usability” to get references.)

herr_ernst:

The reason OSS desktop software has not gotten popular isn’t due to interface issues. It is because it isn’t ‘usable’ in the real sense of doing everything that people need to do. Firefox does what browsers need to do, so it is used.

Derek

Very interesting article. By the way, love your TeX anywhere product (is there a possibility it will be available for the Mac in the future?)

An interesting thing to note: all your top three examples are dynamic programming languages. (Functionality can be added on the fly with no recompilation or restarts.) It’s assumed that as a user of Emacs you will customize it to work how you want by programming it. It’s less obvious with firefox, but the combination of XUL and javascript in effect creates a programming language that’s designed to write browsers in. (Unfortunately the extension architecture is crap compared to Emacs.)

I believe this is the only way to achieve the necessary flexibility without descending into the madness of early KDE with config boxes for everything.

Just one note: another thing which is essential in order to make open source software more human is, after you have developed it, to advocate and support it without repeating the Seven Things we’re tired of hearing from software hackers! Thanks for the article!

Marco F.

I’m a programmer (though not a python flavoured one) and sysadmin. I have no argument with python’s language design, which I think is admirable, but I do have problems with the practicalities of its implementations, which are often horrific. Far too often I need to use a python-based app, only to find that it has very, very specific version dependencies that are either not available in my distro, or conflict with those of some other app. So I might find that one app will ONLY work with python 2.4, and that it requires exactly version 2.0.5 of pysqlite2, another might need pysqlite2 2.0.7, but another app might want python 2.5.1 (though you can run multiple major versions at once, it’s more admin hassle) and pysqlite2 2.3.3. So eventually you get them all to run at once. Then you do a normal apt-get upgrade, and it all breaks.
It seems to be completely normal to have python app dependencies that are == rather than >=. Some python apps are rock-solid and seem resistant to this - apt itself for example - but it seems rare, to the point where I actively avoid apps written in python because I know that I’m in for a shedload of config and dependency trouble, or, if I’m desperate, set up a whole additional server just so I can restrict library versions to the exact ones required for one app. If I was a python author, I wouldn’t want to inflict that kind of pain on my users. Generally I don’t usually have this kind of trouble with php and perl apps (though installing rt is like running a marathon…).

I know you were expecting this, a Vi(m) shill to come argue about emacs being great :P
There are two prime reasons I’m afraid of using Emacs:
1. I find it overwhelming. To go a page down or to skip to the next word; I really don’t like to move my fingers from the home keys… While Emacs needs me to learn too many combos.

2. I was afraid of a particular phenomenon whose name I found out now : Tower of Babel Effect. I really don’t want to be habituated to something customised to such a degree that the factory configuration becomes unusable. At times I forget what changes I made to a software to begin with; which is traumatising.

These two are what I find less prominent in Vi; plus the fact that I can stack commands (I don’t know if you can do it in Emacs) is where I find it fun. But Emacs is definitely modal!

[…] Slik kan fri programvare blir brukarvennleg […]

Nice article. But I don’t see why the configurability of KDE should be a disadvantage. It’s usable out of the box, and you only have to configure it if you don’t like some aspect. I like a sober desktop, so I disabled all the graphics fluff and eyecandy ;-) I’m glad KDE lets me do that.

[…] Whole Article from Jono DiCarlo tags:  Usability Leave a Comment […]

When the default UI doesn’t cover the users needs (different video card, different NIC, different features that are not UI), why force the user to search through thousands of bygone era internet documents? Remember, a document on the internet is not a solution for every version of a given command and will not apply to every distro. Been there a hundred times.

I see no reason to single out any particular Linux application as a good or bad example when the whole Linux paradigm rests on developing trust in any number of any age of ancient documents that rarely cite the versions of the commands they are documenting.

How many times have I been referred to some tutorial to cover what the UI failed to address? I’d say dozens… and then the referrer says: ‘the same as that one, only different’ because that one is a few releases back, yahda yahda. How many times has the kernel been revised since the highly regarded ancient tome was glyphed? How obsolete does something on the internet need to be before the site owner pulls it down?

I say if you are going to discuss a lack of efforts, start at the most distant locations of Linux and work toward this UI concern, such UI refining efforts will also be a lot easier after people are trained in understanding how the other stuff works and also helps add definition to where the developing UI holes reside and thus refines the quality from the inside out.

And then I woke up.

First, see OpenUsability.org - “…an online community that connects usability people and F/OSS developers…”

Second, I agree with Jono’s points, and I’m sad to see comments that blindly advocate “freedom” and configurability. They don’t address the points that a well designed UI is useful for all, that most people prefer not to have to configure their UI and when they have to configure something, prefer to find it easily rather than wade through a lot of options.

As for the comment about selling UI design to developers, I don’t see what you find “emotional” (illogical) about the points here. The article advocates for a clear vision, thinking through the use cases and user testing. What more logical than those?

There will always be those people who want 100% configurability of there system, and those that want 0% configurability. If you design a product that gives 0% configuration options you don’t accommodate those that want to change it. If you design a product that is 100% configurable, it’s impossible to NOT accomodate those that DON’T want to change it. If product A that offers little configuration, and product B offers 100% customization and the two are otherwise completely identical, the one that is configurable is better, that is unless every single human is an exact identical copy of the other and they all want exactly the same thing, then configuration is rather pointless since everyone is the same. For those that don’t want to options to configure, I say you’re rather dull, boring, stupid, uninteresting, and a waste of space, time, and everything so bug off! :D

[…] Posts Ten Ways to Make More Humane Open Source Software Undo Made Easy with Ajax (Part 1) Undo Made Easy with Ajax (Part 1.5) Never Use a Warning When you […]

I could not find this site in the Search Engines index