After four years of working almost exclusively with Macs, this summer I found myself back on a PC, using Windows 7 and Microsoft Office 2007. Admittedly this is not the state of the art, but I was surprised to find just how annoying and inefficient it was using a PC after the latest version of OSX. There are many factors to this, but one was the Ribbon in Office applications. It struck me as an extremely poor design: it was hard to find commands, hard to remember where they were and felt very inefficient.
I remember reading the articles and blogs around the development of the Ribbon and was impressed with the degree of user experience thinking that had gone into the design. So what went wrong? This article analyses the Ribbon and some of the factors that impact on its effectiveness.
The basic problem with designing an application like Word, Powerpoint, or Excel, is that there are a very large number of commands and options. How can these be presented to the user such that they can quickly and efficiently use the commands they need all the time, but can also easily find valuable, but little-used commands?
The Ribbon attempts to solve this problem by eliminating traditional menus and displaying commands directly in the UI in the form of one very large toolbar, presented as a set of tabs. This has the effect of surfacing a large number of commands to the user, as opposed to commands being hidden away under hierarchical menus. The cost of this is that the user must find the command they need amongst the many commands on offer.
To begin with, the user can attempt to find a command by quickly scanning the Ribbon. However, specific features of its design have the effect of making scanning harder:
The Ribbon is horizontal in orientation, which is more difficult to scan than a vertical orientation (in which the user can more easily fixate on the first few letters of each word). But the Ribbon is not exclusively horizontal – it also has multiple rows, with up to three commands placed one above the other.
The size and format of commands also varies: Sometimes there are three small commands one above the other, sometimes one large one. Sometimes commands are just icons; sometimes they have labels; and still others are ‘galleries’ presenting a range of related options. This variability makes it hard to scan the Ribbon and have any reasonable confidence of spotting a particular command.
Finally, the Ribbon is divided into tabs, so most of the commands are not actually visible at any one time – meaning it can only be scanned in sections.
If we scan an interface and fail to find what we are looking for, then we can enter into a more intensive ‘hunting’ behaviour, in which we actively search through the UI and look through menus and dialogs in a more structured way. The characteristics which make the basic format of the Ribbon tricky to scan make it even less helpful as a hunting interface. It is hard to actively look through every item, because they are scattered across multiple rows and presented at different sizes – there is no effective search pattern.
On top of this, although the Ribbon contains many commands which act immediately, there are also a good proportion that have a drop down menu attached to them, and many of those menus also give access to supporting dialogs. It is hard to hunt through each of these features to be sure that you have looked everywhere.
The Ribbon lacks a useful sense of hierarchy in its organisation. It is true that each tab is divided up into sections, but the section labels are placed at the bottom of the Ribbon and are given a low visual hierarchy. I find that I rarely look at them. On the plus side, this doesn’t have much of a negative impact, since the categories are not, in fact, very helpful. It is actually very difficult to divide up commands into categories and even more difficult to give those categories useful names.
The tabs themselves also ought to provide some organisation to the commands, dividing them into groups. However, the association of the commands to each tab often feels fairly arbitrary. In some cases it is clear where something should be, but far too often, it feels like guesswork.
The Ribbon is not a very efficient interface: The tab representation means that you are constantly having to swap between tabs – often the command that you need is not on the tab you used last.
For example, insertion is nearly always woefully inefficient, since you have to swap to the Insert tab, and then select the object you want to insert. Now the Ribbon is stuck in Insert mode, so to edit that object, you need to swap tabs again.
The Ribbon’s horizontal orientation also means that large mouse movements are needed to switch between tabs and access commands at each end.
Options that are specific to certain selections do not appear on the normal tabs. Instead, dedicated contextual tabs are added to the end whilst something is selected, for example, when selecting a chart in Excel.
Showing contextual options only when needed should work really well, since it simplifies the interface the rest of the time. However, it doesn’t seem to work, perhaps because those tabs are not placed in focus automatically. This means that some of the most relevant commands to what I’m doing at any time are always hidden under a different tab.
The Ribbon is the primary access route to almost all of the functionality in these Apps. This includes things that relate to editing the content of the document (for which a toolbar representation works well) and things that have nothing to do with it.
In Powerpoint, for example, to access the Master slides, you have to switch to the View tab. But then to get back to the normal view, you have to switch to the contextual ‘Masters’ tab in order to close the master view. Placing these kinds of commands in the Ribbon confuses its purpose and makes the whole application harder to use.
Only File-related commands (which are dealt with via the menu launched from the logo), and some View-related commands (which are offered at the bottom right) have escaped being incorporated into the Ribbon.
WHAT WOULD WORK WELL?
If the Ribbon is not a good approach, what would work well? Here are the considerations I would start with in designing an alternative:
- Provide quick and efficient access to frequently-used commands. They need to be visible in the UI and easy to hit quickly and with minimal mouse movement.
- Design for scannability: using a slim horizontal format for small numbers of commands and a narrow vertical orientation for more extensive sets.
- An effective response to context would need to be a core principle: serve up commands that make the most sense given what I’m working with, close to the point of focus.
- Use a progressive hierarchy for less-important items to support hunting.
- Offer a search facility to help users find commands easily.
- Consider using a different presentation for non-editing commands, e,g, view, save, zoom, print etc.
- Provide the option for the user to learn or create shortcuts for items that they use frequently (but may not be commonly-used by others).
One thought on “What’s wrong with the Ribbon?”
Hello, I don’t know if you write blogs anymore but this has been a very insightful read as I’m someone interested in UI/UX design and hope my life takes me in the direction where I can pursue such a carer. Thank you for the interesting post!