RibbonX lets you do a lot of things, but which ones are the right ones? How should your add-in behave and integrate itself into the Office UI? Where should you place your add-in? Which modifications are ok, which are not?

Today I am going to address all of these questions. In a more generic sense, I am going to talk about the User Interface Style Guidelines. As further reading on this topic, I suggest the Microsoft UI Style Guide. I should say though that this post goes beyond the style guide.

When you take RibbonX into your hands, the deciding factor on what you should do is whether you control (directly or indirectly) the Office application. You control the Office application, if

• You are writing a full-fledged application based on it. The two most notable examples are Access applications and Excel dictator applications. In both situations, your code completely takes over the Office application frequently to the point where the user does not even recognize anymore that there is an underlying Office application.
  
• You are dealing with your own Office.
• You are designing the corporate “look” of an Office application. Many corporations choose to roll out Office applications with a set of add-ins and with a UI that is customized to the needs of the corporate users.
• You are developing a template or document that is rather unique and offered in a corporate environment. A good example for a rather unique template is Word’s Blogging feature which displays a very different Ribbon. However, this template does not fit into the controlled category per se, because a user could install add-ins that modify the Blogging ribbon. If the Blogging template were to be used in a corporate environment with IT preventing the user from installing any add-ins him- or herself, then it would be controlled.
• You are developing an add-in for a corporate environment. Generally, corporate IT controls which add-ins can be installed and hence you have some control about which other add-ins are changing the user interface.

You do not control the Office application, if

• You don’t know and/or can’t influence what other add-ins, documents and/or templates might be installed in any Office application.
  
• You are not developing for one particular client. That means, you are developing a commercial add-in that is available for anyone who wants to have it (via a free download, buying it, etc). If you are developing a customized solution for one particular client, you might be dealing with a controlled situation, but not necessarily.

The distinction between controlled and uncontrolled is crucial, because in an uncontrolled situation you don’t know (and have no way of finding out) what other add-ins, documents or templates might be doing to the User Interface. You also don’t have any way of figuring in changes to the basic User Interface by Microsoft (Office 14 might seem far away, but your program might be around a lot longer than 2-3 years on a machine. MS is skipping #13). In addition, you cannot control which locale (User Interface language) a user is running your add-in with. With Office 2007, changing the UI language is as simple as a few mouse-clicks. For example, I have the US English version of Beta 2 with the German language pack installed. While all Office applications are closed, I can change between US English and German in Start, All Programs, Microsoft Office, Microsoft Office Tools, Microsoft Office 2007 Language Settings.

If two add-ins (I am going to refer to templates, documents and add-ins that modify the Ribbon simply as add-ins. MS calls them “solutions” in their documentation) modify the same element on the Ribbon, the last one to load wins. As you cannot control nor predict whether your add-in will be the last one to load, this is an extremely indeterministic situation and one you should avoid at all cost. Therefore whether you are working in a controlled or uncontrolled situation, keep your UI modifications to a minimum. Let me know discuss the implications of both situations and then talk about modifying the Ribbon UI in general.

Controlled Situation

In a controlled situation, you could do whatever you wanted. I say could, because you should restrain yourself and follow the following guidelines:

• Do not use RibbonX to restore an Office 2003-like UI. This might be tempting to avoid the training costs associated with upgrading, but it is not a forward looking investment. Future upgrades from Microsoft will probably require additional work. Most importantly though, you are not reaping any benefits from the new UI design. If you want an Office 2003-like UI, stick with Office 2003 and do not upgrade.
  
• Follow the UI design principles I am going to outline later. You want to make sure that your UI is similar in behavior to the Office UI, so that users can transfer their knowledge of how to use Microsoft components to your own. Users might have no familiarity with the Office 2007 UI experience currently, but they will for sure have some one year from now and they will expect an identical behavior from your program.
• Do not use the startFromScratch attribute for the ribbon tag unless you are developing an application based on an Office application. startFromScratch truly means that the ribbon starts from scratch. This is a killer approach when you have to deal with more than one add-in, even in a controlled scenario. Avoid it, avoid it, avoid it. If you have to use it, remember that you should ensure that only one, namely your, add-in contains RibbonX. If you use startFromScratch in a scenario with two or more add-ins modifying the ribbon UI, you are setting yourself up for a disaster.
• Decide carefully about what you place in the QAT. There are only 40 spots and every one you use is one less your user has available. Users can place any ribbon control on the QAT and might want to make good use of this, even in a strictly controlled corporate environment. In contrast to previous Office versions, your users won’t be able to mess up most the User Interface and generate lots of support requests when they cannot find things anymore. You should leave them therefore some freedom to do with their QAT what they would like to do. Microsoft preloads the QAT with four controls (for some ribbons six). I suggest that you keep the number of preloaded QAT items to less than 15 (including the Microsoft ones). Note that you can only modify the QAT, if you are using startFromScratch.
• “Everything starts from the Ribbon”. While Microsoft didn’t follow this mantra 100% of the time (there are commands that are not in the Ribbon, but can be added to the QAT. Some exist by default only in the QAT, namely Undo and Redo), you should try to follow it as best as you can. That means, do not put a control only in the QAT. All your controls should either be in the Office button menu or on the ribbon and only added to the QAT as an additional location to find it. That means, do not use the QAT as the primary and only location for a functionality. Remember that a user can remove any item on the QAT with a right-click followed by a left-click and if that was the only place where a user can access some functionality, then this functionality is now gone to the user and he or she probably needs support to get it back.

Uncontrolled situation

In this kind of situation, you really have to be a good Office citizen. The most important guidelines to follow are the following:

• Do not use startFromScratch. Period.
  
• Do not put anything in the QAT. The QAT is for the user to use, not for you to advertise your add-in. If the user wants to put any of your functionality in the QAT, he or she can do so manually. You however should never touch the QAT with RibbonX. Note that you only could modify the QAT if you are using startFromScratch, which you should never do in this situation.
• Remember, your add-in is not the most important thing in the Office User Interface. Don’t make it prominently available just because.
• “Everything starts from Ribbon” applies as well obviously.
• Follow the general UI guidelines outlined below.
• Make your add-in fit in with the rest of Office 2007.
• Mark your add-in clearly as such in the UI. If your add-in blends seamlessly with Microsoft feature and there is no way to distinguish your add-in from any MS component, then your users will first go to Microsoft for help. Microsoft’s website already gets more traffic than your website, so why increase this even more? To mark your add-in, include the words “add-in” somewhere where the user can see it. For example, include it as part of the Group label. Or add a labeled menu separator to the top of a menu like I did for my own add-in:

  

• Tell your users how to get in touch with you. For example, my add-in includes an About button that shows a dialog with my website on it.

Repurposing Commands

RibbonX lets you “hijack” any MS command and redirect it to your own add-in. As with any RibbonX conflicts, if two add-ins repurpose the same command, the last add-in to load wins. Except of a controlled situation, you should never repurpose a command. Even in a controlled situation, repurpose only when there is a very good reason (your own application based on an Office application is the only one that comes to my mind). Whenever you repurpose a command, the original functionality of the command is no longer accessible to the user or any other add-in at all. There is no workaround, the access to the Microsoft functionality is gone while your add-in is loaded (a bug in B2 seems to give access to the original MS functionality using shortcut keys). Repurposing is tempting, but here are two examples why you should not use it:

• Word 2007 has built-in functionality for Citations & Bibliography. That functionality though is inferior compared to a full fledged citation manager like EndNote. EndNote comes with an add-in for Word to easily insert citations into documents. It would be tempting for EndNote to repurpose the Word 2007 controls for citations & bibliography on the References tab with a new version of the EndNote add-in to provide seamless integration into Word 2007. What happens though if the user gets a document that was created using the built-in feature? If EndNote repurposed all the built-in commands, the user won’t have any way of editing those citations, because access to the MS functionality would be gone. Repurposing becomes an even more problematic situation, if another citation manager, RefWorks, decides to do the same (ProCite and Reference Manager are two other well-known citation managers, but EndNote and those two are from the same company). If a user installs both, then the user might have one day access to EndNote via the built-in UI items and the other day to RefWorks, simply depending on which add-in managed to load first that day. A much better solution would be for EndNote and RefWorks to each add its own group to the References tab and leave the MS commands alone.
  
• On the Mailings tab, Create group there is a control for Labels. As you might know, the label manufacturers provide add-ins for Word that are designed to work specifically with their labels. What if two label manufacturers, Avery and Herma e.g., decided both to repurpose that particular control to provide access to their custom label wizards? If a user installed both, which is quite plausible, he or she would have access to only one of the two wizards again depending on the load order of the add-ins. The user would also lose access to the MS label functionality.

Home Tab

If you want your add-in to be visible immediately when a user opens a Ribbon application, where do you put it? Of course on the Home tab. Are the commands of your add-in among the 80% most used commands when you count all MS and add-in commands? No? Does your add-in provide functionality that is similar to the functionality of the MS commands on the Home tab (or expands on it, e.g. a button to paste special as image)? No? If you answered no to both, then what is your add-in doing on the Home tab?

Do not put your add-in on the Home tab simply because you want users to be able to find it. Advertising your add-in is not a good reason to clutter the Home tab. Be a good Office citizen and remember that the Home tab is for the functionality that a users access 80% of the time.

Your own tab

It is tempting to create your own tab, but do you really need it or do you just want to advertise your add-in (as it would be prominently displayed in the tabs at all time)? The rule for creating your own tab is simple: If you can fill the tab, then make one, otherwise don’t. If your add-in can be categorized into any of the existing tabs, put it there except if you really need the space of a full tab. A full tab generally has at least 3 groups (a tab that is full but has only one group is a sign of a poor layout). Full means that when viewed with a 1024×768 resolution (the MS target resolution for the Ribbon UI), you cover at least 70% of the tab space (I made up that number, but that is my estimate how full the least full MS tabs are).

Your own group

Your own group is generally a good place to put your controls. The question is mainly where to put your group. If your functionality fits into any of the existing tabs logically, then put it there. Otherwise, use the Add-Ins tab. Remember that your functionality might fit logically best into a contextual tab, because it is only relevant when a picture, chart, table, etc is selected. If your add-in is limited in functionality to any of the built-in objects that have contextual tabs, then you should definitely place it there.

MS groups and controls

You cannot modify any MS groups directly. For example, if you wanted to add a paste special as image button next to the paste button in the clipboard group on the home tab, you’d have to make your own group and put it next to the clipboard group as you cannot modify the Microsoft group. What you could do is hide the MS group and create a new group that contains all the MS controls plus your own one. While this would conserve space, you should never do this in an uncontrolled situation. If you do this, you rob any other add-in from access to that particular group and you really don’t know what other add-ins might do. It is feasible that another add-in will display the Clipboard group again, if it loads after yours. In that case, the user would now suddenly have two Clipboard groups.

Avoid hiding or disabling MS controls and groups in a non-controlled situation. Again, you don’t know what other add-ins will do and what the overall effect for the user will be.

Use as little space as possible

Space is a premium on a tab. Microsoft groups will shrink in size and make space available for your groups (to see this effect, just make a window slowly narrower and watch what happens to the Ribbon). You cannot shrink your own groups automatically though. If your group uses a lot of space then that means that one or more MS groups shrink if the screen resolution is 1024×768, the screen resolution you should target in a non-controlled situation. As MS groups shrink though, the user has to click twice to get to the same functionality that he or she could get to with one click before your add-in was added. If your add-in uses space too freely and forces the user to click too much, the user might just get annoyed with your add-in and your add-in will get uninstalled. Remember that space is at a premium and it is your job to use it wisely. Also remember that yours might not be the only add-in on any particular tab using space. You should consider using a menuButton, splitButton or a dynamicMenu for all your functionality to use as little space as possible.

Add your functionality only once

There really is no need to put your functionality in more than one place, except if you are working with some contextual tabs. For example, the Format contextual tab is repeated almost identically for SmartArt graphics, charts and shapes. If your add-in extends the functionality offered on that tab, then you should add it to all relevant tabs.

However, there is no reason to put your functionality on two regular tabs. Put it only in one.

Visibility

You can change the visibility of tabs, groups and controls dynamically. Don’t. If you go through the Office UI, you should notice that no group, tab or control ever disappears or appears magically. If something is not available, it is visible but not enabled. The rule is: From the time you open a particular ribbon to the time you close it, the visibility of your items should not change (exceptions below). Don’t change the visibility of your controls ever during runtime. You should determine the visibility once and then leave it at that. As an example, the Ink group on the Review tab is only visible if you have a Tablet PC, but this visibility is never altered during runtime. Office determines at startup whether you have a Tablet or not and sets the visibility accordingly.

In Outlook, the same ribbon should always look the same as well. Keep in mind that Outlook asks you once to specify a particular ribbon and even though the user can close the window with that ribbon, Outlook never asks you again. Why should you not change the visibility? The Ribbon UI is all about the user finding features. If your UI elements are visible, but not enabled, then the user knows that the functionality is there, but that he or she cannot use it currently. If your UI elements are not visible, the user will go searching for them and become frustrated. Your user will even be more frustrated if one time they are suddenly there and another time they aren’t. Remember that whether something is visible or not might be logical to you (as it is context dependant and you know what the context is), but to your user this might be totally random and only a source of frustration.

There are exceptions to the rule of course. It could be that a certain user action triggers a fundamental change. For example, you might require the user to log in somewhere and after a successful login, a lot more functionality is available to the user. This is a stretch and a situation you should try to avoid, but it would be a case where you might be able to get away with changing the visibility during runtime. Creating your own custom contextual tab is an example too. I will show you in a later post how to do that.

Changing UI elements dynamically

You might want to change UI elements dynamically in a rather drastic manner. Again, don’t. Look at the Office UI itself and you will see that no group (including all controls, labels and icons) ever changes during runtime. The reason is the same as with the Visibility issue.

If you have to change your UI dynamically, do what Office does: Change a menu. You might notice that the menus that you can open from Ribbon buttons change their content frequently yet the buttons themselves stay. You can do the same by using a dynamicMenu.

To sum up: Leave your groups and controls visible and unchanged during runtime. Use a dynamicMenu to deal with dynamic UI modifications.

Office button menu

Again, the Office button menu is no place to simply advertise your add-in. Add commands to it if your add-in affects the entire document. As you can see from the built-in menu, sharing, printing, sending, saving, opening are there instead of in the ribbon.

Custom Task Panes

According to the Office UI style guide, you should use a Custom Task Pane, if “your solution needs to present data about a document that is required to be visible, in a non-modal fashion, use a custom task pane. However, only display this task pane based on user actions. Also use if you need to use custom controls that are outside of the Ribbon control set.”

No surprises

The Office UI style guide summarizes this one best: “Task panes or dialogs do not appear automatically on document open. Only user actions should open and close task panes or dialogs. Ideally, all task panes are opened using a button in the Ribbon. For example, clicking the launcher button on the Clipboard group open and closes the Clipboard task pane. ”

Switching a tab

I showed you in an earlier post how to switch a tab into the foreground. What I didn’t talk about was when you should do that. Almost never is the answer. You should only trigger a tab switch when you are dealing with your own custom contextual tab (again, how to do that in a later post) or when you had to reload your add-in and need to get back to the tab the user was on when you triggered the reload (when you reload your add-in, Office switches back to the Home tab). I’ll save the reason for why you’d want to reload your add-in for later as well.

First tab

What I didn’t mention yet is that Office doesn’t necessarily treat the MS Home tab as the Home tab (the one it shows at startup and returns to by default). Rather, the first tab is treated as such. That means you could create your own tab, put it in order before the Home tab using insertBeforeIdMso=”Home”. The answer to when you should do this should be rather clear by now: Never, except in a controlled situation and even then very sparingly (think, your application based on an Office application).

I can’t think of anything else right now. If more comes up later, I will edit this post.

Edits

• Edited to include the information that the QAT can only be altered via RibbonX, if startFromScratch (=”true”) is used. (June 18, 2006)