As part of the effort to deliver refreshed visuals for Word Online, we decided to build a new UX platform for Office Online to improve the long-term engineering velocity of our team. This new UX platform would be influenced by industry best practices, even if it came at the cost of the platform being a bit more painful to integrate into our monolithic applications. We went into this project as if this were the beginning of an effort to rewrite Word Online from scratch. With this approach, we hoped to build a UX platform that was isolated, extensible, and reusable. While this approach would introduce short term pain as we had to refactor our existing application to introduce the right APIs for an isolated UX platform, we knew that this would pay off in the long run as we continue to modernize other parts of our applications.

Building a standalone component

To help us ensure that our new architecture was not influenced by the structure of the existing Office Online applications, we decided that we would build the UX platform as a standalone NPM package. This NPM package would live in a new git repository and it would have its own test application that would enable us to render parts of the UX platform in isolation. This contrasts with our existing UX platform, where things like the Ribbon can only be rendered inside an application like Word Online. The hope was that this test application would be a place where developers making UI changes could see their changes in seconds instead the minutes it takes with our current stack.

There was some initial concern here that this approach would make it more difficult for developers working on bug fixes to test their changes end to end. After all, there are some bugs in Word Online that only appear when the UX platform is integrated within the larger application. In practice, we found that this isolated test app enabled us to easily separate bugs in the UX platform from bugs in the integration of the UX platform into an Office Online application. We also invested in tooling to enable developers to be able to validate changes in the UX platform inside a larger application without deploying a new version of the NPM package. A side effect of this development approach is that we did not have Office Online specific implementation details inside the UX platform, which has enabled us to share our code with other web applications within Microsoft.

Design considerations

To fully understand the design decisions we made when building up a new UX platform, it is important to understand some of the functionality we need to support in our applications. While our initial UX platform rewrite was only targeting the Ribbon, we plan to eventually port all our UX surfaces to React and TypeScript. It was very important for us to have a forward looking mindset here to enable us to scale out to more developers as the project matured.

Responsive layout

The Single Line Ribbon has a responsive design where controls can be rendered in an overflow menu to fit in narrower browser windows. This means we need to support rendering any control type in an overflow menu. We also needed to figure out a clean way for application teams to author the contents of their Ribbons and order in which controls go into an overflow. The implementation of Ribbon scaling was actually one of the more challenging parts of this rewrite and likely merits a blog post of its own.

Ribbon Scaling

Tell Me

Another interesting aspect of our UX platform is the “Tell Me” control. This is a feature that enables users to search for a command in Word Online. The Tell Me control needs to be able to query for all controls in the Ribbon to determine what results should be presented to the user. The Tell Me control was implemented years after our legacy Script# UX platform, which resulted in some clunky mechanisms for interacting with the Ribbon to identify and invoke commands. We wanted to improve the architecture in the new UX platform to ensure we were exposing the right APIs from our UX platform to prevent tight coupling between the Ribbon and Tell Me code.

Tell Me Control

Add Ins

Office Online’s extensibility platform allows for third party developers to develop features and have their own buttons in the Ribbon. Like “Tell Me”, this functionality came to Word Online a long time after the initial implementation of the UX platform. The legacy Ribbon was originally built under the assumption that all controls could be statically defined at build time. We did not have APIs for adding or removing controls at run time, so this meant that we had to write new code for add ins to support this scenario rather than leveraging the same mechanism for constructing the first party controls in the Ribbon. It was a goal of the rewrite to consolidate the ways in which controls are added to the Ribbon.

Pickit Images is an example of a third party extension that adds a Ribbon control at run time

Synchronizing state across multiple UI surfaces

Controls that appear in the Ribbon might also appear in other UI surfaces, such as context menus, floaties, and Tell Me search results. Many of these controls also have some state associated with them. An example of this can be seen with “toggle buttons” like the “bold” button in Word Online. Whenever the user’s selection contains bold text, the control has a darker background color than it does when the selection does not contain bolded text.

Bold toggle state updating with changes in the user’s selection

This state needs to be consistent across all the UI surfaces in which the “bold” button appears. Today, each of these UI surfaces has its own “bold” button whose state needs to be kept up to date, resulting in each application having code that needs to know about all these UI surfaces. For the new UX platform, we wanted to eliminate this duplication and reduce some of this coupling between core application logic and the UX platform.