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):
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.
Custom Group Auto-Scaling
I have a custom Tab with autoScale=false.
However When I resize the Excel Window it still shrinks to a "Green Blob" - Please tell me that this is a BUG in TP and has been corrected in the Beta Release....
Many solutions will break if this is not the case
I have a problem with Example 1.
"Contoso Process UI" is placed directly among the file menu, and at this rate, the file menu will exceed the screen with many plugins vying for that space.
You can compare this to IE with LOTS of toolbars from Yahoo, Windows Live, MSN, StumbleUpon, etc... Seriously, I've seen someone with that many toolbars!!!
I think that all additions in the File Menu should be placed in the Add-Ins submenu so that the UI will scale without cluttering.
Sam, can you check if setting autoScale to "true" (not "false") on your custom group(s) (not tabs) solves the unexpected behavior you are seeing?
thenonhacker, thanks for the feedback! You make an interesting point and these types of questions are exactly what we are asking ourselves and our customers when building the UI extensibility platform. Striking a fine balance between being too rigid with what 3rd parties can do and ensuring that the underlying UI can't be "stretched too thin" by all of the custom additions is a constant challenge. In this particular case, based on our research around the types of solutions that we believe 3rd parties will want to build in the Backstage, limiting customizations to a single flyout felt too restrictive. The Backstage scaling support was designed with that in mind, though. While the end-user experience could degrade if too many custom tabs are added to the Backstage, all of them will always be available to the user.
Mirko - relegating add-ins to a flyout would also penalise users who have one or two add-ins that they use all the time. Perhaps the ideal would be for the user to decide which add-ins were prioritized and which relegated?
Is the full schema and/or examples for the 2010 ribbon available anywhere? There's lots of articles about what can be done but none about how to do it.
thanks - dave
I tried that...no luck..If I have many controls on the Tab it will shrink to a green blob !
We dont get the Slider arrow like in 2007
Thanks for this post. NOW I understand why there is so much white space in some of the panes/sheets in Backstage.
I thought the design team would be adding new stuff in the beta, which may, indeed, happen, but ... companies, consultants, even users can really customize their Office experience. Cool evolution.
1) Will Microsoft *finally* provide a developer based Ribbon/Backstage/Context Menu customization tool that will handle most of the XML code generation?
2) Why did you leave out *basic* Ribbon customization options in the Excel UI e.g. button size, screentip/supertip, custom button images etc? The omissions seem quite arbitrary.
This article is excellent news. However, as some others asked, is there any comprehensive documentation that would help us to anticipate GUI development
A few of you have asked about documentation. Coinciding with the public release of Office 2010 Beta, the following UI extensibility resources will be published on MSDN:
- Introduction to the Office 2010 Backstage View for Developers
- Customizing the Office 2010 Backstage View
- Customizing Context Menus in Office 2010
- Ribbon Extensibility in Microsoft Office 2010: Tab Activation and Auto-Scaling
- Targeting User Interface Solutions to the 2007 and 2010 Releases of Microsoft Office
- Office 2010 Schema: Fluent User Interface Schema
- Office 2010 Help Files: Office Fluent User Interface Control Identifiers
The resources will be based on and compatible with the Beta build.
Also, if you are authoring document-based solutions, you should know that Trang Luu’s Custom UI Editor tool will be updated with a few functional and usability improvements.
Once all of these resources become available publicly I will post another comment here. In the meantime, you can keep checking the Microsoft Office 2010 Developer Center (see the link at the end of my post).
Will Microsoft be providing pre-configured backstage view to recreate the Office 2003 interface (i.e. menus+toolbar and no ribbon)?
There are a considerable number of people that hate the ribbon with passion so a menus + toolbar view would be most welcome.
Technical articles mentioned at the end of my post have become available on MSDN (http://msdn.microsoft.com/en-us/library/ee692951(office.14).aspx).
In addition to the technical articles, the following two downloads are also available:
- Office 2010 Schema: Fluent User Interface Schema (http://download.microsoft.com/download/F/F/3/FF36D32F-4080-494B-83B8-49DADC68A999/Office2010FluentUISchema.exe)
- Office 2010 Help Files: Office Fluent User Interface Control Identifiers (http://download.microsoft.com/download/0/7/B/07BF35CE-4FA1-4DED-B4AA-3801D4E49F89/Office2010ControlIDs.exe)
The updated Custom UI Editor tool is available at (http://openxmldeveloper.org/archive/2009/11/18/7802.aspx). The tool is compatible both with Office 2007
and with the Beta build of Office 2010.
While not strictly related to UI extensibility, the MSDN article on deploying customized Ribbon (http://msdn.microsoft.com/en-us/library/ee704589(office.14).aspx)
and Melissa Kerr’s blog post on UI customization (http://blogs.technet.com/office2010/archive/2009/11/09/making-the-ribbon-mine.aspx)
may be of interest to you.
I hope you find these resources valuable. Thanks for helping us make Office better and keep sending your feedback!
We started development on backstage. While I think the general design is very interesting and allows to plug-in many different business rules, we discoverd a strong regression : the whole model is static. For instance the menus can't be populated each time they need to be.
Where is the dynamicMenu control that turned out to be a very nice feature in Office 2007 ????
Is there complete documentation for the ribbon and backstage anywhere? You show lots of useful examples of what can be done. But I can't find a complete list of all functionality (ie, definition & description of all the tags in the xml).
Can you please point a link to that?
I echo the concern voiced by thenonhacker. We have many 3rd party plug-ins for Office, and I can see folks wanting to implement many custom business solutions on this. It would be nice to have some rudimentary organizational abilities--perhaps a tiered structure?
Besides the limitations on space, some of this is more about clutter and deployment. What control does IT have over this? Is it easy to deploy certain tabs only to certain groups, for example? And if so, is it easy for IT to enforce the presence of a given tab?
Maybe some of those types of scenarios weren't envisioned for Backstage use and would best be implemented another way? I guess if nothing else, please provide very specific guidance about how Backstage should be used (and how it *should not* be used), and any other best practices you recommend.
Cool stuff! :)