When introducing the Ribbon UI in Office 2007, we also introduced the RibbonX (Ribbon extensibility) model, a new way to programmatically customize the Office UI. RibbonX enables 3rd party developers and solution providers to build on top of the Ribbon by authoring custom tabs and groups, targeting scenarios unique to and optimized for their customers.
Office 2010 extends the span of the UI extensibility platform by providing support for customization of the new Backstage view. It also adds several new, powerful features to the existent RibbonX platform.
The Backstage view is a new integral part of the Office UI. It elevates the file-level features (printing, sharing, distributing, collaborating, etc.) the way the Ribbon elevated document creation features. Making it easy for 3rd parties to extend the Backstage view’s immersive UI in meaningful ways is a large area of our extensibility focus in Office 2010.
One may ask – “when is it appropriate to extend the Ribbon and when the Backstage view?” If you are building a solution that targets document editing and content generation scenarios (i.e. your features will be helping customers when working in the document), extending the Ribbon is the way to go. If, on the other hand, your customers need a solution that helps them work with documents, processes and custom workflows that those documents are associated with, extending the Backstage is the recommended approach.
More than ever in the past, today’s documents evolve via collaborative efforts, shifting through various stages and cycles. Processes that those documents are tied to are often highly customized and organization-specific. The Backstage view offers a great place to expose custom info about documents and those idiosyncratic processes, and enable users to “move” those documents through various stages.
Below is an add-in that adds a custom Contoso Process tab to the Backstage view; all of the custom UI in the example is built using the new Backstage extensibility model. Contoso Process tab displays relevant metadata about the spreadsheet and the phase it is in, as well as remaining steps that need to be taken for the spreadsheet to progress to the next stage. Schedule For Design Phase and Open Design Issues groups are red, indicating issues that require immediate attention. The graph on the right provides “bigger picture,” a summary of where in the process all of the other related spreadsheets are. It is easy to imagine how all of this custom metadata could be pulled from a SharePoint library which hosts the spreadsheets.
The Contoso Process UI displays custom metadata and contextually-aware custom UI for process management
Once all of the open design issues are resolved, Exit Design Phase button on top of the tab can be enabled programmatically. Clicking it moves the spreadsheet into the legal review phase and the tab updates its content dynamically to show the new status and the requirements for the new phase.
The Contoso Process UI updates dynamically to reflect the new phase spreadsheet has been moved to
Imagine you are a solution developer, and sharing documents is a common scenario for your customers. They like the capabilities of the built-in Share tab in the Backstage view, but they also want a direct way to exchange their documents via Windows Live Hotmail and Facebook. Backstage extensibility empowers you to create and integrate both of these custom features into the built-in Share tab.
Here is what the customized Send Using E-Mail form would look like with the Send via Hotmail group added (the bottom right of the picture):
Custom Send via Hotmail group is integrated into the built-in Send Using E-mail form
And, here is what the customized Share tab would look like with the new Post to Facebook task (and the associated form) added:
Built-in Share tab is extended with a custom Post to Facebook task
Now imagine you are a developer and your customers do a lot of intense data editing in multiple documents simultaneously. They open and close documents frequently, and they don’t want to be prompted to save changes when closing documents.
With the Backstage view extensibility, you can easily replace the built-in Close command with a custom Save and Close control which automatically saves the document before closing it.
Navigation pane in the Backstage before and after the change to replace built-in Close with custom Save & Close
Backstage customizations are defined in the same markup file that contains Ribbon and context menu customizations; the Backstage is just another top-level node. Its internal hierarchy is in many ways similar to the Ribbon’s. Primarily, just like the Ribbon, the Backstage uses tabs as its core building blocks. Backstage tabs can contain either one or two columns of groups. The custom Contoso Process tab from the earlier example contains two columns:
Unlike the Ribbon, the Backstage can also host buttons at the top level – they show up as fast commands in the navigation pane, like the Save and Close command from our earlier example.
While groups in the Ribbon and the Backstage have different spatial organization of content, they can host numerous identical control types, with callbacks (custom functions that define unique control behaviors and which are being called by Office code) for those controls being same across the two.
More details on the Backstage extensibility, its structure and features will be provided in the upcoming Beta documentation. As the Beta build of Office 2010 becomes publicly available, the documentation will be published at the Office Developer Center on MSDN, and will include the full Backstage XML schema, the list of built-in control IDs, a comprehensive introductory article on Backstage extensibility, as well as numerous Backstage extensibility code samples.
If your solution customized the Office Menu in Office 2007, it will keep working in Office 2010. All of the custom functionality that was added to the Office Menu shows up in the Add-Ins flyout in the Backstage’s navigation pane:
Custom Office Menu additions (from Office 2007) show up in the Backstage’s navigation pane
Tab activation and group auto-scaling are frequently requested features we hear from developers who create Ribbon solutions. Tab activation enables developers to activate a tab on demand; this brings the tab to the foreground (as if it were selected) in response to some event. Group auto-scaling enables custom Ribbon groups to adapt their layout to best match the horizontal window size. Improving context menu extensibility is another feature request we hear often. We addressed all these requests in Office 2010.
Imagine a scenario in which you have built an Excel solution with several custom tabs. If each of your custom tabs pertains to a particular type of data, you may want to ensure that the appropriate tab is brought to the foreground when the user interacts with corresponding data type. You achieve this using the ActivateTab method on the IRibbonUI object (passing to it a String-type parameter specifying the custom tab to activate):
IRibbonUI.ActivateTab(String tabID).
You can use a “parallel” ActivateTabMso method to activate a built-in tab and ActivateTabQ method to activate a tab shared between multiple add-ins (ActivateTabQ requires an extra String-type parameter that specifies the namespace of the target add-in).
You have probably noticed that built-in Ribbon groups change their layout when you resize the window. When the window is larger, groups in the Ribbon use the space to show labels or “grow” the size of some commands; as the window shrinks down, groups adapt and “pack” more functionality into less space.
Imagine if customers of your solution want to run with non-maximized windows so they can have multiple applications visible simultaneously. However, when they make the application window smaller, they don’t want commands in your custom group to immediately resize into a single button and be an extra click away. Without having to define when or exactly how your custom group scales, in Office 2010 you can just indicate that the group should adaptively change its layout (by setting its autoScale property to “true”), and Office will ensure that it best fits within the changing window size.
Here is an example that shows how an add-in group would scale using autoScale=true; note that you should assign an icon to the group itself as the icon will be used when the group finally transforms into a single button:
In Office 2010 a custom group can change its layout to best fit within the resized application window
If you are building solutions on top of Office and efficient access to frequently-used, contextual functionality is important for users of your solutions, you have probably considered customizing right-click menus. Some context menus have been extensible via the CommandBars Object Model. However, there are context menus that can’t be changed this way; for example, PowerPoint 2007 contains context menus that aren’t accessible via the CommandBars OM. And, several control types (galleries, split-buttons) can’t be added to context menus via the CommandBars OM.
In Office 2010, you can rely on the familiar RibbonX model to also customize context menus. All of the control types supported in built-in menus can now be added to customized context menus. Context menus are accessible in Office 2010 as a new top-level node in the custom UI markup, the same markup that already hosts the Ribbon.
Customized cell context menu in Excel with a custom split-button, gallery and a separator added
The new Backstage extensibility platform and Ribbon extensibility enhancements empower you to build Office 2010 solutions that are even richer than the ones you could build in the past. We hope that you have already started using these features in the Technical Preview build of Office 2010 and we greatly appreciate your continuous feedback.
- Mirko Mandic, Office User Experience Program Manager
Update - 11/3/2009: Links to more resources has been added in a “Further Reading” at the end of the post.
Update - 11/20/2009: More technical articles have been provided with the release of the Office 2010 public Beta – see Mirko’s comment below (posted on 11/20) for those details.
Update – 2/27/2010: Visio has just posted a related blog on UI extensibility in Visio 2010. Check it out here.
Will VS 2010 have a visual designer for Backstage?
@ Sam: This is possible if you are adding a custom group to a built-in tab. In order to ensure optimal scaling of all groups (including the built-in ones) within a built-in group, your custom group can in some cases scale directly to a big button, without going through the gradual auto-scaling sequence.
@ David, Nicolas: Please see my last comment for the UI extensibility documentation for Office 2010 Beta. More specifically, the schema is available at http://download.microsoft.com/download/0/7/B/07BF35CE-4FA1-4DED-B4AA-3801D4E49F89/Office2010ControlIDs.exe; the list of all the Backstage elements and their properties is available at the end of this article - http://msdn.microsoft.com/en-us/library/ee691833(office.14).aspx; and, of course, the Office 2007 documentation (at http://msdn.microsoft.com/en-us/library/aa338199.aspx) for the Ribbon elements and their properties is still valid.
@ Nicolas: Thanks for the feedback on dynamically generated UI. While you can’t build custom dynamic menus in the Backstage, keep in mind that the UI is not entirely static. In fact, you can use a lot of the callbacks that are identical to those available in the Ribbon extensibility model to dynamically change the appearance of your controls (including their visibility).
@ Colin, Simon: VSTO offers a Ribbon Visual Designer, which automatically generates the underlying custom markup from an easy-to-customize visual representation of the actual UI. VSTO’s Visual Designer currently offers no support for the Backstage extensibility.
@ Colin: This post focuses on our UI extensibility work in Office 2010. The features you have mentioned (“*basic* Ribbon customization options in the Excel UI e.g. button size, screentip/supertip, custom button images”) have been documented elsewhere – in particular, check out the Office Fluent User Interface Developer Center at http://msdn.microsoft.com/en-us/office/aa905530.aspx and various UI extensibility posts on the Office 2007 UI blog (http://blogs.msdn.com/jensenh/).
@ Oliver: Thanks for the feedback. There are no plans to offer UI extensibity capabilities for recreating the Office 2003 interface.
@ thenonhacker, mary_branscombe, Ryan: IT departments have control over which add-ins are installed on the computers in their organizations and also, over how end-users can customize their Office applications. See this article (http://msdn.microsoft.com/en-us/library/ee704589(office.14).aspx) for more info.
Where one has created a customised ribbon and then exported this, as can be achieved through File | Options | Customize Ribbon, how can one incoporate the ribbon as part of the Office 2010 installation?
I'm porting our Outlook 2007 Addin to 2010. and testing the different new features.
I've copied the xml for the back stage and it doesn't work!
I can get the ribbonX in the Explorer to load with ribbon items and context menus using the sample XML.
but the backstage sample XML doesn't show up.
any ideas what the problem can be?
is the an error log for the 2010 beta anywhere?
@ Graham: My name is Melissa and I am the PM for Ribbon Customization. There exists an MSDN article (http://msdn.microsoft.com/en-us/library/ee704589(office.14).aspx) that provides instructions on Deploying a Customized Ribbon & Quick Access Toolbar to a set of user via an OS script. This article is not specifically about deploying customizations during Office 2010 installation time, but I think it will provide you with the necessary information in order to do this. Thanks for your question!
I Would like to use RibbonX ans backstage view in a Windows form or WPF application. Is it possible.
Can you give me resource link for helping me.
Thanks
Many Thanks Melissa!
Can i add Our server documents list to Recent documents list.