The Long Road to Contextual Tabs

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.

Click to view full picture

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.

Comments (17)

  1. Nikhil says:

    Gotta say, the contextual tabs are a killer feature. very helpful in the beta 1 builds and i hope it continues to impress!! Great work guys.

  2. I noticed a while ago that most of the format “commands” in Office are really attributes or properties of objects: weight of text, color of outline, position of legend, etc. Rather than menu commands or modal dialogs, it makes more sense to have a properties pane or modeless dialog for manipulating them. That’s one thing I’d keep open almost all the time. Like a MS Windows Properties window, the application can add sheets as necessary for the class of object, allowing consistency within each sheet across classes while supporting differences in attributes among classes. Looked at this way, your contextual tabs make perfect sense and represent a significant improvement.

  3. Jon Peltier says:

    Michael –

    "… it makes more sense to have a properties pane or modeless dialog for manipulating them. That’s one thing I’d keep open almost all the time."

    You mean, like the tearaway formatting menus in Office 2003 (font color, line or fill color, autoshapes, align, rotate/flip, etc.)? These are long gone from the Office 12 interface, and sorely missed.

  4. Ben R. says:

    You know, reading about the ideas you’ve rejected is at least as interesting to me as hearing about what will make it into the final product, because it gives us a chance to understand your team’s thought process. I’d love to see more posts like this!

    For example, what (other than IX) has been the largest, longest-developed idea you’ve rejected so far? Do you expect to make any major changes at Beta 2 (or even after?)?

  5. Abigail says:

    Has the MiniBar (a.k.a. floatie) eased the loss of the tearaway tabs at all?

  6. Abigail:

    I can’t see that the MiniBar will ease the loss of tearaway tabs if it’s not customizable (which it isn’t).

  7. Shirley says:

    I didn’t get to take a lot of HCI courses when I was in school, but I found myself learning a lot about UI design from your posts. Thanks!

  8. One of the key concepts in the Office 2007 user interface is Contextual Tabs. Whenever an object is selected,…

  9. Another misconception that I read is regarding the new Ribbon interface: some people apparently are expecting…

  10. Yesterday morning we were sitting in the office of one of our usability researchers watching some DVCAM…