Contextual Tabs are among the most important components of the Office 2007 user interface. They provide quick access to the contextual features which work with an object, much like context menus do. When you’re working on a table, we add the Table Tools to the set of features presented. When there’s no table present, the Table Tools are gone, greatly simplifying the Office apps. I wrote a whole post detailing how Contextual Tabs work last fall.
But coming to this design didn’t come quickly or easily.
The earliest designs of the Ribbon had no concept of Contextual Tabs at all and instead had a Format tab. This Format tab changed its content depending on the object you were working with to present the features for use with that object.
This design had some major disadvantages. First, the Format tab was constantly changing its content. One of the design tenets around the Ribbon was predictability and consistency of UI–visiting a tab should always look the same. Yet, the whole idea of the Format tab violated this tenet; we had six top-level tabs which were consistent and one which was always changing. Not good.
Also, we found that the breadth of tools available to work with an object varied greatly. A simple drawing, for instance, has a relatively small set of tools, mostly formatting and aligning. A chart has most of the drawing tools plus chart-specific formatting and all of the layout and data analysis features of charting. A PivotChart combines all of the features of PivotTables, charts, and drawing into one experience. So, while a single Format tab worked OK for simple things, it wasn’t capable of supporting the feature set of rich objects.
So, we knew that a Format tab wouldn’t work and that some of the object-specific features would need to span several tabs. Our next iteration was something called Immersive Experiences, and we actually built this into the product for a while.
The idea behind Immersive Experiences was that as you started working with an object (say, a picture) the main tabs of the app disappeared and were replaced with a new set of tabs (the Picture Tools.) When you were truly working with your picture, the entire UI scoped to help you work with the picture. We even imaged totally changing the look of the app to show that you were kind of focused in on a specific object, and we spent a bunch of time thinking about how to deal with navigating back and forth between the main ribbon and the Immersive Experience.
As we got further into designing these experiences, however, we started to run into problems–both tactical and usability in nature. The tactical problems started here: You can add text to a shape. Well, if you have text, you can bold that text. So, I guess we copy the Bold button into the Immersive Experience. And Italic. And, in fact almost everything on the first tab.
But wait, it gets better. Think about tables: what if I want to put a picture in the table? I need the Insert tab also. And what if I want to change the margins of a paragraph in a text box? Well, then I need the page layout tools.
The kicker is this: in Word, your entire document could be inside a table cell. For certain kinds of East Asian documents, this is not at all uncommon. You literally need all of Word in the Immersive Experience for tables, and we kept having to move more and more of the app into the IX (as we called them).
And, as I mentioned, there were also usability problems. In particular, people felt jarred because it looked like another app launched and they wondered “why Excel went away.” The “immersive” part of the design was what was throwing people off, and it felt unnatural, off-putting, and confusing.
As a result, between our first and second coding milestone, we iterated the design again and changed Immersive Experiences to Contextual Tabs. The idea was this: if you have to enable Bold for an object, then let people use it where they’re used to it being: on the home tab. Similarly, if people want to add a comment to a table cell, why not let them do it where they always do it (on the Review tab) instead of designing some one-off UI.
Contextual Tabs, then, leave the core tabs of the program alone and simply add tabs for the object you are using. People can continue to use core commands just where they always have, yet the object-specific features have an expansive space in which to express themselves. Even better, the app experience feels more stable because the core tabs don’t change, and this was a huge step forward in usability. For the first time, people were getting how the model worked and going crazy using their newly-found contextual tools.
Beyond this point, we still had a lot to figure out in terms of how the visual design of contextual tabs and the triggers to bring them up would work, and in a future post I’ll get into these deeper aspects of the design.
Everything in this story happened well before Beta 1, and it was an incredible luxury to have a development team willing to adjust the product in such a major way once we found where we were headed wasn’t working.
For me, it helped illustrate the value of planning for iterative design.