There’s a tension between presenting a user an uncluttered interface and helping the user discover new features. This post will begin by discussing two extreme examples. On the cluttered but discoverable end of the spectrum is Microsoft Word 2007. On the uncluttered but also undiscoverable end is Emacs.
Microsoft added the ribbon toolbar to Office 2007 to make it easier to discover new features. Before that release, 90% of the feature requests the Office team received were for features that Office already supported. The functionality was there, but users couldn’t discover it.
According to this report, the ribbon has been remarkably successful.
Data is showing that the redesign of Office really did reach this goal — Word 2007 and Excel 2007 users are now using four times as many features as they used in previous versions, and for PowerPoint, the increase in feature use is a factor of five.
Power users often dislike the ribbon, but most of the estimated half billion people who use Microsoft Office are not power users.
(By the way, you can collapse the ribbon with Control-F1. The ribbon will reappear when you click on a menu. On a small screen, say on a netbook, this could greatly increase your vertical real estate.)
In some ways Emacs may be the exact opposite of Microsoft Word. It has an enormous number of features, and yet it doesn’t feel cluttered. The downside is that discoverability in Emacs is pretty bad. The best way to discover Emacs features is to read the documentation. There are ways to discover features while using Emacs, but you have to be fairly deep into Emacs before you learn how to learn more.
Can you increase discoverability without adding clutter? Maybe if your design is not very good to begin with. But after some refinement it seems inevitable that you’ll have to decide whether you’re willing to increase clutter in order to increase discoverability.
One suggested compromise is to have interfaces adapt over time. Applications could start out with voluminous menus when discoverability is most important, then hide uncommonly used options over time, reducing clutter as users gain experience. Microsoft tried that approach in Office 2003 without much success. It sounded like a good idea, but changing menus scared novice users and annoyed advanced users.
A variation on this approach is to make controls visible based on context rather than based on frequency of use. People find this easier to understand.
The trade-off between discoverability and clutter may be a question of where you want your clutter, in the UI or in external documentation. I suppose I’d prefer the clutter in the UI for software I use rarely and in the documentation for software I use the most.
18 thoughts on “Clutter-discoverability trade-off”
I don’t think the interface adaptation idea works for the simple reason that people like to learn how to do some particular task once and then keep doing it that way until they are dead.
It’s the same reason why accelerator keys are good in theory but not in practice: once people get used to doing a task without the accelerator keys it’s almost harder to unlearn the old way and relearn the new way than it would have been to just learn the fast way in the first place.
> discoverability in Emacs is pretty bad.
I’ve been using emacs for just about 20 years now (OM*G!), and I am a power user (by that, I mean that I’ve written maybe 4k lines of elisp in my .emacs)…and there are VAST swaths of emacs packages that I’m still not aware of.
I’m an engineer, and a lot of my time is spent inside CAD software. Most of the time I use Pro/ENGINEER, which is fairly well known for being powerful and poorly documented. Once I had to do a project in Solid Edge (SE) which I’d had no previous experience with. Overall, SE was much more user friendly, and had several featured geared towards teaching users how to use the software effectively. The best ones were:
1. “Beginner” mode: you could toggle this on and it would show command names along with icons in the toolbar, which helped users learn what each button actually did. When you were comfortable with the software, you could switch it off, which reduced icon sizes and removed icon names, giving you more screen space for modeling.
2. A “command finder”: there was a little text box that you could use to find functions and get documentation. If you were familiar with another CAD package, you could type in a command name, and it would return a list of SE functions that had similar functionality. It would then show you where that function was located in the menus or toolbars and point you towards the documentation.
3. Solid Edge had really good documentation. Pro/E doesn’t even compare. I really can’t emphasize what a big difference there is, and how much good documentation (and examples) helps users, though I’m sure that anyone reading this knows that already.
These seem like features that should be a standard part of every software package with a GUI.
I may be too out-dated but I feel the Office ’03 menus struck the perfect balance – if you want a feature, scan down the appropriate menu, exploring sub-menus as necessary (caveat – the organization and naming of the items wasn’t ideal so this is maybe why people couldn’t find the features before). My biggest issue with the ribbon is my eyes can’t scan it in a 1-D pass, it requires a 1-D pass along each column/row on each pane, making it a step back in discoverability.
Interestingly, using Control-F1 to hide MS’ discoverability-aiding ribbon bar, is not discoverable (or at least I never discovered it)!
Brandon: I agree that people tend to learn how to do something one way then stick to it forever. That suggests that software that’s easier to use at first could make things harder in the long run. (Along those lines, see Is helpful software really helpful?.) For example, I’m glad that there were no semi-WYSIWYG editors for LaTeX when I was learning it. If there had been, I might have gotten into the habit of using one and been much slower at using LaTeX. Instead I had to simply learn LaTeX.
But when I’m using some software I only need every six months, I want it to be easy to use right now, not in the long term. The trap is when you start to use something more frequently. I’ve fallen into that. At some point you need to say “It looks like I’m going to be doing this a lot, so I need to rethink what tools I use.”
Thom: I only discovered the Control-F1 trick yesterday when a colleague told me about it.
I’ve taken to using python instead of calc… can emacs run python???
You can also double-click the tabs to minimize the ribbon. Not as tricky as control-F1.
Woody: You can run a shell inside Emacs and from there run Python or anything else you want.
personally i prefer things in documentation. good documentation would go a long way in microsoft products.
thats what i love in linux, man pages. need to know how to rip the audio from a video file using mplayer? man mplayer. really if you just need to know how to do something most your answers are in the man pages. the rest are on google. if you have a really fringe case you can probably ask someone.
“The best way to discover Emacs features is to read the documentation.”
Wow. Imagine what would happen if people actually bothered to read the instructions! I am continually amazed at the almost total lack of logic being used by people lately. -I won’t bother to RTFM, I’ll just ask someone else or complain to the manufacturer- This is why http://www.lmgtfy.com is so popular among support professionals and Sr. programmers.
austin: I agree that Microsoft could improve its documentation. Lately they seem to be delegating more documentation responsibility to bloggers.
The problem with man pages, however, is getting started. You can’t just pick up a man page and read it like a newspaper. There are notations, conventions, etc. that take a while to pick up. You can bootstrap your way up, but it takes a fair amount of work. It’s a lot easier if you have someone to help you get started.
RDShaefer: I was afraid that when I wrote “The best way to discover Emacs features is to read the documentation” that it might sound like I think this is unreasonable. Not at all. I’m old fashioned enough to think that software ought to be documented and that people ought to read the documentation.
I appreciate when I don’t have to read documentation for simple tasks. Imagine if you had to read a manual for every web site you visit. But for tools I depend on to do by work, tools that I’m going to spend hundreds of using, I don’t mind reading documentation. In fact I want to read documentation on these and I’m irked when it doesn’t exist or is inadequate.
It’s interesting how over my career, Microsoft and Apple have switched places on this. I remember when Macs came out in the 80’s–really up until Windows 95–the advantage was the everything was discoverable on a menu or as an icon, unlike DOS-based programs where you needed a cheat sheet handy for all the commands. These days, I find Apple products, while beautifully clutter-free, are less discoverable; for example, gestures that involve taps or swipes with 2 or 3 fingers.
(Hope that doesn’t start a flame war!)
john: one of my best discoveries in that regard was man man where i learned the man -k. then i just think of something i want to know about and man -k [search item] takes a bit of trial and error
i learned all i know of c++ from man -k c++ and then just looking at different features (though it helped that i already grasped the basic linguistic concepts and this was all about vocabulary) and the always had code snippets that helped even more.
same way i learned to script in mirc. they have an index you can search for certain things or browse the list and see if something sounds cool, and they had code snippets and good explanations of what they did and why. i got pretty good at mirc script from that. (mirc script came first which probably helped prepare me for c++..except OOP)
documentation is one of the best things you can make, more so than the interface good documentation is greatly important.
i guess a good analogy would be a city, even the best layed out city made for optimum convenience and efficiency for its inhabitants will still be easy for an outsider to get lost in. documentation is like a map.
Several times recently I have tried to find answers to fairly straightforward questions about Microsoft products and the C# language, only to find that the most authoritative answer available was in a thread on one of their discussion forums. I found that pretty disappointing. I hate having to figure out if the five-star Most Exalted Evanglizing Wizard or the guy whose blog is titled, “The up down old new fig” is more likely to be correct, while both explicitly disclaim any characteristic of real documentation, such as authority, correctness, or completeness.
Nice article and gets right to the point.
My biggest beef with the ribbon, is the hiding of certain dialogs behind a very small little button in the lower-right corner of the sections. Took me forever to find where the paragraph and line-spaceing dialog had gone.
I have noted the office 2010 ribbon is subtly better about some of the niggles present in ’07. They have at least tried to address the undiscoverable dialogs in the 2010 version by making them look a little bit more like a button instead of a decoration. Still….ugh!
Oh, and minimize ribbon is discoverable by the small upward pointing arrow in the mdi button-row (not sure if that’s in ’07). I had discovered that first and the double-click way by accident one day. I tend to only remember hot-keys for things I do often and minimizing the ribbon happened only once and it’ll stay that way :)
Overall I feel like it’s a pretty good compromise; the awfulness of many rows of ever-present buttons (most of which are never used) is gone for good, replaced by (what is really) menus. I will even go so far as to opine they are well designed menus; it strikes me that MS Word is actually somewhat non-distracting with a minimized ribbon!
Apple has an interesting approach built into Snow Leopard: If you search for something using the live help function, it will also search all menu items and show you were they are so that you can find them again.
This is extremely handy in programs with huge menus like Textmate.
Its the first trick I usually show new apple users.
“Power users often dislike the ribbon,”
That’s not entirely true. We have complaints about the ribbon’s implementation, sure, like it taking up too much vertical real estate on these widescreen monitors everyone’s going to, and it hides way too many features making trying to adapt just as frustrating as menus… But the real problem power users have is they FORCED the ribbon on us and intentionally TOOK AWAY the “power user” way of doing things. There was no reason to strip out the old way, they could’ve lived side-by-side.
“but most of the estimated half billion people who use Microsoft Office are not power users.”
I’ll bet a majority of the estimated half billion people using Microsoft Office are still using pre-2007 versions too.