Over the last few days, I've explained some of the major capabilities of the gallery control in Office 12 and shown how we use it to make formatting objects easy. Today, I want to write about how we use galleries in Office 12 to make the entire product--not just applying visual styles--easier to use.
Office has this fantastic templates web site where people download millions of resumes, form letters, newsletters, greeting cards, and all kinds of different starter documents. One of the things we did early in the design of the new UI was to download a number of our most popular templates (as well as look at templates from other products) and try to learn why they were popular. One of the most obvious things that jumped out at us was that most of the templates used the product in more depth than the average person. For example, many templates rely heavily on text boxes and pictures that have the text wrap around them in order to get a polished effect. Yet, in the usability lab, we found many people unable to perform this seemingly straightforward and common task.
It turns out that moving a picture to the upper-right corner of a page and having text wrap around it is a pretty involved task. Not because the commands or concepts involved are themselves too complicated, but because you need to know how to synthesize a set of unrelated commands and settings together in order to get the desired result.
To do it right involves some combination of:
Again, it's not that any of these actions are too hard to do in themselves, it's that it takes a pretty detailed understanding of Word to realize that you need to find and use these commands together to get the result you want.
In Office 12, we use the term "Results-Oriented Design" to reflect a subtle but powerful evolution in our thinking about how software should work. Instead of presenting many different small commands as the primary interface to functionality, we believe in presenting the likely result the user is looking for first, and then exposing the individual advanced commands secondarily. The key to this approach is the "pick and click" mentality of the gallery applied to richer features.
Let's take the picture example again. Word 12 introduces a Position gallery in the Picture Tools tab:
(click to enlarge)
As you can see, we've taken the most commonly sought-after results and presented them in a gallery. Clicking the desired result applies all of the right features behind the scenes without needing to understand all of the settings that are being applied. And once the picture is in place, you're free to nudge it over, shrink it, crop it, or even tweak the underlying advanced properties. Tell us which result is the closest to what you're looking for and we'll get it close enough that you can easily tweak the rest to get it exactly right.
We've also applied this concept to the UI in order to improve efficiency. Although changing margins in Word is a common operation, people do tend to set the same margins over and over. For instance, I always set my margins to 1" on each side. Other people use 1" on the left and 4" on the right for comments as a standard. I'm sure you have your own favorites. Here's a Margins gallery that shows a more results-oriented approach to quickly setting your margins:
(Of course we remember your custom settings so that you can quickly apply them again and again.)
Here's another example from charting. Getting the layout you intend for a chart today can be a challenge. You have go in and out of the Format Chart dialog with different elements of the chart selected to set combinations of controls to get the result you intend. I saw a member of the chart team do a presentation where she showed that some of the most common chart layouts that used to take 50 clicks now take only 1 click, thanks to a gallery of chart layout results:
So, when you hear the term "Results-Oriented Design", it's really just an overly fancy term for a simple concept: Present the functionality in your program at a slightly higher level. Think about the results people are trying to achieve and present the interface as those results first, and the commands and settings that enable those results as a secondary option.
I like to think of it this way: figure out 25 things people want to do with your app and phrase them as questions: "How do I do X?" If your UI enables you to answer those questions in a single sentence rather than a 5-item bulleted list, you're on the right track.