Today I present guest writer Savraj Dhanjal, Program Manager on the Office User Experience Team. He is one of the members of our team focused on user interface extensibility for Office developers.

Articles on the Office 2007 user interface developer story will be published every Thursday for the next few weeks.

Today's Guest Writer: Savraj Dhanjal

I'm Savraj Dhanjal, and I'm a program manager on the Office User Experience team. At the start of the Office 2007 product cycle, I worked on the technical framework that underlies the new user interface, and then I started working on UI extensibility--making sure existing solutions still work and can be updated to work well with the Ribbon.

You've probably asked yourself: "when am I going to learn about how to create my own ribbon tabs, groups, and controls, so I can harness the power of the New UI in my Office 2007 add-ins and solutions?"

You've read about all of the cool aspects of the new user interface from this blog, so as a developer, you want to know how you can update your solutions to work with the new UI. If you're not a developer, well, you may still find the discussion interesting.

Enter the new UI extensibility model, code-named RibbonX. Optimized for common developer scenarios, we built RibbonX from the ground up, just like the new user interface itself.

As with all of the components of the new UI, the extensibility story was subject to the same "first-principles" scrutiny that every other feature received. Did we even need a developer story for Office 2007? Was it really used in the past? Would custom Task Panes be the solution which obviated the need for a UI extensibility story?

Many of these questions came up because the last time UI extensibility was actively worked on was early in 1996, when the shared UI team rolled out the CommandBars object model. CommandBars attempted to unify the various UI extensibility models of the applications. After its release, we made a few tweaks, but as far as we were concerned, it was done, and most of the original people that worked on it moved on.

In researching the question of whether the UI extensibility story was a necessary component of Office 2007, we began to realize how silly the question was in the first place. It became quite apparent that, in the ten years since CommandBars, hundreds of thousands, if not millions of solutions were built on Office, and almost all of them changed the UI in some way. Even though the first Office Developer Conference was in 2005, the notion of Office as a platform had been around almost as long as Office itself.

So it was obvious that we needed a developer story. Again, like all of our other features, we wanted to know what didn't make sense with the existing model, so the new model would be free of these issues. Furthermore, we wanted to understand what developers were trying to accomplish, so that we could optimize for common scenarios. We turned to our customers, partners, and MVPs to understand the problems with, and uses of, UI extensibility today.

We viewed the entire spectrum of Office extensibility, from the small freeware add-in that sprinkled a few buttons in the menus, to the whole hog remake of Excel that created a fully customized application. We uncovered issues with solution localization, control repurposing, end-user customization, consistency between the Office applications, and “housekeeping”--making sure buttons only appear when your solution is loaded, and disappear when unloaded. We found that it was hard to create a well-behaved add-in, and the right way to do it differed between the applications.

We also found developers isolating menu and toolbar changes from the core of a solution. Developers created solutions where the UI is represented in a text or proprietary XML, so the UI can be updated without the overhead of rebuilding and redeploying an add-in. At first we thought it amazing, until we remembered that keeping UI separate from code is a good development practice. In fact, the Ribbon internally is built on markup--Office developers can change the layout of the Ribbon without going near core application code.

Taking all of this in, the extensibility feature crew was tasked with building an extensibility story while UI itself was still being designed. We knew that our model should focus on consistency across all applications, close integration into the new UI, optimization for common scenarios, and allow for well-behaved add-ins by default.

The feature crew set to work and exposed an XML schema that allows developers to create their own tabs, groups, and almost a dozen different control types, far more than the set of five custom controls offered by CommandBars. Since add-ins give us markup that contains customizations, it's easy for us to fix all of the housekeeping issues: when the add-in disappears, the UI disappears with it, and then markup is also easier to localize, understand, and manage.

Here's the XML required for the special group shown above.

<customUI xmlns="">

    <tab idMso="TabEnterData">
      <group id="myGroup" label="My Code"
        <button id="myButton" 
               label="Hello World!" onAction="Hi" 
               size="large" imageMso="WebInsertHyperlink" />


In many ways, the model continues to evolve and improve, and we on the extensibility crew are still hard at work building the extensibility model, so stay tuned for more posts on how you can harness the power of the new UI.