Microsoft Office Backstage (Part 1 – Backstory)

Hi, I'm Clay Satterfield and I'm a Senior Program Manager on the Office User Experience team. Within the first few hours or so of using the Office 2010 Technical Preview, it’s pretty likely that you’ll eventually need to “Save As” or “Print” or do something else with your file. When you finally do click on the Office Button, you’ll see something that you probably didn’t expect. Instead of a menu, or even a Ribbon tab, you’ll see the new Microsoft Office Backstage View.

 

Microsoft Office Backstage

Before getting into the details of the Backstage View, I’d like to talk about the thinking that led us to the design. And to do that, I have to start way back in the fall of 2003, before we started designing the Ribbon.

The Office User Experience Team is responsible for providing the UI platform for the rest of Office, so it was our assignment to tackle the following two problems. First, we knew from user feedback that people had a lot of difficulty finding, using, and understanding the vast feature set in Office. Second, we were struggling internally with the fact the menus, toolbars, and task panes were collapsing under their own weight. Those UI concepts were designed for much simpler programs, and could no longer handle the volume of commands in the mature Office applications.

So, we spent a lot of time looking at entire the Office feature set. We thought hard about how new features should be built and we made some predictions about the types of features we’d need to build over the next several versions.

One of the first things we identified was that there were two distinct types of features within the applications. We called the two types IN and OUT features.

The IN features are the ones most people are more familiar with. These are the features that act on the content of the document and show up on the page. Examples include commands like bold, margins, spelling, and styles. These are the features that make up the heart of the application. When using these features, you need to be able to view the document content and often need to have a selection or blinking cursor somewhere in the document.

The “Out” features help people do something with the content they create. Examples include Saving, Printing, Permissions, Versioning, Collaboration, Document Inspector, Workflows, etc. The Out feature set includes a wide ranging and surprisingly long list, but they all have a lot of similarities. The primary characteristic is that they don’t act on a specific point in the document, and their effects don’t appear on the page. In fact, you could easily imagine using one of these features without even opening the document to look at it (for example, setting permissions on the file or sending it as an attachment).

Unfortunately, the other thing the OUT features have in common is that they almost all suffer from low discoverability and poor usability.

When we looked closely at the requirements on the UI platform, we realized that IN and OUT features have very different needs. Some of the most striking differences become obvious when you start thinking about Office’s WYSIWYG user interface.

WYSIWYG Process

The user looks at the document, sees something they want to change, and then they find and use a tool that lets them make the change they desire. They repeat this loop until they decide the document is finished.

In fact, when we created the Fluent UI for Office 2007, we specifically focused on improving a few parts of this model. For example, the Ribbon helps users “Find the Tool”. Galleries combine complex steps into a visual result so that “Using the Tool” is easier. Live Preview takes advantage of the power of “Seeing the Results on the Page.”

The Ribbon needs to stay out of the way because most of this model depends on seeing as much as possible of your document. Nearly all of the communication between you and the application happens on the document surface. We don’t need to pop up a dialog box to tell you when you successfully changed the font size – you just see it happen. Same goes for changing margins, inserting a picture, or any other IN command.

Here’s the problem though – The OUT features don’t show up on the page, so the WYSIWYG model falls apart for those features.

· You can’t scan the page for something you want to change. The status of OUT features doesn’t appear there. For example, there’s nothing on the page to indicate who has permissions to read the document, so you have to form the goal to set permissions some other way.

· When people form an editing goal because of something they don’t like on the page, they assume an appropriate tool exists in the application somewhere. People rarely make that assumption for OUT features. For example, many very smart people have no idea that you can e-mail a document to someone from within the application. They just never even imagine that something like that could live in a word processor.

· Even if you do find and use an OUT feature, the communication with the application is difficult and inconsistent. We use a combination of the status bar, message boxes, dialogs, task panes, pop-up notifications, and even web sites to tell you what’s actually going on with your document. For example, if you notice that you can’t edit a document you’ve opened, you have to check three or four possible permissions dialogs, a task pane, the status bar, and the application title bar to find out which feature is making the document read-only.

Sadly, the only way the average person can be successful using our OUT features is with assistance from outside of our user interface. Most commonly, people use these features because a coworker has found and explained them, or because a boss required that they be used (and provided training). A few people might get lucky and read about a new feature on a Tips and Tricks blog.

What we were sorely lacking was the WYSIWYG equivalent for the OUT features.

What made this particularly scary for us internally is that for the foreseeable future, the OUT features are the ones that are growing rapidly. Documents are now rarely simple files authored by one person who keeps it on his hard drive until he prints. Collaboration and sharing are critical. Documents are key parts of complicated business processes. There’s a ton of context surrounding documents, and increasingly, that context needs to surface within the authoring application.

So, based on the planned feature set for Office 2007, we knew we had to tackle the IN problems first. Features like SmartArt, Conditional Formatting, Themes, and all the Office Art effects required investments in Galleries, Live Preview, and contextual tabs. But we knew that the OUT features wouldn’t go away, and as planning for Office 2010 began, we could see that the Office Menu just wasn’t going to cut it.

The Backstage view is the solution that tries to achieve these goals. In future blog posts, we’ll discuss how it works and get into the details of the different features inside the Backstage view. For now, we hope you enjoy exploring it!