Good Service for Add-ins
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.
With Book 1 selected, there are no customizations present.
When you select Book 2, the customizations magically appear, in this case, a custom tab, and a new group on the Sheet tab.
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
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.
VBA Solutions
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
Demand Loading
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.
Comments
- Anonymous
March 23, 2006
Savraj are you sure you went on the real London Underground? ;)
On a more serious note, the XML RibbonX concept sounds like it's really been thought about and should reduce add-in bloat... keep up the great work! - Anonymous
March 23, 2006
Those excel screenshots reminded me of the current state of the Excel MDI interface. Is it still the bizarre mixture of MDI and taskbar? Please tell me that the two-entries on the taskbar are going away, which just leads to constant confusion, in ways im sure I don't have to explain :). - Anonymous
March 23, 2006
Regarding the VBA solution, we won't be able to rely on down-level customers of our addins having the xml file converters/importers. So as well as looking in the file for the markup, we'll also need a standard VBA entry point to provide the markup script from code. Perhaps a Workbook_GetCustomUI() method in the ThisWorkbook class (and equivalent in the other apps). That would be ignored by down-level versions, but called by Excel 2007 to allow us to provide the XML, if we want to stick with the binary file formats for compatibility. - Anonymous
March 23, 2006
Could you please explain why the Office team has choosen COM and VBA over .NET?
I thought VB6 had to die because it relies on COM and now Office 2007 ships with a VBA version from 2003 and the new extensibility interface relies on COM. - Anonymous
March 23, 2006
"Could you please explain why the Office team has choosen COM and VBA over .NET?
I thought VB6 had to die because it relies on COM and now Office 2007 ships with a VBA version from 2003 and the new extensibility interface relies on COM. "
They haven't. It's backwards compatibility. The corporate world won't upgrade if they are told they can stick all their legacy VBA macro elsewhere. And man they are very popular.
And for the record, VB6 != VBA - Anonymous
March 23, 2006
Office Add-Ins are not written in VBA. Add-Ins are DLL's which export a COM interface.
So if the interface for Add-Ins is redesigned, why has the Office team choosen COM again?
And in my books VB6 == VBA because they share the same syntax which is different from VB.NET
And Microsoft has already dropped VB6, so why not drop VBA in favor of VB.NET too?
So legacy macros are more important to Microsoft than legacy applications? - Anonymous
March 23, 2006
"Could you please explain why the Office team has choosen COM and VBA over .NET?"
Dot Net isn't exactly sweeping up victories if you look at it as a popularity contest.
The loss of backward compatibility for 6 million VB6 developers is a drop in the bucket compared to what Microsoft could lose in migrating Office development to Dot Net. - Anonymous
March 23, 2006
In case you missed this part in the original post:
... COM Add-ins come in many flavors, including C#, C++, VB6, and VB.Net. ... - Anonymous
March 23, 2006
Jay wrote:
"Please tell me that the two-entries on the taskbar are going away, which just leads to constant confusion..."
I (usually) like having separate taskbar buttons for separate documents.
If I'm working on three documents at once--two Excel and one Word--I find it confusing to go to the taskbar to switch from one to another if one is Excel and the other Word, but to go to the application menu to switch if both are Excel. - Anonymous
March 23, 2006
Oh man, I thought you guys had finally killed off MDI in Excel.
I was excited to upgrade for that reason alone.
I'm sad now. - Anonymous
March 23, 2006
That's exactly what I was thinking of when I saw the screenshots.
Jensen, could you post something about the weird SDI/MDI situation Office is currently in? I can't believe how inconsistent the model is in Office 2003 (with Word basically being SDI, Excel being MDI but having multiple taskbar entries, etc). What's going to happen in 2007? - Anonymous
March 23, 2006
I definitely concur with the comments concerning the confusing SDI/MDI hybrid that is Excel. It was the number 1 thing that stood out when I first used Office 2003, and I really hope you guys consider fixing this for 2007. Why can't Excel behave like Word? - Anonymous
March 23, 2006
Are exchange extension dlls supported? - Anonymous
March 23, 2006
The comment has been removed - Anonymous
March 23, 2006
The comment has been removed - Anonymous
March 23, 2006
I'm so glad that you've sorted out the toolbar persistence in Excel. I wrote a book for the ECDL Advanced Spreadsheets syllabus, and one of the topics that I had to cover was adding macros to custom toolbars. The instructions get a bit complicated when there are students working on shared computers in a school or college, all creating their own toolbars with the same name, but you want them to leave the machines in a tidy state for whoever uses them next. - Anonymous
March 27, 2006
The comment has been removed - Anonymous
March 27, 2006
I adhere to everyone asking for logical SDI behaviour in Excel 2007. - Anonymous
March 29, 2006
The comment has been removed - Anonymous
March 30, 2006
Xin chao, Minh den tu HL, minh mong muon duoc lam quen voi tat ca cac ban. Thanks you - Anonymous
March 30, 2006
Xin chao, Minh den tu HL, minh mong muon duoc lam quen voi tat ca cac ban. Thanks you - Anonymous
March 30, 2006
Xin chao, Minh den tu HL, minh mong muon duoc lam quen voi tat ca cac ban. Thanks you - Anonymous
April 25, 2006
Yesterday I got back home from Redmond (after about 20 hours).
Microsoft Office System Developers conference... - Anonymous
September 03, 2006
Day two of the conference, this time mostly about building rich clients using Info Path, there were also - Anonymous
October 27, 2008
PingBack from http://mstechnews.info/2008/10/the-office-2007-ui-bible/