Most People Are Not Trained In Geology
One of the tenets of the Office 12 user interface is that we don't want people
to have to look "under rocks."
I don't know why we say "under rocks." Maybe I made it up, maybe I heard
it somewhere, who knows. The picture I get in my head is an insect-eating
animal crossing the land, turning over rocks to look for meals.
Occasionally, a rock will be hiding a juicy insect. Most times, however,
there's nothing under the rock. As a result, the animal spends most of his
day looking under rocks.
In a user interface, a "rock" is anything you have to click to see what's under
it. The more rocks you have to look under, the harder it is to find what
you're looking for efficiently. When you have a UI with a lot of rocks to
look under, people start to feel like your program is very complex. It's
like the shell game--people
start forgetting what rocks they've looked under and which they haven't.
Eventually, people give up ever looking for new things and instead just use the
same three rocks they always use.
As you add more features to a product, the tendency is for the number of rocks
to go up. Yet, the more rocks there are, the less likely people are to
explore them. This is a hard issue to solve. Here are some of the
steps we've taken in Office 12 to help people look under fewer rocks:
-
The Ribbon is the starting point for all functionality. Unlike the
old system, in which you had to look under short menus, long menus,
toolbars, hidden toolbars, the Task Pane stack, all commands in Office 12
start in the Ribbon.
- Everything gets a label, especially dropdowns. If you can keep
someone from turning over a rock by giving that rock a good name, then
that's a huge win. You don't ever have to open up a can of Sprite to
know what's inside it.
- Use specific labels. Engineers love to name things "Tools" or
"Options" or "More" or "Advanced." This is just like putting a "Turn
Me Over" sticker on the rock--the name is so ambiguous and yet so promising
that people are going to turn it over every time. A label for a menu
like "Import Data From" is never going to take a click from someone looking
for Word Count.
- Contextualization! I've made
the
case for contextualization already, so I won't bore you again here.
But contextualization simplifies the core experience by only showing the
rocks that are capable of having insects under them.
Looking under the rocks that are left is less inefficient if there's a clear
route for the user to follow from the first one to the last one. Think of
100 rocks lined up in a row vs. the same rocks scattered in a random pattern.
In which case could you look under all 100 rocks faster and be assured that you
looked under all of them and didn't forget any of them? We designed the
Ribbon to be the single home for functionality and to have a built-in, simple
scanning pattern (chunk to chunk, tab to tab.) It's finite and you know
when you've seen all the rocks.
It's impossible to eliminate all the rocks from all but the simplest products, and of course there are always
trade-offs. But in Office 12, we've tried to be hardcore about resisting
the urge to generically categorize or to invent multiple ways to access the same
feature.
One of the questions we always challenge ourselves with is: "are we just
creating another rock for people to look
under?"
