Going Gray

One of the key design tenets of the Office 12 user interface is making sure that the set of features you need to look through is as small as possible. Communicating the relevant features makes the program feel smaller and simpler and saves you time in finding what you're looking for and discovering what's possible.

Contextual Tabs are the most crucial piece of this puzzle. By showing the Picture Tools only when they could possibly work (i.e. when you are working with a picture), and doing the same with all other objects, the core Word/Excel/PowerPoint experience is vastly simplified.

But there are other details to which we have attended in order to help work towards this design goal. A key advance is the work we've done to support top-level command disabling.

Here's an illustrative experiment. Launch Word, and then click Close on the File menu to close the empty Word document. Word is still running, but no documents are open--something we call the "fishbowl."

Now, drop the Insert menu. Most things are disabled, but some commands are not. Picture and References, for instance, remain enabled. So, hover over those menu items to reveal... oh. Actually, everything on the Picture submenu is disabled after all. In fact, everything on the Insert menu is actually disabled, but you have to visit the entire menu hierarchy to reveal that fact. This is just the way dropdown menus work, and it can be confusing and frustrating.

And why do menus work this way? Not a usability reason, but a technical reason. Back in the earliest days of hierarchical menus, checking through the entire hierarchy looking to see if all the children (and children's children) were disabled would have been an expensive and potentially slow process. A trade-off was made to reduce usability in order to improve performance.

Flash forward to today. In the Office 12 Ribbon, any time all of the descendants of a control are disabled, the top-level control is also disabled. This can save you an time digging through the UI trying to figure out which feature you want to use. Communicating the disabled state at the top level means having a more accurate picture of what's available and what's not without wasting time and clicks. And, of course, in many common cases we try to communicate why a feature is disabled through Super Tooltips.

This is another example of one of those little details we hope will make an impact in making Office simpler and more usable.

Comments (27)

  1. Dan McCarty says:

    "Back in the earliest days of hierarchical menus, checking through the entire hierarchy looking to see if all the children (and children’s children) were disabled would have been an expensive and potentially slow process."

    I understand how this would’ve been an issue about 7 or 8 years ago. Office menus, in particular, were some of the slowest menus to load. But the reality today is that

    a) Computers are fast enough to walk the menu list and look for all children

    b) Flyout menus very rarely* go more than two levels deep (so we’re not really talking about the unlimited case)

    I think it’s just one of those overlooked features that didn’t change with the times. Or worse, perhaps, it’s a case of the monekeys and bananas (http://www.kettering.edu/~jhuggins/humor/banana.html): MS left it that was because it always _was_ that way.

    It’s also laziness on the part of the programmers. If you’re writing code to disable all items in a submenu, it’s not very hard to get the parent menu item and disable that as well. (The harder case is if you’re enabling/disabling items one at a time and you need to check if all the siblings are disabled.) Or, on the OS/framework side, EnableMenuItem() should track whether all siblings are disabled and disable the parent.

    I can’t think of anyone that was ever bothered by this "problem," but it’s good to see that we’re changing for the better.

    * IE View…Encoding…More is the only example I can think of.

  2. This is a great idea, but one quick question:

    If a top level menu is dissabled, can u still open it to look what is inside it?

  3. jensenh says:


    There are no top-level menus in Office 12; all the features are in the Ribbon.

  4. Tiago Ribeiro says:

    Should I assume that the a ribbon tab will disappear if all the options in all the chunks are disabled ?

  5. jensenh says:


    Nothing ever “disappears” at any level, it just shows as disabled. If everything in a tab were disabled, the tab would still allow you to click on it, but everything in the tab would be grayed out.

    But looking through the products, I don’t really see a case where this would happen when working with a document.

  6. Centaur says:

    By the way, in Office 2003, if you open Word or Excel and close the last document, you no longer can configure the application with Tools|Options. That’s not nice.

  7. "Contextual Tabs are the most crucial piece of this puzzle."

    So when we’re creating solutions which add custom tabs that only make sense when a specific workbook is active, can we also make those tabs appear in the same "contextual" style that Office uses, and control when they appear, disappear and are active? Or is this another of those "One story for Microsoft, another for the addin developers?" things.

  8. Anthonye says:

    I’ve always had a love/hate relationship designing user interfaces when it comes to greying out commands.

    Sometimes it is not immediately clear to a user why a command is greyed out. And because it is greyed out, there isn’t a obvious way to tell the user why they can not perform the action they want to do.

    However, always having commands enabled, and then popping up dialogs to tell a user, for example, "the clipboard is empty" seems to be a relatively weak alternative as well.

    I have always struggled with trying to establish a better paradigm. I am interested to see how successful super tooltips will be.

  9. MSDN Archive says:

    *cackles madly*

    Note: Access was already doing this in the last (and probably before that) version.

  10. jensenh says:


    Contextual Tabs are object based, not sheet/document based, but we are considering on similar capabilities for dynamic UI extensibility that will allow a similar experience.

  11. Mats Gefvert says:

    Go Seahawks. 🙂

  12. It’s good to hear you’re considering the possibilities for dynamic UI. Wrt contextual tabs, I guess it all depends on what you mean by "context". Built-in contexts could be "Is a picture selected", "is the active cell in a table", "is the active cell in a pivot table". But when users are interacting with my worksheets, there are also lots of contexts that I define – such as whether the active cell is inside the P&L summary, or whether it’s in a specific type of sheet (say a P&L detail sheet), etc. We should be able to define a context and display custom contextual tabs that appear exactly like the built-in ones.

  13. Ben R. says:

    I think what Brandon was trying to ask is whether you can still open a gallery even if the "button" that opens it is disabled. (What’s the terminology for the different kinds of choices the Ribbon presents?)

    Also, what happens when ALL the contextual tabs in Word are showing at the same time? Is there room on the screen? This may seem like an unusual situation, but if a user has a 75-page document with complex formatting and presses Ctrl-A, every contextual tab will have to appear if every object that can be created exists in the document (not all that unlikely).

  14. MSDN Archive says:

    Ben R. –

    I think it’s actually not possible for all the contextual tabs in Word to be showing at the same time. The situation you describe is a situation where none of them would be showing. If you select all, what are you going to do with drawing tools?

  15. jensenh says:


    Actually, CTRL+A doesn’t select all the objects in Word. It selects all of the text.

  16. loki says:

    Jensen, any luck convincing Joe Friend to restart his blog? There must be something new in Word 12, I bet!

  17. Ben R got what I meant (mostly). To clarify, you state: "In the Office 12 Ribbon, any time all of the descendants of a control are disabled, the top-level control is also disabled."

    Can you provide a concrete example of this?

    And in that situation, if the top-level control is disabled, can I still explore its descendants?

  18. Expanding on what Stephen was asking earlier:

    in Word/Excel 2003, we could use XML-aware smart documents to display relevant UI in the task pane based on a custom XML schema. Will we be able to interact with custom Ribbon tabs using this model? Have my custom Product Actions Ribbon (I CAN have a custom ribbon, right?) show as a Contextual Tab whenver the user moves the cursor inside a <Product> node in my document?

  19. mentas says:

    [snipped Beta 1 bug reports from “mentas.” mentas, please report bugs through the provided beta feedback channels. thanks.]

    Im waiting Beta2.. but still working on Beta1. Office “12” are great and the best!

  20. Paul Morriss says:

    I’m glad you’re revisiting decision to see if the assumptions they were based on are correct. I’m sure there must be a lot of code out there to cope with the days when computers were slower, memory was scare etc.

  21. PatriotB says:

    Dan McCarty – It’s easy for applications that have 100% control of their menus to know that they can disable an entire submenu.  However, since Office 2003’s menus are so customizable, there’s no way of knowing whether the user added (for example) the "FileNew" command to the "Insert" menu.  If they did, then the Insert menu needs to stay enabled in order to reach the FileNew command.

    Just shows that customizability has a price.

  22. David Walker says:

    PatriotB: "there’s no way of knowing whether the user added (for example) the "FileNew" command to the "Insert" menu."  

    There’s no way of knowing?  Sure there is.  The code can simply LOOK through the Insert menu to see if the FileNew command is there.  

    In fact, regarding the original comment that described the new behavior in Office12, it doesn’t really matter if the user customized the menus or not; the code can simply look through each top-level menu and see if *whatever sub-menus are present at the moment* are disabled or not, and base the enable/disable decision for each menu on that.  Simple.

    David Walker

  23. I’m interested in what Brandon and Stephen are discussing because, as a Word MVP, I’m constantly referring to toolbars and menus to answer questions from users. For this reason, I keep Document1 open all day (because many menu items are unavailable when there is no document open in Word). I suspect, however, that in Office 12, I’ll have to open my Test.doc document (which contains tables, text boxes, headers/footers, footnotes, etc.) in order to be able to access all the relevant menus and dialogs. Naturally, context sensitivity makes sense for users, but it does make support more difficult.

  24. Stevbe says:

    I started thinking about Suzanne’s great comment.

    I hope that super tooltips (or whatever you are calling them) are available for *presents* wrapped inside a disabled ribbon tab … oh … wait … is there a way for me to get to ribbon tabs that are out of context so I can take a peek at *everything*. Informally I provide Office support because I have used it for so long that I have at least seen most of the menu and toolbar items so I know the kind of things that exist and know where to find them or what to look up in help.

    While I can hope that the new UI is so good that people won’t need to ask me Office questions any more … I would change the monkey and banana story to  … 5 bananas beat a person into acting like a monkey …

Skip to main content