Jensen Harris: An Office User Interface Blog : Contextual UI

Usability: Art and Science

jensenh — Wed, 21 Jun 2006 17:00:00 GMT

Yesterday morning we were sitting in the office of one of our usability researchers watching some DVCAM tapes from tests conducted a few weeks ago.

We had a discussion that got me thinking about a set of tests we ran several years ago to determine the discoverability characteristics of contextual tabs.

At the time, contextual tabs were struggling in the usability lab. The visuals and triggers were not obvious enough, and even when people noticed them, the tabs looked so different from normal tabs in the UI that participants thought they were decorative or unactionable.

We kept iterating and iterating on the design, and one of the desperate ideas we had was to pop up a little yellow balloon the first time a contextual tab set appeared saying something like "Hey you, contextual tabs have appeared, you better click here get to the tools for working with your table."

(I'm sure the real wording was a lot more Microsoft-esque.)

Anyway, we wrote a little app to enable us to pop up the balloon at the right time--but it was a totally manual process. We had two keyboards hooked up to the usability computer, and when the contextual tabs appeared, one of us in the back room would press F10 on our keyboard to make the balloon appear. So the timing was a little weird, but it was cheaper than building the feature directly into the product itself.

The balloon wasn't the only change to the design in the new build being tested, however--we also tested improvements to the visuals and the triggers that activated the contextual tabs as well.

The result of the tests? The usability characteristics of contextual tabs improved dramatically.

But now we had a quandary: which improvements precisely had caused the uptick in usability? The balloon? The substantive changes to the interaction model? The clearer visual design?

One could imagine a world in which we ran controlled, double-blind studies to test the impact of each element of the design separately to assess the best possible combination.

In reality, though, we tend to use an iterative process in which we bring an entire design to a next level and then (if the design is successful) figure out which are the non-critical parts of the improvements. The advantage to this process is that it lets us move faster and abandon bad ideas sooner.

In this particular case, we felt kind of icky about the balloon, so we decided to run another set of tests to see how much not showing it changed the results from the previous successful test. It turned out that the test results didn't change at all mathematically; the usability of the feature was being impacted much more by the substantive changes to the design than by the notification balloon.

Developing a contextual tab design that worked well took well over six months of concentrated iterations, followed by tweaks over the last two years or so as we continued to make progress on the design surrounding them.

The biggest reset recently was when we introduced new visuals for Beta 1 Technical Refresh last winter and we had to reevaluate usability of the entire UI based on the new look.

Some of the most interesting studies we did were eye tracker comparison tests which enabled us to see how and where the new visuals affected the scanning pattern of the UI. It turns out that moving group labels to the bottom of each group in the Ribbon, for instance, helps people target the control they're looking for a bit faster than in the Beta 1 visuals.

So, could we apply an even more incremental method of usability confirmation to more fully test each element of a design change in isolation?

Perhaps, but a design is much more than the sum of its parts, and the usability of one piece always has to be weighed against the usability of the overall product. This is where art meets science.

There's a talk I give to program managers internally at Microsoft in which I present a 100% guaranteed way to improve the discoverability of a fictitious "Send via Telegraph" feature in Word:

You can't evaluate the usability of just one feature or component of an overall design without understanding its impact on the entire product.

Good design is the art of balance.

It's an art that can be infused and informed by scientific rigor, but in the end it's still an art.

Choosing the Contextual Colors

jensenh — Wed, 10 May 2006 17:00:00 GMT

Tonight we spent a few hours finalizing the contextual tab colors for Office 2007.

As you may have seen in pictures of the new UI, each set of contextual tabs has a color associated with it. This helps to uniquely identify each tab set for familiarity's sake as well as to group related tabs when you're using two sets of contextual tabs at once (such as a picture in a table.)

We have seven colors to distribute among the many contextual tab sets: yellow, orange, red, green, purple, blue, and teal. Because we have far more than seven sets of contextual tabs, certain objects have to share colors. In addition, certain colors (such as yellow and purple) stand out more than others (blue, teal), so we want to ensure that the most popular objects have recognizable colors. In early testing, we found a strong correlation between visible contextual tab sets and discoverability/usability of the tools.

Choosing colors for Contextual Tab sets

To avoid duplication in practice, we have a grid of object types vs. applications that we use to figure out which objects can be used in conjunction with one another. Then, we ensure that the objects that are most commonly used together don't share a common color.

We used data from Beta 1 and Beta 1 Technical Refresh to inform the decisions about the contextual tab sets that were most frequently used. For instance, it turns out that "Header & Footer Tools" in Word is used a lot more than we thought, so the fact that in Beta 2 these tools use the blue color is probably not the right thing.

The contextual tab headers up in the title bar are called "flags" by the way. I can't remember why now, but that's what we call them.

Drawn Together

jensenh — Tue, 25 Apr 2006 17:00:00 GMT

Creating a drawing in Office is different is a few key ways from other features we expose on the Insert tab of the Ribbon.

Most notably, individual shapes are usually part of an overall drawing. It's less common that someone intends to draw a solitary circle than that the circle joins together with other shapes and lines to communicate an idea as a complete drawing. Unlike a table or a picture, which is usually by itself a complete expression, shapes and lines tend to work together.

This creates some interesting usability and efficiency issues for the drawing UI. The first realization we had very early on in the design process was that drawing is a cyclical task. Unlike the simple Insert -> Format workflow of a table, the workflow for drawing often looks more like Insert -> Format -> Insert -> Insert -> Insert -> Format -> Insert -> Insert -> etc.

Sorry for another gratuitous diagram today--
I can't get seem enough of using these new Office 2007 diagram tools!

So we knew that we needed to support this process of inserting and formatting a lot of things together well. Although Contextual Tabs are a crucial part of the new user interface, they were originally conceived for use with tables and pictures, in which you tend to insert the object once and then spend the rest of the time adjusting the content, layout, and formatting.

With the drawing model, however, contextual tabs got in the way, because every switch between Insert and Format required a tab switch between the Insert tab and the Drawing contextual tabs. Although I like to point out at this juncture of the discussion that even with an added click for tab switching , the total of number of clicks required for this scenario is still far fewer due to the Ribbon, it felt inefficient for people. One thing that I've learned during this design process is that if something feels inefficient, it is just as bad as if it is inefficient (no matter how much objective proof you can offer to the contrary.)

In order to break this cyclical tab switch, just before Beta 1 we added the same Insert Shapes gallery that's in the Insert tab to the Drawing Tools contextual tabs. Now, you could insert shapes from either the Insert experience or the contextual experience, and you could perform the cycle of inserting and formatting without needing to tab switch at all.

This was also when we designed and built "lingering" into the product to help address scenarios in which you were jumping between objects in a drawing to format them in succession.

This was the state of things circa Beta 1 Technical Refresh. But the feedback kept rolling in.

In general, people liked that they could do the drawing from both tabs, but a new problem came up. Because the shapes gallery was in a different location between the two tabs, you could never dependably and rapidly move your mouse into the same area again and again to draw out many shapes. You had to insert the first shape from one place in the Ribbon and draw subsequent ones from another place.

Well, it turns out that because of the way the Ribbon scales up and down, there's only one place you can put content so that it remains constant between tabs--in the leftmost position. So, we redesigned the Insert tabs in each of the apps so that the Shapes gallery appears to the far left side. This ensures that the drawing tools remain in the same exact place in the screen regardless of which of the two tabs you're using.

The Insert Shapes gallery remains in a consistent position across tabs

Another piece of feedback we received is the importance of being able to efficiently choose exact font sizes for text contained in drawings. Prior to Beta 2, the Mini Toolbar did not include the font size picker (just a simple size up/size down set of controls). So, in order to make sure that the key text formatting controls are at hand when editing text in drawings, we added exact size to the Mini Toolbar for Beta 2.

The Mini Toolbar in Beta 2 has exact font size control

As with everything in the Office 2007 UI, we continue to refine the designs based on feedback. So many areas of the product have been iterated on as many as a dozen times as we learn more about the way people interact with the new UI and expect it to work. Beta 1 was our version 1.0 product: promising but rough.

By continuing to evolve the designs based on feedback, we hope that Beta 2 will exhibit greater levels of refinement and efficiency.

Lingering Around

jensenh — Wed, 15 Mar 2006 17:00:00 GMT

One of the key concepts in the Office 2007 user interface is Contextual Tabs. Whenever an object is selected, the tools for working with that object are made available in the Ribbon. I've talked about them in an introductory article and just last week I posted a design history of the steps we took along the way.

Table Contextual Tabs in Office 2007 - Click to enlarge picture

Diagram Contextual Tabs in Office 2007 - Click to enlarge picture

A number of people have asked the question "When do Contextual Tabs appear?" Today, I thought I'd share the (fairly simple) algorithm underlying the design.

The first, incontrovertible rule is this: whenever an object is selected, the Contextual Tabs for that item are available. You can, of course, continue to use the core tabs, but the object-specific tools are also available. This rule applies 100% of the time, for all objects in Office. Pretty straightforward so far, eh?

Most of the time, what people are really asking is: "in which scenarios do the Contextual Tabs automatically bring themselves forward?" The answer to that is a tad more complex, but still basically straightforward.

Whenever you insert an object, you are brought to the first tab of the Contextual Tab set for that object.
Whenever you double-click an object, you are brought to the first tab of the Contextual Tab set for that object.

So far, so good. There's only one additional rule:

If you deselect a selected object and then click right back on it without performing any other commands in-between, we put you back in the Contextual Tabs where you were before you deselected the object.

This third item was a feature called "lingering" that we added based on very early real-world research. What we found was that an extremely common scenario involved people using an object, clicking away from it to make the selection handles go away (to get a better look at it) and then clicking right back on the object to continue formatting it.

Before we made this change, someone would be using the Layout tab of the Chart Tools. They would click away for a second, then click back on the object and when they would go to use the Ribbon, they were suddenly back on the Sheet tab. Confusion reigned. Since implementing "lingering," the usability results on Contextual Tabs have become very solid.

So now you know the three rules which determine when we navigate to a Contextual Tab.

Picture This: A New Look For Office

jensenh — Thu, 09 Mar 2006 20:00:00 GMT

This morning at the CeBIT conference in Germany, we revealed the new visuals for the Office 2007 user interface.

You can see a few screenshots of the new look on the Office 2007 UI Preview Site. If you've got a craving to see even more, I've created a mini-gallery of full-size screenshots from a recent build of the product below.

I've also posted a guest article written by my colleague Brad Weed, head of the Office Design Group. He's penned an in-depth, behind-the-scenes look at the new visuals from his perspective as a designer.

Screenshots of the Office 2007 User Interface

First, here are some basic screenshots of the Office 2007 programs.

There are so many changes from the Beta 1 visuals that it would be hard to make a complete list, but a couple of the things you might notice right off the bat: the Quick Access Toolbar in the title bar, group titles on the bottom of groups, and the Office Button (more on that below.)

Click each thumbnail to open a full-size version of the picture.

Word 2007 - Click to enlarge picture

Excel 2007 - Click to enlarge picture

PowerPoint 2007 - Click to enlarge picture

Outlook 2007 - Click to enlarge picture

Access 2007 - Click to enlarge picture

Close-up Screenshots of the Ribbon

If you don't have the bandwidth to download the full-window pictures above and you just want to see the Ribbon, these pictures are for you.

Word 2007 Ribbon - Click to enlarge picture

Excel 2007 Ribbon - Click to enlarge picture

PowerPoint 2007 Ribbon - Click to enlarge picture

Contextual Tabs

As I've written several times here on the blog, Contextual Tabs are at the heart of the new user interface. When designing the visuals, we wanted the Contextual Tabs to feel special and part of a group--but in the end, they also need to feel like real tabs. This is one of many places in which usability results informed our visual design decisions.

Table Tools in Office 2007 - Click to enlarge picture

Diagram Tools in Office 2007 - Click to enlarge picture

The Office Button

The Office Button provides access to all of the document and system-level functionality in the program. This is where you go to start doing things with your document in Office--from simply opening a file to saving as a PDF to starting a workflow or publishing the document on a server. This is where you start a document, and this is where you finish a document.

There's so much more to write about this in the future, but here's the simple screenshot of what you get when you first click the Office Button.

Office Button - Click to enlarge picture

Adjust To Taste

In Office 2007, we've done something else that we've never done before: given you a choice of skins for the user interface. If you don't like the default blue skin and would prefer something more neutral, we've got you covered with the striking new black skin.

Going Dark in Office 2007 - Click to enlarge picture

On Windows Vista, of course, we fully support glass in both skins. I'll get you some screenshots of that in the not-too-distant future.

Coming Attractions

The team is beyond excited to finally be able to show you what we've been up to recently. There's so much to write about now that we can start showing in more detail the changes we've made since Beta 1 and how the parts fit together.

In the coming weeks, I'll detail more of the thought process and analysis that went into these designs, along with additional perspective from a few guest writers.

The Beta 1 Technical Refresh, from which these screens were taken, will soon be in the hands of our private beta testers. Meanwhile, we remain hard at work on Beta 2.

It's not too late to sign up to receive Beta 2 of Office 2007 when it's ready later in the year. I hope you'll consider giving it a try and letting us know what you think.

The Long Road to Contextual Tabs

jensenh — Tue, 07 Mar 2006 15:00:00 GMT

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.

Not So Set In Our Ways After All

jensenh — Mon, 27 Feb 2006 15:00:00 GMT

Back in the article "Set In Our Ways?" I talked about one of the design issues we were thinking about at the time--namely, whether or not it was OK sometimes to break commands out of a set.

In particular, we were thinking about the Mini Toolbar which comes up on selection and as part of context menus in Office 2007. As you may recall, in order to make the best use of the limited space available, we needed to cast a critical eye on the content included in this UI.

With many people clamoring for indent, outdent, highlighter, and styles, it seemed like a waste of space to include much less frequently-used features such as right justify and underline.

As it often does, an interesting discussion ensued, and many of you encouraged us to break with convention.

So, for Beta 2 we decided to take the plunge and really optimize around the most frequently-used commands, breaking the restriction that all of the commands of a "set" (such as Bold, Italic, Underline) have to be together.

Here's what we decided on as Beta 2 content for the Mini Toolbar in Word:

(Remember, the complete set of commands is still always available in the Ribbon--the Mini Toolbar is for super-efficient mouse access to the absolute most frequently-used commands.)

An overview of changes from Beta 1:

Styles were added (the button next to Format Painter on the top row)
Underline, left justify, right justify, and numbering were removed.
Highlighter, Indent, and Outdent were added
Center is now a toggle button which toggles between Center and Left Justify (if you click Center on centered text, it left justifies.)

As a result, the set of features available maps much more closely to the most frequently-used features in Word while taking even less screen real-estate than the Beta 1 Mini Toolbar.

We made similar enhancements to the Mini Toolbar in Excel, PowerPoint, and Outlook based on the same design criteria.

So, as always, thanks for taking the time to write your thoughts--it was because of feedback from the internal beta program as well as the discussion here that we made this change.

I'm finding the updated Mini Toolbar to be a lot more useful, especially because of the indent/outdent and highlighter that I missed so much on the Beta 1 version. And I know, based on overwhelming feedback, that many people will be happy to have access to Styles as well.

So, while I'm optimistic about the improved design, only time will tell as we get the next round of feedback based on Beta 2.

Saddle Up to the MiniBar

jensenh — Thu, 06 Oct 2005 17:00:00 GMT

Yesterday, I talked about "command loops," in which commands not available at the same time in a modal user interface can cause frustration or reduced efficiency due the mode switch required to access both of them.

When we looked closely at the command loops people were experiencing in our early Office 12 prototypes, almost all of them were related to text formatting. Someone would be creating a caption or a footnote or a comment and they wanted a simple way to access the Bold button with the mouse. (If you use the keyboard to access bold, there is no command loop because keyboard shortcuts are inherently modeless.)

Out of the search for a solution to this problem was born the MiniBar. (If you've heard the term "Floatie" before, the MiniBar is the same thing. "Floatie" was our internal name for what we're now calling the "MiniBar." Aren't names fun?)

At Microsoft, we've been using a UI mechanism we call "on-object UI" for a couple of years. For instance, when Word AutoCorrects your capitalization or spelling in Office 2003, a little tag shows up around the word that was corrected. If you click on it, a menu pops down inviting you to undo the correction or to turn off AutoCorrection altogether.

(A form of on-object UI in Word 2003)

This has been a moderately successful mechanism at exposing people to features they wouldn't normally see. But the MiniBar had a more ambitious goal: try to use the concepts behind on-object UI to improve the efficiency of mouse users. Whereas most of our current on-object UI exposes fairly obscure or hard-to-find features, the MiniBar provides access to the formatting commands people use the most.

When you select text in Office 12, the MiniBar appears "ghosted" above the text you selected. If you move closer to the MiniBar, it fades in and becomes a miniature toolbar you can use to apply Bold, Italic, Font Size, Color, etc. As you move the pointer away from the edge of the MiniBar, it fades away to nothing. So, if you don't want to use the MiniBar on selection, just move your cursor a few pixels away and it dismisses.

Here's a little movie I made that demonstrates the MiniBar in action:

(Click to view movie - Windows Media Format, 982 KB)

(You can also download the 1.2 MB high quality movie, but you'll have to have the free VMWare Movie Decoder codec installed.)

The MiniBar is designed to reduce the amount your mouse has to travel around the screen by allowing on-object tweaks to formatting. At the same time, we wanted to make sure that it's not annoying by designing it to be incredibly shy and easy to dismiss. In fact, our current feedback shows that the MiniBar is actually too shy, and we need to dial back the dismiss behavior a little bit to strike the right balance between predictability, ease-of-use, and annoyance.

We also know there are "selection readers" out there. (I'm one of them.) Selection readers are just what they sound like: people who select text in a document as they read it. Maybe it's a kind of nervous habit. For me, I think I do it to kind of help me keep my place in the document. Regardless, we knew that the MiniBar would fail if it annoyed the "selection readers", and we've gone out of our way to try to make it undisruptive.

Of course, if you think having the MiniBar come up on selection would annoy you no matter what, you can turn it off. We've added the MiniBar to the top of context menus as well, so you can turn off the on-object MiniBar and still only be a right-click away from top formatting commands. But most people who have used it, including those who were initially very skeptical of the concept, have come around to make it a major part of the way they work.

I do love the thing and it drives me crazy not to have it when I'm using earlier versions of Office.

Dialog Launchers

jensenh — Tue, 27 Sep 2005 17:00:00 GMT

A common question I hear: "Are there dialog boxes in Office 12?"

The answer is a definite "yes." Dialog boxes remain a part of the Office 12 user interface, and many of the "tried-and-true" dialog boxes from past versions of Office remain untouched in Office 12. The dialog box has proven to be a useful paradigm for presentation of advanced functionality and thus we've left it to play that role in Office 12. What we've tried to do through the use of galleries and better-scoped features is to reduce the amount of time you have to spend in dialog boxes, especially for frequently-used functionality.

In today's world of menus and toolbars, the entry points to dialog boxes are divorced from the efficient way of performing commands. For example, in Word 2003 most people know how to use the Bold and Underline toolbar buttons. But what if you want Double Underline? Or Strikethrough? These uncommon font styles are only available in the Font dialog box, and your knowledge of the location of the Bold button doesn't help you find the related advanced functionality which is located in the "Format - Font..." menu.

Similarly, if all you want is a simple alphabetical sort in Excel 2003, you can use the Sort Ascending toolbar button. As soon as you want something more complex than that, you have to dig through the menu structure to find the more powerful version, tucked away on the "Data - Sort..." menu.

The Office 12 UI introduces a concept called the "dialog launcher", which formalizes the relationship between the efficient presentation of functionality in the Ribbon and the advanced version in a dialog box.

Each "chunk" in the Ribbon can have a dialog launcher which leads to the dialog box which maps to a chunk's functionality. In this case, the Font chunk on the Write tab in Word contains a dialog launcher that navigates to the Format Font dialog box in Word:

(click to see full picture)

If you know where the simple version is, you know where to look for the advanced version. Similarly, every gallery that has a more advanced set of settings or choices in a dialog box contains a dialog launcher at the bottom of the gallery:

(click to see full picture)

As you can see in the previous picture, the dialog launcher at the bottom of a gallery is called "Advanced." One of the current topics of discussion internally is what to call these and deciding how important it is that they are standardized. "More Columns", "Advanced", "More", "Columns Dialog Box", and several other variations are all in the running.

Our internal design criteria for when to use dialog launchers is: "only when the dialog box cleanly supersets a chunk or gallery on the Ribbon." What we don't want is people feeling like they have to check every dialog box in the product as part of scanning for a certain feature. So, when the mapping isn't totally clean, we don't expose the feature as a dialog launcher and instead leave it as a normal labeled command.

The dialog launcher is a simple concept that helps make the interface of Office more logical. It was designed to help people become proficient at finding advanced functionality when they need it in Office 12.

It's All About Context

jensenh — Fri, 16 Sep 2005 23:30:00 GMT

Right-click contextual menus were first introduced in Office 4.x (which included Word 6.0 and Excel 5.0) and went on to become a ubiquitous part of using software starting with Windows 95. The basic idea behind context menus was to give power users a more efficient way of executing commands. The concept of "object-oriented" design, both in programming languages and in user interface design were starting to hit their stride.

Back in the early days of context menus, however, we couldn't have paid real people to click on them. Had we given people an electric shock when they used the right-mouse button (ala Dr. Venkman at the beginning of Ghostbusters) context menus couldn't have performed any worse in the usability lab.

Then, over time, something interesting happened. More and more people would come into the labs versed in the language of right-click. Even people we considered "novice" users were regularly exercising the context menus. Today, more often than not, people try right-click almost before anything. Right-click, right-click, right-click.

Why has this revolution come about, and how does the new Office UI take advantage of it? It turns out the answer is only superficially rooted in efficiency and is, instead, all about context.

Let's say you insert a drawing of a circle into your Word document and now you want to put a border around it. A program like Word has well over a thousand discrete commands. Where do you start searching? The menus? The toolbars? If the toolbar you need isn't up, you need to view the full list of 30+ toolbars in the View.Toolbars dialog box. Maybe there's a Task Pane to do the formatting? Once you do start surfing the menus and toolbars, you'll see that more than half of the commands in the product are disabled. Your search is going to encompass hundreds and hundreds of commands.

Now, right-click on the circle. A menu of only 9 commands comes up... and every command is relevant to the circle. Simply by right-clicking, you've reduced the scope of your search from the entire product to just the tools relevant for a drawing. It turns out that people are not right-clicking primarily for efficiency gains; they're right-clicking because that's the best way they've found to get their work done. Unfortunately, with the exception of a few one-off commands like "Cut" or "Delete", context menus are often a series of links to dialog boxes in which you do the real work. So, you actually have to use a more inefficient and advanced UI (the dialog box) by choosing the context menu, but it's worth it because at least you found what you're looking for.

The Office "12" UI introduces a concept called "Contextual Tabs." The way it works is this: The default tabs for the application contain only the commands that are not object-specific. It turns out that this drastically simplifies the functionality you have to look through because so much of Word, for example, only works when you have a Table or a Chart or a Picture or a Header or a Drawing or a Text Box selected.

Whenever you insert or select an object, the Contextual Tabs for that object appear next to the main tabs in the Ribbon. It looks like this:

(click to enlarge)

The Contextual Tabs contain all the features you need for working with the selected object. When you deselect the object, the contextual tabs go away because all of the commands would have otherwise been disabled. If you reselect the object, of course, the tools come back.

The result is this: the core product is drastically simplified. You don't have to scrounge through hundreds of disabled commands when you aren't working with an object. On the other hand, as soon as those tools are relevant (e.g. when you're working with a Table), they come into view. When they no longer could work, they're out of your way.

Contextual Tabs combine the discoverability advantages of context with the ease-of-use and efficiency of the Ribbon. Context Menus are great and are still a part of Office 12 (and are even being improved, as I'll discuss down the road), but we've taken advantage of what we've learned about the value of context and applied it to the core of the new interface.