“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.
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.
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:
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.
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.
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.
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:
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.
Consider using our Ribbon Design consulting service if you are having trouble deciding if you should use a ribbon or need help designing it.
The comments are closed.