Using the Microsoft Ribbon without anyone getting hurt

Designing an effective Microsoft Fluent/Ribbon toolbar is not for the faint of heart. You need to understand your users’ activity in detail and plan a consistent overall experience.

I’m working on two WPF applications at the moment. For both, we have to decide whether to use traditional File/Edit/View menus or an MS-Office-style ribbon. It’s not an easy decision…

MS Office Fluent Interface Ribbon
A piece of the Ribbon, from MS Excel 2007

Pro: It appears to be built on a sound theoretical basis and Microsoft tell us they’ve researched it to death with hordes of real users. They also say they’re planning to use it more widely.

Con: Key players on both the teams I’m working with are against the ribbon. They say “I use Office all the time and I really don’t want one of those things on MY software.”

Con: Jakob Nielsen raises an eyebrow that a number of the best new applications of the year use ribbons. He points out that Microsoft have not always come up with the best interface innovations in the past. Pro: But he grudgingly admits that maybe “the Ribbon has legs”.

Con: Some surfing around yields plenty of blogs posts from frustrated ribbon users.

Pro: The techsmith team implemented a ribbon on snagit 9 and say their research showed it worked well.

Con: And a couple of bits of software that allow you to replace the ribbon in MS Office 2007 with a more traditional menu bar. That’s a sign that there’s a potential market of people desperate enough to pay to get rid of the ribbon.

So what’s going on?

Good if used with UCD

My analysis: The ribbon is a decent piece of interface, but like most things in UX, it’s hard to design it well. And to design it well you really have to understand your users’ needs, behaviours and work practices.

That’s because the ribbon tries to show commands grouped together based on what users are most likely to want to do. So in Word 2007, for example, there’s a tab for mail-merge, and one for page layout and one for referencing, whereas in Word 2003 those features are pushed lower down in a more generic menu structure. If you get the groupings right, your users will always find the selection of controls they need right there in the ribbon. But if you misunderstand what they need to do, they’ll get an irrelevant list and you’ll get complaints.

Microsoft have got a lot of it right, but a bit of it wrong.  And with Office’s massive user base, an angry, vocal minority is still a million people or more.

Three ways to get Ribbon design wrong

  1. Choose groupings that don’t mirror real-world workflow. If you group menu options together in ways that don’t reflect the way that people really work in the real world you’ll cause frustration.  PowerPoint 2007 Beta 2 had some problems with this.
  2. Make groups the wrong size. If a group isn’t properly broken down it could end up displaying too many icons on the ribbon at once, making the ribbon hard to scan. Making groups too small means people might have to hunt through have too many tabs with not much on each.
  3. Options that move about too much. If the same control appears in different areas of the Ribbon for different tabs, it becomes hard to know where to look to find what you want. For example, in PowerPoint 2007, the shapes gallery appears on several tabs in different places. If I’m in format mode, I’ll find my shapes on the left. But on the home tab, I’ll find them on the right. This makes the core activity of drawing a shape surprisingly hard to engage in. I think this sort of thing is what makes some people complain that they “can never find anything” in Office 2007.

Powerpoint ribbon: Same controls, radically different locations depending on context
The shapes gallery appears on the left of the format ribbon and the right of the home ribbon. This makes it a lot more effort to locate a key feature in PowerPoint 2007

This last point is, I think, the key issue that makes me feel uneasy about the Ribbon. As humans, we’re not very good at remembering which mode or state a machine is in. We need to look at indicators and control panels to see it. But we are quite good at remembering where a given resource or tool sits in our environment. This is because of the way things behave in the real world. Our frying pan doesn’t magically reposition itself on the hob just because we pick up some bacon. It stays put in the cupboard and we know where to find it.

So with interfaces, we might well expect that the controls we want will be in a fixed place. Remembering what mode a piece of software is in, and remembering a different control layout for each mode, is just too much. If we look up at the Ribbon and (fail to) see controls in unexpected places, it causes cognitive friction.

Update: guidelines from Microsoft

I’ve discovered some updated guidelines from Microsoft that really help. Along with other nuggets, this one addresses dockable palettes issue below…

Ribbons must be used in place of menu bars and toolbars. However, a Ribbon may be combined with palette windows and navigation elements, such as Back and Forward buttons and an Address bar.

The opposite of dockable palettes?

Dockable windows or palettes are by definition always there, regardless of what mode the application is in. That’s very different from the spirit of the Ribbon, which is supposed to be all about contextual relevance. Can the two co-exist?

Snag-It 9 seems to have included dockable windows in their interface. And even Powerpoint does actually have a few non-modal dialogs (windows you can leave open all the time while you’re doing other things) – the format shape dialog, for example. So perhaps it’s ok.

Proceeding with caution

I think I’ll suggest using a Ribbon for the applications I’m working on. We’ll need to look carefully at sensible task groupings, and make sure that features don’t jump around too much. Then usability test it a lot.

If I find any specific reasons why the Ribbon doesn’t work, I’ll post.

5 thoughts on “Using the Microsoft Ribbon without anyone getting hurt

  • October 9, 2008 at 8:48 am

    I think you hit the nail on the head.

    What might be interesting to test is to see the core difference between people that like the Ribbon and those that don’t. It might be that the first group “looks” wider, while the second group are very specific where they look at, and if you shift things around it (cognitive friction) affects them a lot more.

    It might not be that simple, but if you can lower the friction and remove any connotation with the Office Ribbon (which comes with preconceived ideas that the Ribbon doesn’t work), you might convince them. Call it a “Task Flow Menu” or something. :)

    A question I would like to ask is how is a Ribbon different from a standard hierarchical menu? The only difference I see is that the “sub categories” are displayed horizontally (saves space) instead of vertically and that the choice for the menu’s main grouping is task driven.

  • October 13, 2008 at 7:41 am

    Thanks AJ. Yes – the ribbon is really just a double-tab with some magic bells and whistles. But changing from file/edit/view to double tab is a big jump for the desktop software metaphor.

    Further experimentation has shown me that ribbons and dockable panels DON’T go well together at all. There is conflict about where the “master” icon for a given function should live.

    Also, since one of the applications I’m working on will use a lots lists (a bit like Photoshop layers) it’s not at all clear to me how to represent those in a very horizontal space.

    So the prognosis for the ribbon in at least on of the apps is not good.

  • November 4, 2008 at 7:23 pm

    I suspect that everyone except Microsoft can have good success with the ribbon approach.

    The problem for Office is that it is so well known and widely used. People have ingrained habits and muscle memory for Word, Excel etc.

    That means that any significant change to Office has to be several magnitudes better just to be considered ok by the average (experienced) user.

  • November 7, 2008 at 12:34 pm

    I guess the future bastardisation of the Ribbon would be mini-Ribbons (which will replace dockable panels).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>