UX Design Edge

The politics of ribbons

“Everything is best for something and worst for something else. The trick is knowing for what, when, for whom, and why.”—Bill Buxton

The ribbon UI, introduced by Microsoft Office 12, is a great interaction innovation. Many teams are starting to adapt ribbons in their apps. This is good when it’s appropriate, but unfortunately that isn’t always the case. Doing the right thing can be especially challenging when politics enter the picture.

A brief history of application commanding

Historically, GUIs started with menu bars, which do a great job of hierarchically presenting the complete set of commands that apply in a context. A major problem with menu bars is that they take a lot of work to navigate, so a typical command takes at least three clicks to execute. Toolbars solve this efficiency problem by displaying iconic commands directly on the surface—requiring only a single click to execute. Their problem is that they don’t scale well, so toolbars usually display only the most commonly used commands. Happily, menu bars and toolbars are very complimentary, so using them together can give both comprehensiveness and efficiency.

The classic menu bar/toolbar combo worked well for Office for many releases, but at some point Office apps had so much functionality that this solution started to break down. Jensen Harris does a great job of explaining the problem with The Story of the Ribbon. The Office ribbon scales much better, is much more flexible, has much better labeling, and requires users to look for commands in a single, consistent place. Throw in advanced features like galleries, live preview, dynamic sizing, and enhanced tooltips, and you’ve got the potential for a great user experience.

To love a new UI is to abuse it

So with all this great innovation, what’s not to like? The ribbon has one significant strike against it: it is the heaviest commanding solution there is. A good UX design principle is to use the simplest, lightest weight solution that does the job well, so applying this principle suggests that—given its weight—a ribbon should be among last commanding choices, not the first.

Another challenge is that we have a natural tendency to abuse new UI. The “new UI abuse cycle” goes something like this:

• We discover a new UI
• We apply the new UI sensibly and strategically
• We fall in love with the new UI, and start to apply it foolishly
• Given all the abuse, we fall out of love with the new UI
• We abandon the UI, perhaps for the next new thing

There are many examples of such abuse, tooltips being my favorite. Given all the useless, annoying, unnecessary tooltips out there, you’d swear the guideline was “always provide a tooltip, no matter how useless or annoying.”

Redundant, annoying tooltips are “the worst for something else.”

Fearing this sort of abuse for ribbons, I came up with this example when I wrote the ribbon guidelines when I was at Microsoft.

This is obviously crazy, right?

This example makes a compelling case that not every app should have a ribbon.

So, should your app use a ribbon?

The Windows ribbon guidelines have a useful checklist of factors to consider when deciding to use a ribbon. If your app can really benefit from a ribbon, go for it! The challenge is the marginal situations, where you could use a ribbon but possibly shouldn’t. If a ribbon isn’t appropriate for your app, most likely it’s because it’s solving problems your app doesn’t have—adding unnecessary complexity along the way.

A better question: does your VP think your app should use a ribbon?

While at Microsoft, I observed that teams would make a sincere effort to do the right thing. They would apply the ribbon guidelines, consider alternative solutions, and choose the best approach for their customers.

That is, until they had an executive review, which would tend to go something like this:

VP: So, we’re using a ribbon for the next release, right?

Team: Umm…we looked into this carefully, applied the ribbon guidelines, considered the alternatives, and decided a ribbon really not a good choice because…

VP: We’re using a ribbon.

Team: But using a ribbon would cause problems with…

VP: We’re using a ribbon. Make it work.

Executives believe that ribbons have strong customer support and will make even the most dated app feel modern. Furthermore, Office is using it and no executive ever lost his or her job by copying Office. Ship the next release without a ribbon and there’ll be some ‘splainin’ to do. Execs don’t like having to do any ‘splainin’.

I’m a strong believer in user-centered design—executive-centered design, not so much. The problem with this approach, of course, is that such executive mandates completely ignore the nature of your application, its commanding needs, your target users, their goals, etc. This is now purely a political decision. Still, this type of decision making happens all the time, so you have to deal with it.

Four reasons to proceed with caution

Don’t be stupid over this—if your VP insists on using a ribbon regardless of its appropriateness, it’s not worth falling on your sword over. If you work hard enough, you can make it work. But if you are fortunate enough to have an executive that listens to reason, here are four solid arguments you can make for proceeding with caution:

• Designing a useful ribbon takes lot of work. The Windows ribbon guidelines stress that a successful ribbon will most likely require a complete redesign of your application. Great ribbon-based apps add value through surfacing buried commands, making commands easier to find, and advanced features like results-oriented commanding and live preview. Most apps can’t support these without a significant redesign. (If adding a ribbon to your app was really easy to do, that should tell you something about the value of the ribbon.)
• Change is bad unless it is great. A not-so-great ribbon is just a fat toolbar that fails to improve the UX significantly. Such ribbons are more likely to upset experienced users than impress them. Even if you are aiming for a lower bar, it’s worth noting that even a “just OK” ribbon is much harder to design than an acceptable menu bar/toolbar combo. It’s going to require a lot of design work, user testing, and iteration to just get to OK.
• Ribbons aren’t really modern UI. Yes, ribbons are more modern than menu bars and toolbars, but that’s not saying much. Make a list of all the apps and web sites that you think have modern user experiences. How many of them have ribbons or anything even similar? None, I bet. When was the last time you used something like an iPhone app and thought “I wish this app had a ribbon”? Modern UIs are characterized by simple, lightweight, contextual, direct/touchable, dynamic experiences—pretty much the opposite of ribbons. Complex, heavy, out-of-context, indirect commanding is old school.
• Ribbons have a significant opportunity cost. Rearchitecting your app to create a great ribbon UX means that you aren’t using your limited resources to be great at something else. If you are in a competitive market, doing so could put at a significant disadvantage.
  Consider Office itself. If you’ve used Office extensively over the years, you know that there are literally hundreds of small, annoying problems that have largely gone unfixed for the last decade. (There are too many to list, but here’s one example: try creating a Word doc by copying and pasting bits from other Office docs without any tweaking—the results will look like a ransom note. Paste is the top command in Office, yet it continues to do the wrong thing by default.) As much as I like the Office ribbon, I’d prefer a product that has nailed basic functionality even more.

If you do only one thing:
If your app can really benefit from a ribbon, go for it! But if not, be fully aware of the challenges and proceed with caution. Either way, adapting an effective ribbon is going to take a lot more work than you expect.

We’re here to help

Consider using our Ribbon Design consulting service if you are having trouble deciding if you should use a ribbon or need help designing it.

• 1 Comment »


• Design guidelines, UI design, UX design