People need help finding, discovering, and using capabilities of software applications.
Surface the capabilities of your application through a tabbed ribbon using task-based grouping and informative and illustrative visualizations.
Technically, there’s more to the “ribbon” than the ribbon. Microsoft calls the whole kit and caboodle the Microsoft Office Fluent user interface, which is broken down as follows, but the main innovation in the interface (and the most notable part) is the ribbon; it’s what people remember and talk about and is why this pattern is called Ribbon and not Office Fluent UI.
The impetus behind the creation of the ribbon was an effort to make the Office products easier to learn and use. In the beginning, Office first had a simple menu as most apps have. Then they introduced their toolbars, then action panes. It got to where for some users much of the screen was taken up with these various, competing affordances, and the menus themselves were too deep and complex with many hidden dialogs. They tried “intelligently” hiding menu commands to simplify the menus, but that was not received well as it didn’t expand the hidden items in reliable places, and they more often than not did not hide the right things at the right times.
The ribbon eliminates the toolbars and the usual menus and drastically reduces the need for dialogs and action panes. It categorizes the hundreds of capabilities according to related task (e.g., inserting, layout, references, data, etc.), and provides further task-related grouping within those task-based tabs. It uses visual affordances (such as icons and previews) along with galleries and live previews in the document itself to help people more quickly find and determine appropriate commands. It hides commands that only make sense in particular contexts into contextual tabs that show only when applicable; it uses the Home tab for the most common commands (based on their extensive usage tracking data), and it uses Drop Down Button controls to show the most common commands in command groups while retaining easy access to others. Finally, it uses varying visual sizes for commands to provide further visual prioritization.
All of these things—task-based tabs, contextual tabs, visuals and previews, and research-based visual prioritization—all contribute to a much more user and goal-centric approach to surfacing the capabilities in applications that use the ribbon. If the organization in the ribbon matches the way people work, it is a no-brainer that it will be an effective tool, but it can also be a terrible choice that can make a once-fairly-usable application much harder to use if the organization does not match working styles, so use with care.
In addition, the ribbon can be a good choice to conserve space, especially if you have many toolbars or other Command Area and Button Groups implementations. It can hide all but the tab titles for minimal intrusion, but even expanded, it can end up taking less space than a menu bar and several toolbars and/or action pane (as exemplified here: http://blogs.msdn.com/jensenh/archive/2005/09/15/467956.aspx).
By far, the most critical step in implementing the ribbon is to carefully organize the capabilities of your application. It is doubtful you will have the usage tracking and testing resources at your command that Microsoft had, but you should do your best to get some real usage data and if you can’t get that, do as much usability testing that you can of potential organizations. If you’re not sure where to start, using the card sorting technique with some potential users can be a great jumping off point.
You need to think about at least two levels of grouping—the tab and the command groups within the tab. Once you have those two levels, try prototyping different layouts—paper/whiteboard is fine and probably better than jumping straight into the technology implementation. If you have commands that act on the same object or perform similar functions, consider if Drop Down Button applies.
Where possible, identify visualizations to help distinguish between commands, and consider creating galleries for commands that have varying and distinguishable visual outcomes on the same object—this helps people to predict the right choice without having to try and undo. Usability-test your low-fidelity prototypes before investing in making the related artwork for the various visualizations; you can try different combinations of icons and sizing to find an appropriate layout.
Once you find a ribbon layout that tests well, then you can design the artwork for the various visualizations and make it a reality in software. Since it is a very complex control, you should strongly consider using one provided by a third party like Infragistics or your platform vendor if one is available from them and meets your needs.
Here are some more specific guidelines:
Infragistics has some tools that can jumpstart your efforts to implement this pattern. Broken down by technology, they are as follows.
You can use the NetAdvantage for Windows Forms WinToolbarsManager to implement this feature. If you download the NetAdvantage for Win Client bundle, you can find a sample in the WinForms sample browser called IG Paint with Ribbon to see it in action.
You can implement this pattern using the NetAdvantage for WPF xamRibbon. If you download the NetAdvantage for Win Client bundle, you can find a section in the xamFeatureBrowser dedicated to the xamRibbon control.
The primary example is from, surprise, Microsoft Word. This example shows the Home tab, which should have the commands you use most often. I think they got it right with the font, paragraph, and styling groups. I guess I use CTRL-V, so having the Paste command be in the #1 spot is weird to me, but doubtless they have data to support this positioning.
This is an example from SnagIt, which moved to using the ribbon in version 9. As far as I’m concerned, the jury is still out on whether or not the tasks were broken down correctly. I customized the quick access toolbar to put the commands I use almost all the time but which are on different tabs. It’s still the best screen capture tool out there, though!
This example shows the Microsoft PowerPoint Animations tab in the ribbon. It uses an iconic gallery to suggest the possible animations, helping people to find and choose the animation that they are looking for. It also puts the Preview command in prominence on the left, which is a very common need when working with animations.
This example from Microsoft PowerPoint (though it is the same in other Office applications) shows the contextual tabs for working with SmartArt. When people select a SmartArt object, these tabs show up as contextually relevant and go away when you’re not working with SmartArt, only surfacing this additional complexity when needed and in a non-intrusive way.
In this example from Microsoft Word, note that the command groups resize differently. For example, in the “Illustrations” region, the Shapes/SmartArt/Chart buttons become smaller, but the Picture and Clip Art remain large, indicating they are the most common commands in that group.
This simple sample using Infragistics Windows Forms toolset shows the ribbon being used for a Paint-like application.
This example shows the Infragistics WPF xamRibbon control being used in a sample sales manager application, which is probably on the level of complexity you’d need to really take advantage of the ribbon well. Note the use of icons of varying sizes, the tab groups and command groups within the tabs, as well as the contextual Salesperson tab.
Jensen Harris, An Office User Interface Blog
Microsoft MSDN, Microsoft Office Fluent User Interface, http://office.microsoft.com/en-us/products/HA101679411033.aspx
Microsoft MSDN, Information about licensing the Office UI