Tipping the Scale (Why the UI, Part 5)

This is the fifth part in my weekly series of entries in which I outline some
of the reasons we decided to pursue a new user interface for Office 12. You can
read the last installments here:
Part 1
Part 2
Part 3
Part 4.

Over the last month, we've taken a trip through Ye Olde
Museum of Office Past , looking specifically at Microsoft Word for
Windows, starting with Word 1.0 and working our way to the present-day
state-of-the-art, Word 2003.

One of the misunderstandings I've seen repeated around the 'net a number of
times is that our team set out to "destroy the menu-based paradigms introduced
by Apple."

Of course, as you know if you've read
Part 1 of the story, many of today's UI
paradigms attributed to Apple were introduced well before the Lisa or the
Macintosh.  Regardless of who gets credit for them, they're good paradigms.  There's nothing wrong with menus and
toolbars-based UI for certain applications.  Truth be told, these paradigms
served Office well for a number of releases.

Because it's not that menus and toolbars are bad or that the people who created
them weren't smart.  The problem is that Office has outgrown them. 
There's a point beyond which menus and toolbars cease to scale well.  A
flat menu with 8 well-organized commands on it works just great; a three-level
hierarchical menu containing 35 loosely-related commands can be a bit of a
disaster.

In short, we're not trying to destroy anything.  Our goal is to create a
new standard user interface for full-featured productivity applications.  The original
team who built Word or Excel couldn't have imagined how much their products
would be able to do today.  I want us to step back, to think through the
question: "what kind of interface would they have built knowing how Word turned
out?"

Let's take a more visual look at the scale issues facing Office.  Here are a few charts, demonstrating the number of top-level menu
items, toolbars, and Task Panes included in the product, from Word 1.0 to Word
2003:

Number of top-level menu items in Word, by release

Number of toolbars and Task Panes in Word, by release

As you can see, the number of features using all UI mechanisms goes up virtually
every version.  Keep in mind that every toolbar includes between 10 and 50
commands, often presented only as 16x16 unlabeled icons.

Here's another way of visualizing how much Word has grown in the last fifteen
years.  This pie chart represents the percentage of all features introduced in each
version and illustrates how much more today's Word can do compared to the first
few versions.

Percentage of Word features added in each version

(By the way, all three charts above were created with Beta 1 of Office 12
just by using the new gallery-based Chart UI. No tweaks required.)

There are several ways one could approach this kind of scale problem.  We
could have just cut half of the features from the product and left the UI as-is. 
(Well, actually a pretty major redesign would have been required to deal with
half of the commands being gone.)   But which half to get rid of?  Many
attempts have been made to imagine a "Lite" version of Office, both at Microsoft
and elsewhere in the industry.  It's hard because virtually all of the features do get used and
every feature is someone's favorite. 

When we get evidence that a feature is hardly used at all, we sometimes do remove it
from the product--but even then Microsoft feels pain as the people who rely on
that feature lash out.  No one's ever figured out the true "half of a
spreadsheet" that appeals to the broad market.

Another way we could deal with the scale issue is by factoring the products
differently.  Perhaps if Word were broken up into eight separate apps--say
a text editor, a printing/page layout app, a table maker, a picture editor, a drawing program,
a spelling/grammar checker, a mail merge engine, and an envelope/label printer.  Then each one could
have a more manageable menu and toolbar structure.  When you install
Office, we could put 65 icons in the Start menu.

But that would be going in a direction completely contrary to what our customers ask us for.  We're constantly
prodded to do more integration, to do better integration.  In
the places where are there separate "apps" today (such as the Equation engine in Word
or the Chart engine in PowerPoint), these are incredible pain points for
customers and they implore us to integrate the functionality.

So, our decision wasn't to make Office 12 stupider or more fragmented. 
Instead, we worked to embrace the integration and rebuild the user interface to
give us runway to build the next decade of productivity features.  This is
why concepts such as
contextualization and
galleries are so pivotal to the new
UI--they help break the functionality of Office into more manageable pieces
while maintaining the integration that makes the product powerful.

Next week, I'll delve into how we use the data we get from "SQM"... also
known as the Microsoft Office
Customer Experience Improvement Program.