This is a follow-up to my previous article on the Microsoft Office 2007 ribbon style of user interface (UI). It's prompted by a too-long history of design meetings where apparently everything must be reset to a previous decade, and where new people drop in to ask the same fundamental questions yet again, proposing top-of-the-head suggestions that have already been comprehensively discounted by thorough and painstaking research. A blank slate isn't always the best point of departure.
I've listed a very few, key takeaways from Jensen Harris's presentation on the history and evolution of the ribbon UI. The technology is well matured by now, and these caveats, or something like them (preferably a smallish superset), need to become integral to the our new jumping-off point.
No to the Ribbon (sometimes)
The ribbon was never just a fad to be copied, for the sake of looking like Office 2007. For many applications, those containing a few dozen operations, the menu and toolbar approach is still superior - and using a ribbon just looks silly. It's only when you migrate closer to the region of 50, 100 or more unique user-executable commands, that you should be thinking of switching to this more fluent alternative. Remember, Microsoft were driven to develop this UI by the sheer, exponentially, ever-increasing bloat in the numbers of nested menus, toolbars and task panes, in Office 2003 and its immediate predecessors.
No to Command-Oriented Design
Microsoft's Office 2007 group emphasised instead Results-Oriented Design:
- Think about features instead of commands
- Present functionality at a higher level
- Illustrate features by their results
- Use galleries to let the user close to the result they want to achieve as quickly as possible
- Visual! Tactile! Responsive!
You don't just "ribbonise" a form, any more than you "webify" an arbitrary desktop application. The most visible part of this UI design, the ribbon itself, must be supported by a host of other equally essential concepts and devices:
- Galleries e.g. for Visual Styles and Pictures
- Live Preview
- Contextual Tabs
- Quick Access Toolbar
- Mini Toolbar
- Enhanced Tooltips
- Enhanced Status Bar
- Live Zoom
- Customisable Status Bar
- KeyTips and Keyboard Navigation
- Streamlined Options
- Context Menus
What's missing is as important as what's provided. With the ribbon scheme, Microsoft got rid of more than just the endlessly proliferating dockable multilevel menus and toolbars on every side of the display; also gone is the stack of task panes. Why? Added complexity, for one thing. Task panes don't actually replace anything, they just occupy more space, less productively, giving the user yet another place to search for functionality. Remember, one of the biggest ideas behind the ribbon is having a single point of access for that functionality.
Also: in Office 2003, everybody wanted to add a whole new task pane to the stack, for just their one feature.
No to Customisation
It can seem arrogant to lock down the UI, preventing users from arranging their toolbars, buttons and menus in their "favourite" configuration, or the one deemed most productivity-enhancing (who decides?) for their specific roles or requirements. In truth, more users hate their toolbar and menu docking freedoms. For example, two features of Office 2000 designed to simplify the UI by modifying it, namely adaptive menus and rafted toolbars, actually added so much complexity and disorientation to the user experience that most customers, especially those in corporate environments, turned both off.
As Jensen Harris puts it, 99% of all users' requirements were met by their eventual "static" ribbon design. But 1% of 200 million customers is still two million people; so, the status bar, and a single customisable toolbar, were left in for just those 1%. The point to note is that Microsoft in 2007 were in the happy position of having amassed so much customer feedback (over 3 billion data sessions collected from Office users; 2 million sessions and 40 million command bar clicks per day; 6000 individual data points; etc.), they didn't have to hypothesise about such things - they just looked at the data. You probably don't have that luxury. So, it's even more important that you allow your pet UI features to be questioned. Ruthlessly tortured, in fact. Probably killed.
No to Exceptions
Design tenets have to be religion. Microsoft's design tenet set in the summer of 2003 looked a bit like this:
- A person's focus should be on content, not on the UI. Help people work without interference.
- Reduce the number of choices presented at any given time.
- Increase efficiency.
- Embrace consistency, but not homogeneity.
- Give features a permanent home. Prefer consistent-location UI over "smart" UI.
- Straightforward is better than clever.
Great blog post John.
ReplyDeleteAfter viewing the presentation myself today and now reading your post I am asking myself the question, does our product fit the Ribbon criteria?
In his presentation Jensen’s suggested that process based applications were one of the suitable targets so for that reason I’d say we do have a chance of making use of them. Given the form based style of the application and limited editing scope we will be limited as to the number of features we will benefit from. Beyond showing examples of workflow structure I can’t think of many opportunities to use galleries.
A couple of exceptions to the high number of command based apps do exist however. Look at Paint, Movie Maker or Live Gallery on Windows 7 or the new Explorer in Windows 8. Do they merit the Ribbon UI?
Cheers...
Oh, meant to say, the Task Bar (assuming you mean RHS pane) still exists in Office 2010 – Research and Thesaurus...