Because You Want To, Not Because You Have To

You've written an add-in to Microsoft Word.

It creates an entry point at the bottom of the Tools menu.

"Crikey! There is no Tools menu. Call Sgt. Pepper immediately!"

We know there are thousands of add-ins, macros, and other projects that extend Office or use it to host UI.  Exactly none of these were written with the expectation that eventually they would be run in a version of Office without menus and toolbars.

At the same time, we knew that it would not be feasible (or polite) to ask people to make changes to their code just because we changed things around in Office.  Very occasionally a customer will even sadly report that they lost the source code to their crucial add-in.

So, we started designing the Office 12 extensibility story around a promise: the promise that we will do everything possible to make all existing code run untouched in Office 12.  If you want to take full advantage of the new opportunities afforded by the new UI, you do need to make a few changes.  But, as a rule, any add-in or macro that ran in Office 2003 should run just fine in Office 12.

"But how does this work?" you might be asking.  And rightfully so.  User interface extensibility in Office 97-2003 was based on the CommandBars object model, which provided access to the menus and toolbars in each application.  Your code could choose to add a button to the 7th position on the Standard toolbar, or to the very top of the Format menu.  Or anywhere else in-between.

What does asking Word to position you as the 7th button on the Standard toolbar mean when there is no Standard toolbar?  Does it mean you want to be next to Print Preview?  Or next to Spell Check?  Or, perhaps you want to be next to the special alignment toolbar button that only shows up in Japanese versions of Word?  Or maybe you just want to be in the middle of the screen?

We racked our brains trying to come up with some way of mapping CommandBars requests to organization in the new UI.  And it turned out that there wasn't really any way to do it reasonably.  We can't infer enough about what the intention behind the UI was to do something intelligent--and doing something "automatic" some of the time and getting it wrong most of the time is just about the most confusing thing possible.  So instead, we went for predictability.

Whenever code tries to add a control via the CommandBars object model (or other legacy means of adding menus such as WordBasic), we show an extra tab in the Ribbon called "Add-ins."  Two chunks can be present in this tab: Menu Commands and Toolbar Commands.  Existing code that tries to add to the old menu structure is re-routed to the Menu Commands chunk.  Likewise, adds to the Toolbars show up in the Toolbar Commands chunk.  If you create your own toolbar, it is converted into your very own chunk and all of the controls you add are inside.


(Click to view full picture)

We present a "virtual" menu and toolbar structure to existing code, so to an add-in internally it looks just like it's running in Office 2003.  In practice, only the UI added by the add-in shows up on the tab.  (If you change the action of built-in Office controls, they do show up in the Add-ins tab as well.)

The benefits: UI shows up in a predictable place.  Controls are presented in a way that makes sense depending on the control type and the required destination.  UI controls intended to be shown together remain together.  And, best of all, no code changes are required in order for UI to show up on the Add-ins tab.

Of course, if you are willing to write a small amount of code, you can upgrade your project to take full advantage of the Office 12 UI through the new extensibility model, code-named "RibbonX."

But, until you are, you can rest more soundly knowing that the UI for the WordBasic add-in you originally wrote for Word 6.0 still shows up in the Ribbon.

Crikey!