waffle

Steven Frank lets loose on the Ribbon:

I know that Microsoft replaced the traditional toolbar with something called a “ribbon” and I’ve never understood what it’s supposed to be. It seems to be a categorized toolbar where you can arbitrarily stack icons of varying sizes, with or without labels, in whichever layout strikes your fancy.

Seriously, go look at this thing. There’s some sort of “mini toolbar” in the title bar of the window in addition to the standard window controls. (Before my fellow Mac users get too sanctimonious, let’s consider Safari 4 beta’s “top tabs”, which my internal jury is still out on.)

Then you’ve got the ribbon itself, which appears to be tabbed, and one of the tabs has what I can only guess is a resize widget. I mean what is happening here?

It is a distinct possibility that Steven has spent more time writing out that post than using the Windows version Office for the past five years, so I can’t rule out that he actually hasn’t had more than a brief acquaintance with the Ribbon, but many questions posed in the post may just as well be rhetorical. The Ribbon in Office 2007 is not perfect by any means, but it is significantly more perfect than the Ribbon in Office 2010 on the subject of tactility. In Office 2007, the definition of the whole thing is not lost in a sea of milky shades. Therefore I’m going to approach this a bit carefully.

In 2007, you can see that there’s one row-wide toolbar per tab, and that it contains several groups. In actual use, you can see that the groups on the Ribbon collapse and expand to fill the available space according to rough level of importance, and that no buttons are ever hidden behind an overflow chevron; only the entire group is collapsed. In 2007 Steven would have seen that “The Find section is, unlike all the other sections, unlabeled. It appears to contain a toggle button with a popup arrow underneath it.” — is actually a mimic of the full Find group. In actual use, you can click the “what I can only guess is a resize widget” to see that it launches the appropriate panel that correlates with the properties one would adjust or actions one would take in the group itself.

If it sounds like I’m hounding Steven for not having used the existing version, I’d like to set the record straight that I’m not. But I do think he’s being a bit unfair. I dare you to find someone who could label Coda‘s unlabelled functionality from a cursory, milked-out screenshot from the next version, and I like Coda.

That doesn’t put the Ribbon beyond blame. The Ribbon was constructed to make a drastic change in the Office user interface because the vast majority of features that people wanted were already there; you just couldn’t find them. Usability studies and science backed the design (and in the wake of Douglas Bowman’s reveal of Google’s “statistics will save your design” strategy, I should highlight Jensen Harris’ — program manager on the Office User Experience Team — quote “good UI design is one part art and one part science“), and something needed to be done. The Ribbon got a lot of things right, but it’s also only appropriate in some uses.

• The Ribbon was built for a document-based editor, where a big goal was that you could accomplish changes to the document without needing to go into “the dialogs”. This hoists a number of commands onto the Ribbon that could be hidden, even though a lot of them are hidden thanks to contextual tabs for eg. editing images.

• The Ribbon was built to consolidate everything; both menus and toolbars. The reason people got a lot of toolbars on their screen before was because it was impossible to find stuff in the menus; people had given them up for most document editing. The idea was that everything is in one place and that the tab and group organization is at least logical according to the Ribbon test groups and the impromptu “please categorize a few commands” sessions that were apparently being held when you came to test something UI-related at the labs at Microsoft. (Coda is spectacularly good at providing contextual UI, but imagine if they had to show their entire menus somewhere in a tab control instead.)

• The Ribbon was built to scale well, thanks to the constant presence of every old command and some new shortcut commands. For it to remain a constant size or not grow to ungodly proportions, this means taking up a big space and populating that.

• The Ribbon was built to have things stay where they are, because overflow toolbar menus (or “rafts”), menu personalization and the sort of stuff that tried to apply the big-scale science (which worked) on a small scale (which didn’t) gave people the heebie-jeebies. That means that when a tab is crowded, it stays crowded. If you shrink it, the groups shrink to fit, which regularly removes labels.

Most importantly, the Ribbon was built for Microsoft Word and Excel. It was not built for Coda, it was not built for Notepad, it was not built for Windows 7 Paint and the newly revealed Outlook 2010 main window (which in 2007 managed without a Ribbon) is (preliminary) the latest in a series of proofs that it was not built for Outlook either.

The Ribbon was built to solve a bunch of problems. Although the Ribbon by example also includes many other useful techniques (like live preview, “galleries” (notably absent from the Outlook message window that got Steven angry and probably the only good thing about the Outlook main window — it’s the nine actions grid thing), long informative tooltips with contextual help shortcuts and improved status bars, all supporting Jensen Harris’ claim for a “results oriented” interface), Microsoft keeps reusing the Ribbon in places where it’s far too clunky to make the other things seem worthwhile. The Ribbon needs a smaller cousin, a slimmer and better implemented toolbar that works in different scenarios.

The Ribbon, as a result of those tenets of predictability, is also plagued by the failure of a) a more customizable solution than the “Quick Access Toolbar” in the top left and b) useful command search to materialize. These two things might mess you back up, but it might also do wonders for getting used, finally, to the Ribbon, and if that fails, to reorganize it to your liking. (Update: Johan Strandell in the comments mentions the experimental Office Labs Search Commands which I have found not only the wrong solution to the right problem but is actually corrosive to the flow. Instead of teaching you where the command is located, it teaches you to use the program as you’d normally do and then search-invoke when you come upon something you can’t find, instead of learning it once quickly. It is the primary reason I said “useful command search”.)

So in short, if Steven Frank wants to call the Ribbon “UI salad”, it is fine by me since I’ve found its use in its original habitat a very desirable and nutritious salad. That doesn’t make him wrong when he points out that Office 2010 tries to sweeten the salad (…huh?), or that its use elsewhere is more harmful than good. However, I don’t believe that he was right by deliberation; I believe that he saw a cluttered UI on a screenshot and decided to rail against it. That is his choice (and archivists have unearthed uncanny evidence that not even your humble author has evaded this, although I was railing against something different than just the Ribbon itself, and although it may now be relevant that I like the Ribbon after having had the chance to use it), but it is startling to see such outburst from such a modest and reasonable man with such talent for UI (overshadowed by Cabel‘s as it may periodically be — but Betelgeuse or not, that’s still a big-ass nuclear fireball, if you get my drift).