다음을 통해 공유

Tipping the Scale (Why the UI, Part 5)

  • 아티클

This is the fifth part in my eight-part series of entries in which I outline some of the reasons we decided to pursue a new user interface for Office 2007.

Over the last few articles, 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

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 2007 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.

Comments