Hello World, For Real

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="https://schemas.microsoft.com/office/2006/01/customui"><ribbon>  <tabs>    <tab idMso="TabEnterData">      <group id="myGroup" label="My Code"               insertBeforeMso="GroupEditingTools">        <button id="myButton"                label="Hello World!" onAction="Hi"                size="large" imageMso="WebInsertHyperlink" />      </group>    </tab>  </tabs></ribbon></customUI>

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.

Comments

• Anonymous
  March 16, 2006
  Great intro to extensibility here. Thanks!
  
  Quick question: What kind of thought did you folks put into how new chunks would effect ribbon usability.. for instance, when new chuncks are added, they force others to get smaller..
  
  thanks-
  -Dave

• Anonymous
  March 16, 2006
  I like the idea of being able to manipulate the Office UI with XSLT.

• Anonymous
  March 16, 2006
  The obvious related issue is how Office 2007 behaves when add-ins from prior versions are installed.
  
  I know that you addressed this issue in a previous article (http://blogs.msdn.com/jensenh/archive/2005/10/27/485597.aspx) written back in October, and I wondered if there were any changes to how later builds utilize the "Add-ins" tab.

• Anonymous
  March 16, 2006
  Real Nice Job with the extensibility part.  I was just wondering how the developers were going to play around with office 12.
  
  Probably the greatest part of all is that this ribbon thing is not located in the registry.  I believe nothing should be located in the registry.  Not even settings.  The only thing that should be there is if there is an interaction with the OS.  Such as in registering new document extensions.  I do not know how many times I have seen that after uninstalling a program and then reinstalling it, the settings remain.  
  
  They should be just made as basic files in the folder of the installation.
  
  Keep that in mind for the new office 12

• Anonymous
  March 16, 2006
  Nice overview, Savraj.  I look forward to reading these Thursday posts, this is a great idea.

• Anonymous
  March 16, 2006
  One question... What happens when a developer needs to design an add-in for Word 2007 that needs to be backwards compatible with older versions of Word?
  
  Is there a way for the add-in to determine which version of Office is running, and thereby make an appropriate decision about which UI to use (CommandBars versus RibbonX)?

• Anonymous
  March 16, 2006
  But what about manipulating the ribbon via code? Are we still able to enable/disable a button at runtime? Or make buttons conditionally appear?

• Anonymous
  March 16, 2006
  The comment has been removed

• Anonymous
  March 16, 2006
  This kinda resembles how you use overlays in Firefox to modify the browser UI. I approve of this choice. :)

• Anonymous
  March 16, 2006
  The comment has been removed

• Anonymous
  March 16, 2006
  Hey everyone,
  
  Thanks for all of your comments! Here's a rollup of responses-
  
  Scaling: Yup, custom groups on built-in tabs do not scale, so the built-in groups get smaller to make room. So custom groups effectively get the highest priority.  This is how it works now, it's not to say that we can't add scaling for custom content in the future.
  
  The Add-Ins Tab: Yes, based on feedback we have updated the add-ins tab so it can handle a larger number custom toolbars before it starts scrolling.
  
  Multi-version Add-Ins: Yes, without diving into the details, it's possible to make a cross-version add-in. You can query the version of Office using Application.Version.
  
  Via Code: Yes, you can enable / disable your own buttons and built-in ones at runtime, and you can make custom controls, groups, and tabs conditionally visible at runtime. More on this in an upcoming post for sure.
  
  The list of what's not possible: That list has honestly not been finalized yet, because we’re still working on the model.  In fact, we’re working to incorporate recent feedback we’ve received. :) I’ll stick to what we can do in future posts, to minimize the chance of making posts obsolete in the future.
  
  Thanks again for the comments and stay tuned for more!
  
  Savraj
  
  

• Anonymous
  March 17, 2006
  I am also concerned about the cross-version addin. So if i change my (existing) addin to extend the Ribbon(let's say add a button or tab) will it still come under the Add-in tab or will Office automatically recognize it as an addin for  office 2007.
  
  Looking forward for more stuff from you.

• Anonymous
  March 17, 2006
  I too am concerned about cross-version support, particularly if it requires us to use xml formats and the down-version importers. Hopefully Savraj has added something like Auto_Open() to ask the VBA code in the workbook for the CustomUI XML when it opens, rather than only being able to read it from a custom part in the new xml format.

• Anonymous
  March 17, 2006
  Why so many attributes? It just makes the XML unreadable and a PITA to write too.

• Anonymous
  March 17, 2006
  Max, In this case,
  Attributes = Properties = Flexibility = Power = A happier developer <g>.

• Anonymous
  March 17, 2006
  Is the Office 2007 UI XML extensibility language related to the Information Bridge Framework metadata language? Or are the two languages completely distinct?
  

• Anonymous
  March 17, 2006
  If I have a separate Windows Form in a VSTO Solution, will there be a "Ribbon Control" I can use at my Windows Form to provide a consistent UI to the user?

• Anonymous
  March 19, 2006
  Is there a relationship between the XML used for  the new Ribbon programming in Office 2007 and XAML? Why don't you make the two more closely resemble one another? Why don't you use a version of XAML for developers to use when building up the ui for their Office solutions?
  A second question is can you add or remove items from the ribbon at runtime? Not hide or show but add and remove. Like the controls in current VBA apps that can be added at runtime.

• Anonymous
  March 22, 2006
  Just checking in with some more responses:
  
  *Updating your existing add-in.  If you update your add-in to use the Ribbon, you can make it a group on an existing tab -- it's not constrained to the add-ins tab.  If you don't want the add-ins tab to appear on Office 2007, don't make any calls to the commandBars OM. :)
  
  *The UI extensibility schema for Office 2007 is distinct from the IBF metadata language.
  
  *The "Ribbon Control.” We do have folks investigating reuse of the Ribbon elsewhere, let us know if you are interested.
  
  *RibbonX and XAML. (Reply by Alex Mogilevsky, UI Architect.)  RibbonX is similar to XAML conceptually – it is markup-based control hierarchy which is associated with code. And both are conceptually similar to ASP.Net. We did build the system with knowledge of both and certainly tried to pick up the features most usable for developers. RibbonX can’t literally "use" XAML as XAML is much more powerful than the functionality we expose (e.g. we don’t expose any kind of graphic primitives, declarative databinding or custom controls). We’ve created something that works for its specific purpose and if at some point in the future XAML makes sense here the door is not closed...
  

• Anonymous
  April 16, 2006
  Office &quot;12&quot; (2007 Microsoft Office) リボンの開発 続編

• Anonymous
  April 16, 2006
  Office &quot;12&quot; (2007 Microsoft Office) リボンの開発 続編

• Anonymous
  April 25, 2006
  Yesterday I got back home from Redmond (after about 20 hours).
  Microsoft Office System Developers conference...

• Anonymous
  May 12, 2006
  Joe Friend has finally made it public that there will be built in blog functionality&amp;nbsp;in Word 2007!&amp;nbsp;I...

• Anonymous
  October 27, 2008
  PingBack from http://mstechnews.info/2008/10/the-office-2007-ui-bible/

• Anonymous
  June 08, 2009
  PingBack from http://insomniacuresite.info/story.php?id=6912