Even before Microsoft has chosen the ribbon component as the emerging trend in its desktop applications, it has spent significant resources not only on the design itself, but also on the painstakingly elaborate user interface design guidelines. The complete document for “Office Fluent UI” weighs in as a 119-page PDF, and it looks like much of the specification is going to find its way into the main MSDN site. There are numerous commercial offerings of compliant implementations available for .NET, Delphi, and even Silverlight developers, and the companies behind these offerings make sure to provide the checklist of features that are enumerated in the official guidelines.
The ribbon component is still being met with a lot of criticism from the developers (and on a personal note, my wife disliked it so much that she reverted to Office 2003 even though i had two more installations). Realistically speaking, though, Microsoft is here to stay, at least in the near future, and while the blogosphere may pat itself on the back for “burying” Vista (am i the only one that didn’t have any problems worthy of mentioning over the last 20 months, or is it just the silent majority that couldn’t care less about “Vista is teh fail” hoopla), it is going to continue setting the de-facto standards for the majority of user-facing applications.
According to Microsoft, one of the main reasons behind the rather strict design guidelines for the ribbon component is that once the user has a firm grasp on the ribbon concepts (presumably from Office 2007), the learning curve for other ribbon-based applications will be much less steeper. While most of the UI concepts behind the ribbon can be found in older applications, most of the users find themselves at odds with a large variety of the new ways to interact with Office – the application menu button, the quick access toolbar, contextual tabs, mini toolbar, galleries and automatic resizing. A consistent user-facing behavior of these features is a key element to well spread user adoption of ribbon-based applications, and may be one of the reasons why Microsoft has invested so many resources in both creating the UI guidelines and pushing the concept down to the bundled Windows applications.
A few weeks ago a chance had me stumbling across AutoCAD 2009 (whereby my lovely wife was faced once again with the ribbon). Autodesk is the world’s largest design software company, and its flagship AutoCAD software line is ubiquitous in the engineering industry. Going back to 1982 (predating even Photoshop), it is estimated to have more than a billion active files. If you think about applications with a large user base, AutoCAD would certainly be on that list. And so it is even more surprising (at least to me) that the latest AutoCAD 2009 release is using the ribbon component as the default UI.
Matt Stein is a senior product designer working in Autodesk and the two-part interview (part 1, part 2) published in June 2008 is a must read for the design teams considering switching their products to use the ribbon. In the beginning Matt mentions the same “feature bloat” problem that has made AutoCAD prohibitively complicated for novice users. Over a thousand commands, random floating toolbars and pallettes in user-submitted configuration screens, stacks of docked vertical and horizontal toolbars – these are the same problems that were discussed at length by Jensen Harris (design lead for Office 2007). It becomes more interesting after Matt has this to say:
The Office Ribbon is such a radical departure from the existing paradigm of menus and toolbars and is deployed so widely that the ribbon interface will eventually become mainstream. From a consistency standpoint that made sense — many of our users have Office and AutoCAD running side by side. Having the applications behave somewhat consistently is important. Does this mean we follow Office to a T? No.
Once it was decided that we would go with our take on the ribbon — because the Office Ribbon was not entirely sufficient — we did our own due diligence and research into what an AutoCAD ribbon would become.
If you read the rest of the interview and spend at least a few minutes with AutoCAD 2009, you would see that the “somewhat consistently” is an overstatement. Let me show you a handful of screenshots that illustrate how different the AutoCAD 2009 ribbon is from Office 2007 ribbon.
It starts off quite innocently with the default UI for editing a new empty document (click to see the full size):
While the appearance of most of the elements (gradients, curved corners, title bar and the application menu button) is not as polished as Office 2007, the ribbon is easily identifiable. It becomes more interesting with the little gear button in the bottom right corner. It allows switching between the different workspaces. One of the workspaces is the 3-D, which presents a ribbon with completely different contents:
And yet another option which has been fondly named as “putting things back to normal”, that reverts AutoCAD to the old menu bar / toolbar UI:
The little down arrow to the right of the tabs allows switching between three different ribbon modes: full, panel titles and tabs only. The panel titles mode is not present in Office 2007 and shows the tabs as well as the titles of all the panels of the selected tab:
In this mode, moving the mouse over a panel title slides out this panel (unlike the full slide out in the minimized Office 2007 ribbon):
Moving the mouse over the panel title that has the triangular arrow and the panel slides out even further revealing additional controls:
The slide-out functionality explicitly goes against one of the basic Office 2007 ribbon tenets – all the available commands are visible when the relevant tab panel is showing. The panels slide out even in the full mode. Here is a screenshot of the Draw panel in full mode (note the triangular arrow in the bottom right):
And here it is when the mouse is clicked over the title panel:
The pin button in the fully expanded panel allows pinning down the slide out state, resulting in an unpleasant jagged footprint of the ribbon:
The square application menu button is nothing more than the traditional menu bar shoehorned into a two-level presentation with the sliding tree on the right hand side. Office 2007 puts only a few chosen commands there, each one accompanied by a rich description.
Perhaps the biggest departure from the Office 2007 ribbon is that AutoCAD 2009 allows floating its ribbon and docking it on all four sides of the application. Here is the floating ribbon:
And here it is vertically docked on the left:
Furthermore, individual panels can be “torn off” the ribbon and become floating windows (bringing back the one of the original pain points mentioned by Matt). The screenshot below shows one panel already torn off, and another being positioned to be grouped with it (you can have multiple panels floating independently):
Finally, contextual tabs have also received their share of rework. Matt specifically mentions that having the contextual tab take over the entire ribbon has not agreed with the user requirements, and the resulting implementation looks a little odd (but perhaps the usage patterns justify this). Once the contextual tab is shown, its panels are always present to the right of the panels of the currently selected tab – see the panels with the light blue titles on the right hand side of the ribbon:
Finally, AutoCAD provides complete freedom to arrange the ribbon contents as the user sees fit. In addition to floating, docking and tearing off individual panels, the user can hide specific tabs and panels. Furthermore, AutoCAD 2009 provides a UI to rearrange the contents of the panels themselves:
Is it worth bending the guidelines for the user requests? Is it worth restricting the user freedom to provide experience consistent with other applications? Do you make a clean cut away from the traditional menu bar / tool bar / palettes approach, or do you provide a way to switch back? Are you prepared to invest significant design effort in restructuring your UI around the ribbon guidelines, or are you willing to take shortcuts as you see fit? These are interesting questions, and AutoCAD 2009 has made quite a few far-reaching choices as far as the compliancy with the Microsoft guidelines goes.
I have already written about the Ribbon control reaching beyond Office into the core applications that are scheduled to be shipped in the next Windows version. This is gaining even more traction with the inclusion of Ribbon in the official MSDN Windows Vista User Experience (UX) Guidelines. It had been also known as Command Bar and Fluent Interface in the different UI Design Guidelines, but it appears that the name “ribbon” is back.
The current preliminary documentation does not only provide the answers to “how”. One of the more important aspects is answering the “when” and “what not to do”. The introductory section delves into the different questions that must be considered before using ribbon in your application. And while the subsequent sections are mainly focusing on the different UI elements of ribbon, they also provide the “correct” and “incorrect” usages of these elements. Here are three examples of incorrect usages from the document:
This is a mockup design of “ribbonized” calculator that clearly has nothing to gain from putting the controls into a ribbon. Following the usual physical layout of the calculator buttons allows users to quickly discover the functionality; there is enough space to arrange all controls so that they can be accessed with a single click; the number of commands is relatively low (in tens); finally, there is no “content area” for the calculator – the result is just a wide single line text box.
Here, the application menu button is added to a window with a menubar. The UX Guidelines are strictly against combining the application menu button with a menubar or a toolbar. In this case, the application menu button aims to replace the “File” menu, but all the other menus are still there.
Here, all the buttons in the ribbon are menu buttons displayed at full size. According to the current guidelines, you might as well use the menu bar and save the vertical space.
The “Program Command Patterns” document delves even deeper into making the decision on presenting the UI commands, discussing when it is appropriate to forgo the ribbon interface and use the more traditional elements such as menu bars, toolbars and direct command controls.
