To Ribbon or not to Ribbon? Considering the Microsoft Fluent Interface.

03/24/2010, updated 04/07/2010

Phil Gilmore

I have a friend who is obsessed with the Ribbon interface found in the latest Microsoft Office suite.  He has been heard asking “To Ribbon or not to Ribbon”.  The answer should be, as always, whatever is best, not whatever is new. 

I work primarily on the Microsoft side of the software development fence.  As a result, I’m surrounded by peers who work with Microsoft Technologies.  Any competent IT person will be vigilant in exploring new technologies.  And frankly, I like most of the technologies that Microsoft produces.  But there are exceptions.  Does anyone remember Microsoft Bob?  Have you used MS-Paint in the last 20 years?  The problem is that most people will blindly adopt whatever is new and relentlessly profess to me that I should too. 

Horse hockey!  While toolbars themselves are not necessarily the worse interface available, the .NET implementation sucks out loud.  Menus are usually a very reasonable UI element, but they’re old and many of my peers think that makes them antiquated.  I disagree.  Paraphrasing Anders Hejlsberg, “Good ideas don’t just go away”. 

So when the latest Microsoft Office came out with its new Ribbon control, I was happy to evaluate it but I was not going to blindly adopt it.  Let’s have a look at that evaluation.

First, let’s have a look at this Ribbon control.  What is it?  How does it work?  Here’s a screen shot of it in Microsoft PowerPoint (not mine… credit goes to Wikipedia, http://en.wikipedia.org/wiki/Ribbon_(computing) ).

The Ribbon control is a singular composite interface which replaces a form’s main menu with a tab page.  Each main menu item is a tab, and each tab page contains a row of toolbars.  Those toolbars can contain controls of any basic kind in various layouts.   

There’s more functionality in it than that, but my purpose today is to compare it to other interfaces.  For now, we’ll press on with the definition given above.

First, let’s consider its origins.  Did Microsoft invent it?  They say that it’s their exclusive new toy and you are required to sign user agreements with them to use this interface.  Even if you write your own to look like theirs, they think they can dictate to you that it must look and behave THEIR way.  Really?  Let’s have a look at the Delphi tool palette, introduced in 1995 (screen shot is the Delphi 7 version, circa 2002). 

Look familiar?  Screen shots don’t really do a user interface justice.  The movement and the action of navigating the Delphi tool palette interface is strikingly synonymous to Microsoft’s Ribbon interface.  There are small differences.  Each tab has only one toolbar in the Delphi 7 tool palette.  There is also a Main menu outside of it.  Each page contains only buttons rather than a variety of controls, but the tabbed toolbar itself is the same concept.  Admittedly, the biggest difference is the fact that this toolbar has a very specialized application whereas the Microsoft Ribbon has shown itself to be a fit for a more diverse set of circumstances.

Well, different is different.  But credit aside, it’s important to consider Ribbon’s origins for sake of comparing user interfaces, knowing the truth that newer is not always better.

So why did Microsoft ditch the toolbars + menus in favor of Ribbon?  Lets weigh the issues.

Searching and navigating

The standard dropdown menu can be hard to navigate if you don’t know where to find what you’re looking for.  You can only see one part of it at a time. 

Floating toolbars can show large sets of functionality to the user at the touch of a button, addressing this problem.  But toolbars have other issues.  They can be context-sensitive, meaning whole toolbars can disappear when you switch contexts, a major no-no in interface design.  Missing buttons and moving toolbars due to the flexibility provided in most floating toolbar implementations can make it even harder to find what you’re looking for.  Lastly, most floating toolbars have only buttons, with tiny icons and no captions, leaving your TOOLTIP as your best option for finding what you’re looking for, which is much worse than a standard dropdown menu.

Ribbon will happily sit in front of you, exposing whole sets of options at a time, like a toolbar.  But it’s easy to find the set you’re looking for because the menu option under which a set is found does not usually move (it may disappear, which is still bad) and has a definitive textual label.  For as many options as the Microsoft Office applications have, this is useful for normal users who occasionally have to hunt for that not-often-used feature.  The down side is, I believe that because you have several sets of uniform space in which to put things, the organization of your menu goes out the window as you’re encouraged to put things where they FIT, not where they BELONG.  Such is the case with Microsoft Word. 

Go ahead.  Open up Word and look at the Ribbon.  Pick a tab and try to guess what will be in its page.  Then take a look.  How far off were you?  The problem is that they tried to make everything fit in as few pages and groups as possible (mission accomplished) and then named each page the best they could based on what they had put there (crashed and burned).  If you look at a tab and can’t guess what’s in it, then they have defeated their purpose and might as well have used a dropdown menu.  Navigating has now become browsing.  Navigating a menu beats browsing a Ribbon.  Browsing a Ribbon beats browsing a menu, and of course floating toolbars are pretty much browse-only.

As my friend correctly points out, a menu CAN be this way as well and historically has been to some degree in Microsoft Office.  I contend that it’s worse in the Ribbon because it’s encouraged there.

Real estate

Obviously, standard dropdown menus provide the very best conservation of real estate.  They only occupy space when you navigate them.  The rest of the time, they’re collapsed to a single line of text at the top of your application and there they diligently stay without moving.

Floating toolbars and Ribbons probably occupy the same space for a given set of controls, but the Ribbon can have many more equally sized sets of controls available on other tabs.  So Ribbon still beats the pants off of floating toolbars in this regard.

Ribbon tabs can have multiple groups, and those groups are rectangular.  They contain controls of varying sizes, and those controls may not fit in a well packed manner on that rectangular group.  So there is some wasted real estate in the arrangement of these controls.  However, this is miniscule and will likely never counter the previous argument.

Ribbon has a much better ability to “shrink” large sets when the window size decreases.  Some toolbars have NO ability to do this.  Others can only collapse themselves partly.

The Ribbon can also be minimized to where it shrinks down to just the tabs.  Clicking a tab will then pop up its page temporarily, just as a dropdown menu would.  When the mouse leaves or clicks an item, it pops back down leaving just the tabs.  This potential puts it on par with menus in regard to real estate.

Aesthetics

Aesthetics are subjective, but I think that in general, these are the impressions that users have.

Newer is better.  +1 to Ribbon

Menus are old-fashioned.  But they can have pretty gradients and colorful icons throughout.  Menus also have a negative mouse factor.  That is, users must click repeatedly in small spaces  on items that tend to collapse on them if not done meticulously.  A valid point by any means.  –1 to menus

Floating toolbars CAN have pretty buttons with lots of color, but a common lack of textual captions coupled with unintuitive icons, toolbar gaps and lots of “customize” dropdowns and other weird anomalies (docking problems, disappearing toolbars, etc.) along with a frustrating user experience may counter this.   0 to floating toolbars.

Final Score

All in all, it looks like Ribbon is swinging with some big gloves.  It does a lot and does it pretty well.  It certainly looks nice and has some great functionality.  Maybe that’s why several non-Microsoft parties felt the necessity to invent it a decade or two ago :) 

To be perfectly succinct, my opinion is that there is very little reason to use a toolbar in new applications where Ribbon is available.  Menus may still be a better alternative if they are small or very deep, but consider this for yourself.  Otherwise, Ribbon seems to be a good fit for most things. 

A note about “getting used to” Ribbon.  Ribbon itself is not hard to use or hard to understand or hard to navigate or hard to browse.  The problem that I think most people encounter is in the layout of the functionality inside the Ribbon in a given application, as I have mentioned before.  Blame the application, not the Ribbon.

Other user interfaces and practical application

So far, I’ve compared dropdown menus to floating toolbars and to Ribbons.  But these are just the common elements for menu design.  What about other interface elements?  Surely there are alternatives and, surely, one-size-fits-all does not always apply to user interfaces.

Consider an application with a menu that contains 3 top level menu items, none more than 1 level deep with about 5 items each.  To use a Ribbon for this would be nonsense.  Each tab would have only one group with a few items in it.  Or you might use one tab with 5 groups in it.  Either way it’s pointless.  The menu is the better option.  And what about deep menus?  A menu system that goes 4 or 5 submenus deep probably needs revision.  But replacing that menu with a Ribbon isn’t very reasonable.  The Ribbon wants 3 levels deep.  Not 2, not 4.  There’s the top row menu item, under that a subgroup, and an item inside the subgroup.  This is a slightly limiting factor when considering the Ribbon control.  Tabbed toolbars could be considered just a Ribbon control with 2 levels instead of 3 and might be preferable over the Microsoft Ribbon for replacing a menu system with 2 levels.

Consider the Delphi tool palette shown earlier.  It’s an interesting case.  Remember my argument that Ribbon encourages you to put items where they fit instead of where they belong?  If you resist the temptation, what you end up with eventually is so many tabs that they don’t all fit in one row on the screen.  Such is the case with most Delphi installations.  Delphi developers soon had their choice of several third party plugins that allowed multiple lines of tabs so that they could fit all their component categories on the screen at one time.  This was handy but not as elegant and we still had to spend a lot of time looking for a tab and looking for our sub item on the tab page.  It also took a lot of real estate.  In Delphi 8, Borland came up with an improvement.  They ditched the tabbed toolbar ribbon-like palette entirely and replaced it with something else.

Delphi’s new tool palette interface is a simple masterpiece.  Since it only contains one type of element (Delphi components), they can exist in any category and there is sometimes no knowing in which category a component exists.  Plus we still have so many categories that you can hardly read through them all.  For real estate’s sake, the first thing they did was make each group collapsible.  The next thing they did was arrange them vertically, so that there is a usable vertical scrollbar instead of a <- and –> navigation buttons or multiple rows of categories.  This is important because the mouse has a wheel which works well with vertical scrollbars.  Horizontal scrollbars simply aren’t there yet.  Lastly, they implemented a search filter.  Because most Delphi developers know part of the name of the control they’re looking for, they can type it in and the matches will promptly appear.

This is something like a searchable outlook bar where multiple categories can be expanded simultaneously.  An Outlook Bar?  But that’s old stuff!  And yet it was a step up from the ribbon-like control previously used.  Yea, even now, Microsoft’s Visual Studio is using the same sort of interface for its tool palette in Visual Studio 2010. 

Looking at the top, you can see that I’ve typed “edit” in the search box.  With each keystroke, the list of categories shrinks and the items inside each category disappear, leaving only items that match my search.  Matching text is highlighted in bold.  This is a substantial usability improvement which Visual Studio 2008’s tool palette sadly lacks (I’m told that Visual Studio 2010 / C# 4.0 personality has this feature, although it is does not appear to be present in all Visual Studio 2010 personalities).  There is also a category selector hot button on the header.  This is useful when the categories are too numerous to fit on the screen or they are expanded, leaving a lot of scrolling to do.  Once again, a big deal and it’s missing in Visual Studio.  It is also imperative if the user base tends to know the names of the elements but not the names of the categories that they’re looking for.  Such is usually the case with RAD developer tool component palettes.

While this is NOT a better alternative over the Microsoft Ribbon for an application like Microsoft Word, it is doubtlessly a better fit for this particular application.

Making a choice

I have an in-house application I developed years ago and have been maintaining for years.  It had a familiar motive.  There were a huge number of items that a user needed to be able to find quickly and select easily.  When I started, there were just a few items, so I used a button for each.  I could have used a toolbar but that requires more real estate with captions than the command buttons do, and I didn’t have time or the inclination to create icons for non-captioned toolbar buttons.  So I used plain command buttons with text and no images, then squished them together.  You can see that while the items are terribly accessible, the UI is as pretty as a pickled pig snout.

Since I was the only one using it and it was very functional, I was happy to leave the interface like this for a while.  But eventually I needed to make these items pluggable and dynamic.  To do this, I needed a dynamic interface.  The button layout could be done dynamically, but it would look different every time and that breaks the accessibility just a little and makes it even uglier.  So I went to work redesigning the UI.  I knew that I needed categories to group these items together if for no other reason than to save real estate but also to make searching for unfamiliar items easier.  So that first thing I tried was a set of menus and submenus.  I was able to categorize things the way I expected, but not very well.  This was a step backward in usability.  The menus are not deep but they’re very wide.  Check it out. 

So I wanted to scrap the menus.  I thought about the Ribbon and I probably would have used it except that there were no good free implementations available for Delphi yet that I could find.  So I stuck with the menus and buttons for a bit.  One day I realized that the latest version of Delphi provided the same control in its tool palette that they used for the tool palette itself in the IDE.  I started playing with it and started wondering if I could use it for anything.  It was obvious.  I was doing the exact same thing that they were.  I had a list of items that belonged in categories but was too huge for items to be quickly accessible. 

I already knew their solution to be superior to the Ribbon control for this scenario.  That’s why they moved away from the Ribbon-esque tabbed toolbar in favor of this interface in the first place.  I immediately started implementing this control in my application.  It’s implemented now and pending just a few more improvements left to make it more keyboard friendly, this was definitely the way to go.  The shot below shows the application in action with a search for “c”, which filtered down to just 3 categories out of 17 with just one keystroke.  I also followed their lead and added a category list dropdown next to the search at the top.  Each category is collapsible if necessary.

I have not added all the items to the list yet, so this search doesn’t show how much improvement this interface will yield when all is said and done.  It will be much more substantial than shown here.

I’m not interested in convincing anyone not to use Ribbon.  I only hope I’ve presented sufficient rhetoric that my more sheepish peers will stop treating my more cognitively apt peers like fools for thinking twice about whether it’s the best solution.

- Phil Gilmore
- http://www.interactiveasp.net