Today’s Guest Writer: Savraj Dhanjal
Savraj is a Program Manager on the Office User Experience team focused on user interface extensibility for Office developers.
For Office 2007, we built the UI extensibility model around a simple idea: If your add-in or solution is installed, its UI customizations are present. If it’s uninstalled, its customizations are no longer present. I would venture to guess that this is how anyone would expect UI extensibility to work.
In Office 2003, you had to take a few extra steps to make sure your add-in behaved in this reasonable manner. As a first line of defense, you created controls as temporary, ensuring that they would not be persisted beyond the current session. If you changed anything built-in, you needed to write code to clean up your changes on uninstall. A tricky task, because you didn’t know what other add-ins, or the user, had done to customize the UI. You could set various protection bits to shield yourself from modification by users, and you could call “.reset” on built-in toolbars to get them back to a default state. But you might have just reset another add-ins customizations on a built-in toolbar. And how does the end user get that add-in back? Perhaps by reinstalling the add-in?
In many ways, the CommandBars OM is a free-for-all. Any add-in can show up, change the UI (whether built-in or from another add-in), and then disappear. In Office 2003, these changes are persisted in Word and Excel in the Normal template and the Excel11.xlb file. As many of you know, the quickest way to reset your UI in these applications is to delete Normal.dot or Excel11.xlb. And for those of you that didn’t know that, there’s a chance that you’re harboring UI customizations in those files from add-ins you uninstalled long ago.
We wanted to move to a model where solutions didn’t have to worry about what other add-ins were doing–a model that didn’t leave the user with a bunch of “dead” buttons cluttering the UI. And if we could pull it off, it would be nice if this played well with end-user customization. Sure, it was possible to author a well-behaved add-in with CommandBars, but it often involved a number of special steps, among them setting protection bits, and in the case of Word, using the CustomizationContext variable.
So we decided to move most persistence away from the application, and instead associate it with the add-ins and solutions. With RibbonX, add-ins provide Office with markup to customize the Ribbon, as you saw in last week’s post. Since a solution’s UI customizations are defined in XML, we can keep track of who’s done what. For example, if we have three add-ins, each supplying markup to change the user interface, and add-in #2 gets uninstalled, we can remove its UI changes, because we know exactly what each add-in did. We do this in a manner transparent to developers–we’ve squarely taken on the burden of UI “housekeeping.”
With the UI as markup attached to solutions, we’ve also enabled a number of scenarios that were complicated or required extra code in Office 2003 to work properly. One of our favorite examples is document switching in Excel. In Excel 2003, you can attach a toolbar to a document. If you have two such documents open, with focus on one of them, you see both toolbars. As you switch between documents in Word 2003, however, the attached toolbars appear and disappear appropriately. If you wanted to get the same behavior in Excel, you would need to write code to show and hide the toolbars. In fact, if you ever want the attached toolbars to go away, even after the Excel workbook is closed, you need to write code–in Excel 2007, it just works as you would expect.
RibbonX works with both COM and VBA solutions, and we have endeavored to make the model as similar as possible between the two. You can create both application-level and document-level solutions with this model. If you want to create an application-level solution–that is, UI customizations that are visible for all open documents, you can create a COM Add-In, a VBA Excel Add-in (.xlam), a VBA PowerPoint Add-in (.ppam) or a Word Global Template (.dotm). Document level solutions can be authored as individual documents: .docx, .xlsx, .pptx–or the matching macro-enabled formats.
COM Add-ins come in many flavors, including C#, C++, VB6, and VB.Net. On load of a COM Add-in, Office asks for your customUI markup via a method on the new IRibbonExtensibility interface, and this markup gets applied to the Ribbon.
If you have built a VBA-based solution, be it a document, an add-in, or global template, Office looks for the customUI part in your new file format document. Once found, the customUI gets applied to the Ribbon.
Support for the Quick Access Toolbar
For all RibbonX add-ins, the user is free to add controls to the Quick Access Toolbar by right-clicking on them. When the solution or document is gone, the control no longer appears on the Quick Access Toolbar. Of course, you don’t need to write a single line of extra code to make this work–we’ve written those lines here at Microsoft. 🙂
Hello World group on the QAT
Ribbon Extensibility is also designed to support “demand loading” of COM Add-Ins. So if you set your COM Add-In as demand-loaded, on first boot, we get (and cache) your XML, and on subsequent boots, your add-in isn’t loaded until someone clicks on one of your controls. This allows you to minimize your solution’s impact on application boot. Of course, we clear the cache if your add-in is ever uninstalled, again, all transparent to you.
Last month I had the pleasure of traveling to the UK for some visits with customers and partners. While gathering feedback and understanding customer scenarios, I had a chance to ride on the London Underground, a marvel of engineering, efficiency, and design. When in the Tube, I would often hear announcements like, “There is a good service on the Jubilee Line,” which meant that the Jubilee Line trains were on time, as one would expect. Well I’m proud to say that Office 2007 will also offer “good service” with regard to add-in UI customizations–that is, they will come and go as you expect.