The Rise of Interface Elegance in Open Source Software
Open Source software is regularly criticized, often fairly, for lacking in ease-of-use and polish. When a developer wants a new feature - he can add it to the software, and if it gets checked-in by the project owners, it will be there for all to use. The obvious fault with this model is the now well known scourge of “creeping featuritis” - when too many features and options begin to overwhelm and overshadow the core functionality of the software.
The Mozilla browser and suite were a high-profile example of the ills of featuritis. While the software did everything you could possibly want it to, people still seemed to prefer other software packages that did less.
In a well run software project (several of which I fancy myself a part of), any additional feature must be proved valuable before it is incorporated. Even if a patch is already written to add a new feature, there are plenty of reasons not to accept it. More code means more potential bugs and more management. Additional user interface features can detract from other more important features.
Learning to Say “No”
One of the most important acts of a software project manager is to say “no”. No, this patch introduces more code than it should. No, this feature will confuse more people than it will help. No, you’re ugly and stupid (sometimes the manager has a bad day).
The open source software model has dealt with the importance of saying “no” quite well in the realm of code and patches. Projects have a limited set of people with the power to commit code to the project. Anyone can submit a patch, but only the anointed few can accept it. These anointed few are usually determined by right of having founded the project, inherited the project from the founder, or through perceived merit. For more on the issue of project ownership in free software, see Eric Raymond’s Homesteading the Noosphere.
When submitted code isn’t up to snuff, it isn’t accepted (ideally). The practice of saying “no” to patches in open source software is understood and accepted. Now, some projects seem to be learning the value of saying no to ideas and features that will negatively affect the interface and experience of using the software.
Living Examples: Firefox
In discussion about the usability of open source software, the Firefox web browser is sometimes cited as an exception[1]. Out from under the girth of the Mozilla project, this small and simple browser emerged to become one of the more popular open source products and projects. The developers of Firefox leveraged the long and proud history of saying “no” to code patches and applied it to the interface and functionality as well.
The resulting browser provides a better browsing experience than it’s ancestor, Mozilla Navigator, despite having far fewer features and functions. Smart default settings and an overall better understanding of the experience of using the application by the developers helped make it better for everyone.
Living Examples: Gnome and the Spatial Nautilus
Spatial Nautilus isn't really much to look at - you really have to use it to understand it. Screenshot from ArsTechnica.
If you think “Gnome and the Spatial Nautilus” sounds like a line from a novel that Douglas Adams and J.R.R. Tolkien might be collaborating on in the afterlife, please bear with me. Gnome is a group of projects that provide a desktop environment on Linux. Nautilus is the name of the file manager in Gnome, like Explorer in Windows and Finder on the Mac.
The “spatial” browsing metaphor a concept for browsing and managing files and directories of which the details are not important for this essay (to learn more about spatial browsing, see John Siracusa’s seminal article, About the Finder…). Suffice to say, the Gnome project has implemented spatial browsing in Nautilus in their latest release, and a lot of people really don’t like it.
Using the spatial browsing metaphor can take some getting used to, and many people who are used to another metaphor (or no solid metaphor at all) are understandably quite resistant to this new model. A fundamental and controversial shift like this is one I would not have expected an open source project to be able to pull off. While a closed corporation has a hierarchy of power, where one person can make a decision for all, consequences be damned, I was skeptical that such a move could happen in the looser structure of the Gnome project.
I was wrong. The developers of Nautilus debated and then declared their bold intent to “go spatial”. There has been much support, and much resistance. However, regardless of whether they were right (which will likely be proven over time), they deserve credit for making such a strong, clear, and decisive move.
Living Examples: Hunting for Preferences in Gaim
The Gaim messaging client is starting to get simpler with each release with a planned simplification of the preferences.
A third and final example of this pattern of interface elegance in open source software comes from a recent discussion on the development mailing list of the Gaim instant messaging client. Gaim is an open source messaging client that works with a variety of protocols (AIM/ICQ, MSN, Yahoo, Jabber, etc.).
Sean Egan, lead developer on the Gaim project, has posted his intent to dramatically simplify the “Preferences” in the application. He lists many preferences that can simply be replaced by a good default, and others that are just plain irrelevant. Rather than getting bigger and fancier with each release, the project seems to get simpler and more elegant.
Killing the Myth of the “Average User” and the “Power User”
Rather than aspiring to do everything imaginable, we are better off aspiring to do everything we might actually want our software to do in practice. While it may be that I’m attracted to projects that tend towards elegance in interface and design, I suspect that the examples I’ve cited here are not exceptions. Rather, I see them as part of a larger trend in open source software - one where simplicity and elegance in interface design is held in the same respect as elegance in code and engineering has been all along.
A kernel hacker, who we might all consider to be a “power user” may not be a power user when he just wants to burn a CD for his road trip. A database administrator, another typical “power user” may just want to chat with his friends, not perform an orchestra of preferences and settings in a chat application. We are all experts in some area of software and beginners in others (and our experience is constantly changing).
Rather than adding more and more features for the mythical “power user”, or swing to the other end of the spectrum and dumb-down the interface for the mythical “average user”, smart developers are learning that good defaults and elegant interface design makes software better for everyone to use, regardless of their level of experience.
- John Gruber cited Firefox and Camino as exceptional in their usability as open source projects in his critical reply to Eric Raymond’s essay, The Luxury of Ignorance. The reasons for the exceptional nature of Firefox and Camino are further discussed by Matthew Thomas.
And true, it's better not to have a feature than have it done poorly.
I fear that the simplification mania sweeping the OSD world is well meaning but ill-founded. The lack of user-centered design processes - specifically documenting use cases and usage frequency means there is no reality check for axing an option.
I think it might be better to make options interface in mindmap style where each option would have "link" to options alike. For example when you are in "save" -option you would have links to options: "save as", "open", "page settings" and "close window". In this way options wouldn't have one "right" place where to find them but you could find them (in semantic web) by following the trace of options alike. What i think would happen in this is that most common options would have lots of connections to them and not so common options far more fewer, so there would be lots of options, but they wouldn't be bugging you unless you'd be looking for them.
This is a wonderful way to allow your product to be both feature-rich, and lean and mean.
During the recent Gaim preference culling mentioned in the article, much feedback took the form of "I don't use it, but others do". One of the Gaim developers smartly stated that such comments were worthless and would be ignored.
Thomas, the Gaim screenshot is actually a hacked-up mockup I made for the gaim-devel list. However, you can now hide those buttons in the CVS version (and presumably the next release). The buddy icon has also been moved up to the left of the input box, as in the screenshot.
I would hope that the makers of OpenOffice, functionally a great program, but with a UI that is downright hostile at points, would take something from this article as they design the UI for OO.o 2.0. We don't need more buttons or prettier buttons, we need an interface that maximizes usability, regardless of the proficiency of the person sitting at the keyboard.
The suggestion that there are no users who enjoy downloading addons for their software is basically wrong. If you look at the Mozillazine forums, there will always be a few threads where people are discussing which extensions they have installed. So, such people do exist, but they're a tiny minority of people who appreciate the software itself rather than just regarding it as a tool.
In any case, the extensions system itself has all sorts of problems. There is a tendency to push out features that should exist in the core into extensions. In the case of Firefox, there are no UI guidelines for extensions, so they tend to suffer from too-many options and occasional flat-out bad design. There is the problem of too-many extensions - how many people are likely to search through nearly 200 extensions to find the one that adds the tiny piece of functionality they need? Worse, extensions can conflict and so a user can unwittingly reduce his browser to an inoperable state by installing the 'wrong' combination of extensions.
A case in point is the "SessionSaver" extension. This extension allows one to save and restore one's browser state in a number of ways (manually, automatically when the browser shuts down, only after a crash). Of these functions, I want precisely one (resore state after a crash - although having said that, the other options have been useful). Now, restoring state after a crash should really be a core function (afterall, it increases the user-friendlyness of the product and doesn't add any complexity). But it's not so, instead, I have to put up with an extension that adds 3 items to my file menu (one of which isn't actually an item at all, it's a text label. In a menu.) and another submenu to my tools menu (which agan has two non-clickable labels). It also has an options dialog which is a model of unfriendly-terseness and has some truly bewildering options (it seems that, at some point someone decided they wanted to be able to restore a state of the browser with lots of different windows into a single window with multiple tabs). Since one is restoring the browser after a crash, one would expect to be asked on startup if one wished to have the session restored. Yet, as far as recall, it doesn't do that.
So we have an extension that I'm using as a replacement for a single function which should be included in the core and should have a single dialog asking if I want to restore my session but instead has a horrific interface that lacks the single dialog box I expect.
To be fair on the sessionsaver people, it works really well and the interface problems may have been fixed in a more recent version.
As for simplifcation in general, I agree it's a good idea and indeed I appreciate a simpler UI. But I get the feeling a lot of 'power users' feel differently. Witness the number of people who bitch and moan about the 'simplified' Gnome 2 interface but love the much more cluttered KDE interface.
As for the last section of this article, the terms 'power' and 'regular' user (to my mind) is language used to distinguish between two groups of users - those who want to customize the product and those who want to use the product out of the 'box'. Extensions allow Mozilla to provide a fast, solid foundation like Firefox without sacrificing the ability to customize and add aditional functionality. If there is a better way to serve the needs of 'all' users, call them what you will, I have yet to see it.
One solution might be a HIG document for extensions. Then at least people would have some rules to follow.
User experience work is very hard. That a few projects have reached a point in their maturity to be able to "afford" high-quality user experiences isn't that surprising. What will be surprising is when it's the rule, rather than the exception.
That's a long ways down the road. But this article, and further attention to the value of quality UI, are great steps to be taking down it.
- The barrier to entry should be as low as possible to build users' confidence
- The users who use the tool the most will find they could improve their productivity by customizing it. At this point a few well-thought out mechanisms are needed to minimize the learning curve. The tool I have written for work has three such mechanisms:
- All non-performance critical code is written in Python, and can be replaced by the user
- A grammar file to specify register formats
- Skeleton files that can invoke Python code
These mechanisms shouldn't be add-ons, but rather the way the tool itself is written since they need to be well tested and easy to understand for users. If the mechanisms provide easy customization for users, they also do for the maintainers.
90% of users just sit down and use their programs as-is. They don't go and tweak the program, they don't do anything. Changing the background is about the limit of tweaking by most users and many don't even get that far. It doesn't matter how bad the defaults are, users don't change them -- I was recently in an office and the screen was still flickering at 60Hz. When queried, the owner said "I don't dare touch anything". The lesson I take from this is that good defaults are critical. I notice you came to the same conclusion. If the default install of your app aren't easy to use, then your app is going to have no end of problems (compare scribus to quark -- regardless of features, scribus feels ungainly.)
But my opinion differs markedly as soon as you go beyond the defaults. Since the defaults are good in 90% or more of cases, a user changing them is a power user by definition. That user wants the feature which will make the program better. Here is where the gnome project fails miserably, such users are told quite simply 'No'. Well, that sucks. The first thing that these 10% of users should be offered is a few simple options -- perhaps the ones mentioned above in the 'Well, I don't use it but I know x does' category. The goal is to satisfy as many people as possible with the minimal amount of effort. Most people can be satisfied by the defaults. Most of the rest can be satisfied by a few simple options.
As an aside, claiming extra features decreases stability is wrong. Sure, the naive way of implementing extra features is to build them straight into the code (decreasing stability) but if you're going to go to the effort of writing an extension mechanism then it is no more work at all to dynamically load any non default preferences as you would an extension.
Extensions are not an acceptable solution because they're just too complicated to install. Extensions are appropriate when you want to go beyond the core functionality of the program. For instance, an extension to the printing system could add printing to PDF (something that is not core to printing, but many people want). However, as soon as you start putting functionality many people want into 'extensions', you ruin the application. Firstly it becomes hard to set the optimal defaults. But more importantly, when the user finds the defaults are inadequate, the barrier for that user to fix their environment is far too high.
The main problem with programs having lots of features is the defaults often suck. This has certainly been a problem for various KDE apps in the past, and will probably continue to be a problem in the future. Conversely, it won't be such a problem for gnome since programmers know they can't expect the users to fix it. Lets go back to the mozilla/firefox debate. I see the main problem with mozilla being that its defaults sucked. That meant users had to go through all sorts of hoops to get their browser they wanted. In creating firefox, developers had to get rid of those options, so they were forced to select good defaults -- they could no longer use the excuse 'the user can change it to something they prefer'. Imagine if mozilla defaults was just like firefox until you hit the preferences menu option. Suddenly most of the justifications for using firefox disappear. Speed? Hardly a problem with prelinking, especially if you're just using the defaults. Reliablity? Not a problem with dynamic loading.
As an attempt to summarise... 90% of users will stick to the defaults, so make them as good as you possibly can. When a user doesn't want the defaults, chances are it will be a simple tweak which many users want. So put these popular variants in a fairly prominant place. But DO NOT STOP THERE!. Some people want the advanced functionality and that should not be relegated to requiring them to download it from the net. The 'advanced' tab is a pretty simple concept, and my only complaint with it is it's misued too often. Then, and only then, put in your extensions mechanism if you want. The goal is to satisfy as many users as possible at every step. You want to satisfy 90% of users without showing them any options, then most of the rest with just a few simple options, then most of the rest with enough options to avoid the need for extensions.
Sorry for the long post.
Here's my two cents: It's not the amount of features (or lack thereof) that matters. It's more important that they are displayed in a friendly manner. Of course, as stated in the article, some features can be entirely worthless and shouldn't even be considered if the developers feel that be the case.
It seems that many programmers start with a few options in early stages of the program, listing them with a checkbox or three. Then add a few more checkboxes, and a few more, and a handful more, and eventually you've got a mess of nothing but checkboxes cleverly placed to fit in the small amount of real estate given. This is either a result of laziness to refine the UI, or poor planning and implementation. After major changes have been done per dialog, there should come a time when the programmer should sit back and consider options of making it a little more usable. Nobody likes to look at a window and read every little option that's there when there are a hundred of them. More likely than not the user is just looking to find a certain option and change it as needed.
My point should now be clear. Functionality shouldn't be affected at all, just the organization of the functions themselves.
At some point, I believe developers should halt development on features and code efficiency and focus on the UI for a minor version number or two. The user interface is just as important on the code it runs on, and should be given stringent usability testing for every large change.
Bug fixes are nice and all, don't get me wrong, but I won't get the chance to find the bug if I don't want to use the program.
Maybe it's an idea to not completely delete the "advanced" options from the code, but only to remove them from the UI. This as long as the code doesn't get bloated because of all options and only if the options fill a real need. These options can be modified by "power users" via the .config files of the programs.
Then create a general purpose tweaking program "LinTweak", with which you can edit the hidden options of the software. This I should of course work with plugins so everybody can add tweaking for any program that has tweaking options.
As for extensions, I believe that they are mostly good because they make it easier for maintainers to say "no" without getting flamed by the tweaker crowd. Other than that, I don't think they are really useful. Maybe for testing new features or for very specific tasks (for example I'd really enjoy a well designed web developer extension for Epiphany, ideally this should be installed by default and activated either from the GUI or a simple gconf key), but in general, applications should be designed as if extensions wouldn't exist.
allow extensions, but use the download count or some other metric as an indication of popularity/desire/need; when a given "measurement" has been reached, implement that extension as an integral part of the product. the majority has spoken and the extension list for future releases is reduced by one.
1) There are many functions that are common to most projects, such as file operations, help (general and context sensitive), printing, viewing options, etc. A skeleton with the most common features would provide developers with a headstart on their user interface, as well as samples that could be used to add the unique features of that project. It would be helpful to have at least one for each of: Gnome, KDE, lesstif, curses, and XUL.
2) In the same vein, while there is a certain amount of art to creating user interfaces, there are also many well-known practices. A site providing HOWTOs and sample design documenation in a format like wikipedia so that it is a living project and can be easily contributed to by users as well as developers and UI professionals would go a long way to helping projects that already have a lot on their plate just getting the blasted thing to work>:-(!
3) A thought about configuration options is to make them context sensitive. A right click would pop-up a menu where configuration is a menu selection, and the submenu would have the options for all of the active elements.
4) Back in the old days of IBM mainframes, they provided several times the number of options that most users would ever need, many of them for tuning. Of course, since they thought of themselves as a hardware company at the time, the defaults were far from optimal. This meant that customers who didn't change them would need to upgrade their hardware sooner, and those who did had to take IBM education courses to learn how (yet another example of how Microsoft does not innovate). I have kept in mind how much I hated this, and in my own development, as much as possible, have the program dynamically tune itself. Would this be possible to do with user interfaces? Here are some ideas:
a) Reorder menus to put the most frequently used items near the top.
b) If a user performs many of the same functions in the same order, automatically build a macro and use it when the beginning sequence is entered (like editor macros that perform shortcuts for certain languages, like closing brackets in C loops). Of course, allow the user to modify it immediately to add prompts and provide the option of executing automatically or displaying a small window with a simple hotkey or mouse click to activate it.
c) If there are several ways to navigate to the same point, keep track of how a user typically does it. When the beginning of that path is selected, display the entire path (like Open Office automatically finishes words). Or, if an option that is nested in several levels of menus is used frequently, move it to a higher level menu.
d) Use a threshold of the number of repititions before "learning" takes place and make it configurable, perhaps with a slider bar from slow learning (ie. many repetitions) to fast learning (ie. 2 or 3 repetitions).
(Note: Coming here from LinuxToday which just linked to the page today.)
a) Reorder menus to put the most frequently used items near the top.
Please, not this. Think about it: just when you're learning where something was, it would move somewhere else...
I found Firestarter installed simply from an RPM at the projects website and within minutes of the install I had a working firewall. Everything was intuitive and easy to follow, in short elegant and Impressive.
Compare Mac OS, wherein you open the Networking control panel, click the Firewall tab, and click Start.
Unfortunately, the Gnome developers have forgotten that they come from the "free software" movement, which believes that software should empower, not constrain, users. Their design decision deliberately removes a measure of control the user has over their environment. That is not a laudable thing.
"Win95's "My Computer" view did it..." No, it didn't. Go read Siracusa's article. Windows does not have, and has never had, spatial file management. They have a "big icons, and open folders in new windows" view, but it is not spatial -- so even the most hardcore Mac user is hard-pressed to like it. Hardly a condemnation of spatial.
"Unfortunately, the Gnome developers have forgotten that they come from the "free software" movement, which believes that software should empower, not constrain, users." Utter bull. The source code is there if you think you can do things better -- it's free software in every sense of the word.
As for keeping things simple, this does not (necessarily) make users less empowered. Put your mom in front of a Mac, and then put her in front of a Linux console, and ask her which she feels more empowered using. Making a free operating system easy enough that my mom can use it is most definitely a laudable goal.
