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!
