Jensen Harris: An Office User Interface Blog : Why the New UI?

Grading On the Curve (Why the UI, Part 8)

jensenh — Tue, 11 Apr 2006 17:00:00 GMT

This is the eighth 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 two posts, I've discussed the Customer Experience Improvement Program and some of the data we've collected from the program.

How do we use that data to influence the design and organization of the Office 2007 user interface?

If you plot the command usage of the Office applications on a graph, you get a curve. A few commands account for a lot of clicks, and then slowly the number of clicks per command tapers off. We use the data represented by the curve to inform us about how often people use certain commands. The curve itself helps us visualize the usage pattern of the overall program and the average "depth" to which most people use the product.

Many people suggest that "you guys should optimize the UI to match the feature usage data." On the surface, this sounds like a solid idea; you could have a computer determine the organization and prominence of different features depending on what part of the curve they are in. It would be very scientific. The only problem? We've already designed that product, and it's called Office 2003.

Put another way: if all we want to do is design a product that matches today's pattern of feature usage--well, I don't have to do any work! Office 2003 already matches the curve exactly; we can't do any better than statistical perfection.

The real equation at work here is data + human = design. We need to take the data, analyze it, understand its shortcomings, and use it to inform a design which meets our goals. But, in itself, the data cannot produce a UI because it has no goals and is a reflection of the DNA of a product you already shipped!

Twice a day, I go in and swap out the tapes...

So, back to the initial question. How can we use the data to inform the Office 2007 design? There are two less obvious ways.

One thing we do is to look for desirable features that have low usage numbers. In general, this combination is a great opportunity for us to take advantage of work we've done in a previous version by helping people find useful features that they don't know are there. We can measure the "desirability" of a feature in several ways: a lot of direct customer requests, questions about the missing functionality on newsgroups and message boards, and sometimes just our gut feeling that people would like a feature if they only could find it. An example of this is the feature in Word that allows you to put a watermark behind a document. Lots of people ask how to do it, but can't figure out how. The prominent gallery of watermarks in Word 2007 has already caused many people to comment what a "great new feature that is."

Of course, there are things that can derail this process. Number one, a low-quality or poorly-designed feature will not succeed no matter how easy it is to find in the UI. Where possible, we've tried to "spruce up" old features in order to make them worth raising their prominence. Secondly, a bad name for a feature can turn people off from using it. Do we change the name, hoping that new people will discover it? Or do we keep it the same, knowing that it hurts discoverability but also that existing users of the feature won't be confused. It's a hard judgment call to make sometimes.

The second way we use the data is by looking for frequently-used features that are hard to get to today. Any time we see this, it represents people overcoming the user interface to use a buried feature because it's so important. A great example of this is "superscript" in Word. In Word 2003, it must be added to the toolbar manually through customization. Yet, even as a non-default toolbar button, it gets more clicks than 30% of the buttons on the Formatting toolbar. The opportunity here is to discover the things that people love and that even more people would use if they knew they could.

The point of both of these exercises is to reshape the feature usage curve. We want to see more people using a broader set of tools and saving time because of it.

Of course it's true that we also use the feature usage data to figure out which commands need to be ultra-efficient and which can be taken out of the product entirely, but that's really the less lofty part of our goal. Success for the Office 2007 UI means that we broaden the Office 2003 feature curve, not that we match it.

No Distaste for Paste (Why the UI, Part 7)

jensenh — Fri, 07 Apr 2006 17:00:00 GMT

This is the seventh 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.

Last time I issued a challenge: for readers to pick the most-used command in Microsoft Word 2003 and also the top 5 most-used commands (bonus points for having them in order.)

For me, the most interesting part was reading the justifications around the guesses. I'll reproduce a few of them here:

"Ctrl-Z Undo has *got* to be one of the top 5. I'm sure that bold/italic are in there too."

"...Save is very rarely used. Most end-users I've known are very hostile to the idea of saving frequently."

"I disagree with everyone. My mother can't cut and copy and paste, and she's probably much more of a typical user than any of us."

"normal ppl don't use Print Preview."

Now you have a pretty good idea what designing software at Microsoft was like before we collected data through the Customer Experience Improvement Program. Our internal discussions would have been peppered with the same wild guesses, justifications, and personal "anecdotes" served up as fact.

And looking over the guesses, one can't help but be surprised at the variety of commands nominated. From "Word Count" to "Tab Adjustments" to "Final Showing Markup" to "Header Style", is it any wonder it's a bit tricky to design a feature organization for software used by 400 million people?

The only difference between your wild guesses and ours would have been that ours would have become reflected in the product. If someone had a strong feeling that a particular feature was important and could convince people with her justification, then probably the product would have reflected that person's bias. We do try to hire people with a good "sense" of how the software is used--but this is most powerful when combined with the real data to back it up.

We're hard at work mining data from Office 2003

OK, time for the big moment. The data set I'm pulling from is all Word 2003 users who have opted in to the program. We could slice the data based on, perhaps, CPU speed to try to get more power users. Or 800x600 screen resolution, to try to get more home users. But in this case, we're looking at the entire data set of commands executed through any means (toolbar, menu, context menu, or keyboard shortcut.)

Top 5 Most-Used Commands in Microsoft Word 2003

Paste

Save

Copy

Undo

Bold

Together, these five commands account for around 32% of the total command use in Word 2003. Paste itself accounts for more than 11% of all commands used, and has more than twice as much usage as the #2 entry on the list, Save.

Paste is also far-and-away the number one command in Excel and PowerPoint, accounting for 15% and 12% of total command use, respectively.

Beyond the top 10 commands or so, however, the curve flattens out considerably. The percentage difference in usage between the #100 command ("Accept Change") and the #400 command ("Reset Picture") is about the same in difference between #1 and #11 ("Change Font Size") This is what makes creating the new UI challenging--people really do use a lot of the breadth of Office and beyond the top 10 commands there are a lot of different ways of using the product.

Here's an example of where we used this very data to help make a decision in Office 2007. Early on, we were toying with the idea of not having buttons for Cut/Copy/Paste in the Ribbon. Everyone "knew" that people mostly used CTRL+X/C/V to do most clipboard actions (which was true.) And that mouse users used the context menu to access these clipboard commands (which was also true.)

What we didn't know until we analyzed the data was that even though so many people do use CTRL+V and do use "Paste" on the context menu, the toolbar button for Paste still gets clicked more than any other button. The command is so incredibly popular that even though there are more efficient ways of using it, many people do prefer to click the toolbar button.

The data kept us from making a crucial, stupid mistake. One which we might not have caught during the beta due to the high expertise level of our beta users. Once we recognized the importance of the Paste toolbar button, it was promoted to the first big button on the left side of Word's first tab.

A few people asked in comments about the top "actions" done in Word 2003. Here they are: Cursor Right, Cursor Left, Cursor Down, Backspace, Cursor Up. Even the last of these (Cursor Up) is done about 8 times more than Paste, so people are doing a lot of cursoring around in the document (as you'd expect.) We don't collect letter and number presses, but I expect you would find that they line up along expected frequencies...

So, without further ado, the winners of the contest:

Grand Prize: "herzi", for guessing "paste, copy, save, print, undo" That's 4 out of 5, with #1 guessed correctly as Paste.
Second Prize: "John C. Kirk", for being the first one to guess Paste correctly as the #1 used command.
Third Prize: "Step", for being first to correctly guess 4 out of 5.

Congratulations to all three winners! Your frame-ready award certificate is ready to be picked up.

To everyone else, thanks for playing and better luck next time.

Inside Deep Thought (Why the UI, Part 6)

jensenh — Wed, 05 Apr 2006 17:00:00 GMT

This is the sixth 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.

Microsoft is tracking your every move!

Soon after you install Office 2003 on your computer, a balloon pops up asking if you would like to "Help Make Office Better." If you click on it, you are given the opportunity to enroll in something called the Microsoft Office Customer Experience Improvement Program. If you opt-in, anonymous data about how you use Office are uploaded to Microsoft occasionally in the background.

If you're the curious type, you might have wondered where your data goes. Well, today I'm here to answer the question: it goes into an Excel spreadsheet I have sitting on my desktop.

OK, back up. Back in the olden days of designing software at Microsoft (say, pre-2003), design decisions were mostly supported by guesswork. There's a classic Microsoft interview question (that I've never heard of anyone actually using) "How many gas stations are there in the United States?" Many have criticized that type of question as being feckless; personally, I agree and it's not representative of how I choose to spend my interview time with a candidate. But the rough "estimate an answer and defend it" style required to answer the gas station question was at the heart of how many design decisions used to be made at Microsoft.

Suppose you were designing the adaptive menus in Office 2000 and you wanted to know what features people use the most. Well, you start by asking a "guru" who has worked in the product for a long time. "Everyone uses AutoText a lot," the guru says. The louder the "experts" are, the more their opinions count. Then you move on to the anecdotal evidence: "I was home over Christmas, and I saw my mom using Normal View... that's probably what most beginners use." And mix in advice from the helpful expert: "most people run multi-monitor, I heard that from the guy at Best Buy."

So much of what we did was based on feel, estimation, and guesswork. How much that was true only became clear with the introduction of a technology called SQM (pronounced "skwim").

SQM, which stands for "Service Quality Monitoring" is our internal name for what because known externally as the Customer Experience Improvement Program. It works like this: Office 2003 users have the opportunity to opt-in to the program. From these people, we collect anonymous, non-traceable data points detailing how the software is used and and on what kind of hardware. (Of course, no personally identifiable data is collected whatsoever.)

As designers, we define data points we're interested in learning about and the software is instrumented to collect that data. All of the incoming data is then aggregated together on a huge server where people like me use it to help drive decisions.

Hard at work in the SQM data center.

What kind of data do we collect? We know everything from the frequency of which commands are used to the number of Outlook mail folders you have. We know which keyboard shortcuts you use. We know how much time you spend in the Calendar, and we know if you customize your toolbars. In short, we collect anything we think might be interesting and useful as long as it doesn't compromise a user's privacy.

How much data have we collected?

About 1.3 billion sessions since we shipped Office 2003 (each session contains all the data points over a certain fixed time period.)
Over 352 million command bar clicks in Word over the last 90 days.

Reflected in these numbers is that we don't even retain all the data points we receive... particularly, we get so much Word and Outlook data that 70% of it is thrown away.

So, one of the biggest reasons that we decided to do the new user interface for Office 12 is simply that, for the first time, we have the data we need to make intelligent decisions. Anything we would have done in the past would have been based more on guesswork and bias than on reality. Data is just one input to the design process, of course, but there's something extraordinarily empowering about knowing which commands people use often and which they don't. And knowing which commands are used in sequence with which other commands. And which commands are used 7x more with the keyboard than with the mouse. And how big people's screens are... and how much of the time they use Excel maximized... and how many documents they use at once... and which commands literally are never used... and which are used much more frequently by East Asian users... and on and on...

Knowledge is power. And having that knowledge makes this the right time to reinvent the user interface of Office.

Want to guess what is the most-used command in Microsoft Word? The top 5 commands used? Post your guesses in a comment and I'll answer in the next post.

(OK, this is a repost so a lot of you know the answer already. If you want to view the guesses from the first time I posed this question, view the comments with the original post here.)

Tipping the Scale (Why the UI, Part 5)

jensenh — Tue, 04 Apr 2006 17:00:00 GMT

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.

New Rectangles to the Rescue? (Why the UI, Part 4)

jensenh — Mon, 03 Apr 2006 17:00:01 GMT

This is the fourth 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.

Last time I discussed the UI mechanisms added to Office 2000 intended to reduce the perception of bloat: Adaptive Menus and Toolbar Rafting. I did want to add something I forgot last week. Steven reminded me that the earliest versions of both Excel and Word for Windows had two versions of all the top-level menus, short and long. By default, only a small number of commands were shown, and a user could click the View - Full Menus command to cause the full list of commands to appear. This is interesting because I'm told the push to move back to the "short menus" was an important influence that impacted the design of Adaptive Menus in Office 2000. Just a bit of historical housekeeping.

Today, I'm going to take you forward all the way to Office 2003 and write about two new rectangles that appeared on the screen in recent versions: the Office Assistant and Task Panes.

I'm not going to spend a lot of time on the Office Assistant (a.k.a. "Clippy", a.k.a. "Clippit"). I was introduced to it probably the same way as a lot of you--I was still in college, and a friend got Office 97 loaded on his new computer. I was somewhat puzzled by it, but I did spend time looking at the different choices (I liked Einstein.) I also spent some time right-clicking on it to make it do funny animations. Once I got Office 97 for myself, I'm pretty sure I kept the Assistant on for a while so that people who saw my computer would think I was cool. In a few months, everyone had Office 97, and the Assistant had lost its geek cachet. Besides, I had papers to write, and that's when I'm pretty sure I turned it off for good.

There's been a lot written about Clippy already; if you want to learn about more of the history, I'd read Steven's analysis entitled "Learning from the past." I wasn't at Microsoft then, and most of the people who worked on Assistant v.1 are now elsewhere, so I don't have a lot of historical insight to offer.

I will say this: the Office Assistant was more an experiment in providing contextual help than it was a new UI mechanism. I know because of the e-mail you've sent me that a lot of you want me to write about Clippy. But honestly, it didn't really factor into the Office 2007 discussion as a direction to look at other than that we had to finally take it out of the product for good this time (no option to turn it back on.) If you're looking for a scholarly discussion, you can dig into some of the reasons people found it annoying.

Let's leave it as this: the Assistant wasn't really relevant to the Office 2007 UI, it was more about the evolution of help than the evolution of interaction design, and I personally don't have any good stories about it. R.I.P. Clippy. The end. (OK, I do know one interesting anecdote: the Japanese version of Office used a dolphin named Kairu as the default Assistant.)

A much more relevant rectangle to the Office 2007 discussion is the introduction of Task Panes in Office XP.

As I have discussed before, by Office 2000, menus and toolbars were essentially full. Each additional item that we added was such a small percentage of the overall structure that people didn't even notice new commands from version to version. The relatively poor organization of the menu structure didn't help. So, when Adaptive Menus failed to catch on, Office had a problem--people weren't finding and using the new features.

Contrary to the conventional wisdom of the naysayers, we weren't (and aren't) "out of ideas" for Office. Customers weren't telling us that they didn't need new features--to the contrary, the list of requests is a mile long. Every version we were putting our heart and soul into developing these new features, undergoing a rigorous process to determine which of the many areas we would invest in during a release, and then working hard to design, test, and ship those features. The only problem was that people weren't finding the very features they asked us to add.

The Task Pane was an attempt to bypass the menu and toolbar structure altogether by exposing new features through a new rectangle on the screen. The thought was that people wouldn't be able to miss a whole new rectangle on the screen and, therefore, they would find and use the new features.

(Click to view full picture)

The Task Pane was completely additive; it made no attempt to change the existing menu or toolbar structure. For the most part, legacy features lived in menus and toolbars, and new features lived in Task Panes. The PowerPoint team probably did the most work to embrace the Task Pane model in their user interface between Office XP and Office 2003; a few legacy features, such as Slide Transition (above) did migrate to the Task Pane.

One of the most controversial internal discussions at the time was whether the Task Pane should go on the left or the right. It started out on the left, which gave it a more primary space in the UI, thought especially key for the New Document Task Pane. On the other hand, it conflicted with the PowerPoint left pane, causing a bit of a mess over there. In the end, the reason it finally got moved to the right for good was that on the right the Task Pane wouldn't cause the document to shift as it opened and closed.

The downsides of the Task Panes were many. Number one, given that all the menus and toolbars still had to be present, it did take up a lot of space, as you'll see if you reflect back on my now infamous "Mythbusters" post. Worse, because it didn't actually replace any of the existing UI metaphors, it created yet another rock for users to look under. Now, in addition to short menus, long menus, hierarchical menus, visible toolbars, and the toolbar list, a user had to look through the Task Pane stack as well for features. It just added complexity to the product.

Probably my biggest misgiving about Task Panes is that they encourage bad interaction design. Every PM wanted to design their feature as a Task Pane because they could have a brand new, clean rectangle to put their feature in. This makes their job easier and your experience, as a person using the software, worse. Every feature would whack away the Task Pane of the previous feature (because only one could be up at once.) Some of the Task Panes were quasi-wizards with multiple pages, some of them were really dialog boxes, some of them were just a menu of two commands with a bunch of explanatory text around them. No one really thought about the experience of how to reconcile all of the Task Panes--how to find related functionality in the old UI system, how to use two features at once, and the fact that ever single feature required its own huge rectangle. In just two releases, ending with Office 2003, we already stretched the limit of Task Panes as a manageable UI paradigm.

When we started Office 2007, before any of the application teams really took it seriously that our team was going to deliver on a new UI (you know, healthy skepticism and all that), we looked at the early designs for some of the proposed features and realized that Office 2007 was going to have 10 times as many Task Panes as Office 2003, and it was just going cause a UI train wreck. I honestly believe we would have had to ship 100 Task Panes in Word 2007.

The Task Pane was the last attempt to find a way to scale old-style UI to programs as full-featured as Office. Although it was a successful stop-gap measure, it ran its course in only two versions. I'm reminded of Nathan Myhrvold's First Law of Software: "Software is a gas." Every time we add a new UI mechanism, it fills up. Because we only added and never renovated/reorganized/removed, complexity went up each release.

Office 2007 is our chance to build a new interaction foundation for the next decade of productivity software.

Combating the Perception of Bloat (Why the UI, Part 3)

jensenh — Fri, 31 Mar 2006 17:00:00 GMT

This is the third 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.

Last time we started a walk down memory lane by taking a look at the first five major versions of Word for Windows. I ended by showing Word 97, a major milestone release which included many useful new features and improvements. Office 97 also introduced command bars, a paradigm in which menus and toolbars were made more similar in capability and visual design. All this new functionality came at a cost, however, and part of this cost was increased complexity in the user interface, mainly through the addition of new menu items and toolbar buttons. Responding to this, the industry press started publishing articles and popularizing the idea that Office was "bloated."

In reality, the programs themselves weren't "bloated." At least, the miles-long list of feature requests from customers indicated that, if anything, people expected us to do more in this space. What had happened, however, was that the user interface had begun to feel bloated. Like a suitcase stuffed to the gills with vacation clothes, the menu and toolbar system was beginning to show signs of not being scalable enough to fit the richness of the product. It was becoming harder to get the zipper shut each release. Some people perceived the result as "bloat."

Office 2000 introduced several new UI mechanisms designed to reduce this perception of "bloat." In many ways, this release marks the beginning of the road that eventually turns towards the redesign of the UI in Office 2007.

(Click to view full picture)

The first new mechanism, called "Adaptive Menus" or, later, "Personalized Menus" were an attempt to make the top-level menus appear shorter by showing the most popular items first. After a few seconds (or after pushing a chevron at the bottom of the menu) the menu expanded to show the full contents. As you used the menus, items you used often were promoted to the "short" menu and items you never used were demoted to the "long" menu. This was the adaptive part, and the idea was that eventually you'd have a fully-tuned, auto-customized UI that would show you only what you need and use.

(Click to view full picture)

Adaptive Menus were not successful. In my opinion, they actually add complexity to the interface. Why? Several reasons:

There was no way to get the default "short" menu right. Although conventional wisdom holds that "everyone only uses the same few features in Office," the reality is that people use an amazingly wide range of functionality. So, one person's ideal default "short" menu was exactly the wrong thing for someone else.
Once the default short menu was wrong, the user was forced to scan the menu. However, scanning adaptive menus requires two passes: scan the short menu, press the chevron, then back to the top to scan the long menu. Because the secondary menu items could appear between short menu items, the appearance of the long menu caused your scan to reset. As a result, scanning menus took twice as long Even if they had designed it so that pushing the chevron revealed the bottom part of the menu (and the top part didn't change), at least you'd only have to scan the menu once. So, adaptive menus added a lot of inefficiency.
Auto-customization, unless it does a perfect job, is usually worse than no customization at all. Although the algorithm used to promote and demote menu items is rather complex and well thought-out, it's not perfect. Because it's not perfect, it does the wrong thing a lot of the time. (If it's even clear what a "right thing" is for a feature like this.) What people experienced is a sense randomness and unpredictability: one time, a menu item would be in a certain place, and then two days later it wasn't there anymore.

As a result, even for the Office 2007 applications that are still using old-style UI (such as Publisher, Project, and Visio), we've turned off Adaptive Menus by default.

The other new mechanism in Office 2000 designed to reduce the perception of bloat was "rafted toolbars." In this design, two or more toolbars could share a line on the screen. By default the Standard and Formatting toolbars were "rafted" together onto the same row. As there wasn't space on most monitors for both toolbars, a complex algorithm decided which toolbar buttons were least likely to be used and those were moved from the toolbar into an overflow area at the end. Just like with adaptive menus, as you used the toolbars, buttons were promoted and demoted from the toolbar and moved to/from the overflow area.

(Click to view full picture)

The rafted toolbars add complexity for the same reason as the adaptive menus do. The order of commands was no longer constant, scanning for functionality was inefficient, and predictability suffered as nothing could ever be guaranteed to be in the same place even from click to click.

The result: most customers, especially those in corporate environments, turn both of these features off.

So, if these mechanisms were so flawed, why were they introduced into the product in the first place?

First, remember that we're analyzing this with 20/20 hindsight. As computers got more powerful, there was a lot of excitement (not just at Microsoft) about "auto-customization" and using the power of the computer to present exactly the right UI for the person at hand. Now, it's easy to say that today people are generally against this idea because it seems to cause unpredictability, but we know that mainly through trying experiments such as the adaptive UI in Office 2000.

But the second, more important piece is that the people who worked on these mechanisms were working within a very narrow set of requirements. Office was known at the time for being very conservative about the user interface; as I discussed last time, until Office 2007, the top-level menu structure of Word hasn't changed since 1989. This consistency was a good thing in many customer's minds, because an unchanged UI meant virtually no retraining costs.

Whatever enhancements were designed had to be done within the confines of not changing the structure of the UI. This means that, if you want to have short and long menus, you have to make the long menu items show up in-place--otherwise you're changing the order of well-known menu items (which would have been a non-starter.)

Similarly with the rafted toolbars, there's only so much you can do to make the toolbars simpler if you can't change the core contents of the Standard and Formatting toolbars.

So, it's not as if we're somehow smarter than the people who worked on the Office 2000 UI. (In fact, some of the biggest supporters of the Office 2007 UI today are people who worked on and taught us what they learned from these earlier versions.) They had to try to reduce the perception of bloat--to combat the fullness of the menus and toolbars--without changing the actual contents of the menus and toolbars. It was kind of like when I was told to clean my room as a kid and I just hid everything under the bed. It looks good on first blush (and on the back of the box), but the facade doesn't hold up for long.

In the end analysis, we didn't end up making the suitcase any bigger or the zipper any easier to close--we just added more pockets.

Next week, we'll take a detour into one of the special exhibits at Ye Olde Museum of Office Past: the "Office Assistant" wing.

Ye Olde Museum Of Office Past (Why the UI, Part 2)

jensenh — Wed, 29 Mar 2006 17:00:00 GMT

This is the second 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.

Today, I want to take you on a journey. A journey that starts back into the cold recesses of the mid-1980s, back into the days of EGA and serial port mice and the MS-DOS Executive.

Microsoft Word 1.0 for Windows shipped in 1989 after a long development cycle and was designed to run on Windows 386. There's not much more to the program than what you see here, but it gives you an idea of how far Word's come. The Berlin Wall was still up but if you squint your eyes, you can see the core of today's Word UI already present. There's an application-level menu bar, which Windows evolved from the Mac's top-level menu bar and the bottom-of-the-screen menu display of Microsoft's DOS programs. Word 1.0 also includes something not seen often in user interfaces since PARC: the toolbar. First used by Microsoft in Excel, it might look like there are two toolbars in Word 1.0, but in reality only the top bar is called a toolbar. Interestingly, the bottom row of buttons is called the "Ribbon"--something we didn't discover until I went back and made these screenshots some number of months ago. It's a small world.

(Word 1.0 - Click to view full picture)

By the time Word 2.0 hit the market in 1992, the basic structure of the Word user interface has already solidified exactly as it is in Word 2003 today. File, Edit, View, Insert, Format, Tools, Table, Window, Help. A "Standard" and "Formatting" toolbar. Here's a program that was in design more than 15 years ago and yet the basic user interface has remained stable all this time. (I was in junior high school at the time, programming on my Apple //c.)

(Word 2.0 - Click to view full picture)

Yet, the thing was, this UI worked well for a program like Word 2.0. It had fewer than 100 commands, and because the Word team was able to plan the ideal menu structure for their program, the organization made sense. The toolbars were simply efficient duplicates of functionality found in the menu structure--no features existed only on toolbars. Browsing the menus was straightforward and fast--most menus had less than 10 items on them, and no menu hosted any fly-off hierarchical menus.

Word 6.0 was a runaway hit. Capitalizing on the popularity of Windows 3.1, this was the turning point in Word's competition with WordPerfect. In terms of new user interface evolution, Word 6 introduced right-click context menus, tabbed dialog boxes, wizards, and toolbars along the bottom of the screen. The number of toolbars jumped from two in the previous version to eight in Word 6, and the menus became more full as features were added to the product.

(Word 6.0 - Click to view full picture)

Word 95 was the first 32-bit version of the product, designed to ride the wave of hoopla from the Windows 95 launch in August 1995. Although it was pretty much a straight port of Word 6, one small, innovative feature was introduced that most people would agree they wouldn't want to live without: red-squiggle underlined spell-checking. Many people cite Word 95 as the last in a generation of simpler, trimmed-down, pre-Internet word processors.

(Word 95 - Click to view full picture)

While a small team had been working to port Office to the 32-bit OS and eventually shipping Office 95, a much larger team was working on what would become Office 97. Office 97 was a huge blockbuster, setting software sales records. Chock full of new features, Word 97 marked the beginning of a new stage of super-rich productivity apps.

(Word 97 - Click to view full picture)

This richness took its toll in complexity, however. Office 97 introduced "command bars", an ultra-customizable user interface in which menus and toolbars were really the same thing. Every menu and toolbar could be dragged around to every side of the screen and floated or docked. Feature designers within Microsoft took full advantage of this new technology, with the number of toolbars rocketing up to 18 and the number of commands on the top-level menus nearly doubling.

Arguably, the most important UI decision made in Word 97 was a simple one: introducing hierarchical menus. In all previous versions of Word, menus were a single list of items--easily scannable, easy to navigate. Excel, taking a cue from 1-2-3's labyrinthine UI, had previously introduced hierarchical menus and though there was an internal struggle between the development teams, eventually the Excel model prevailed and Word 97 got multi-level hierarchical menus.

Why was the decision made? Well, the top-level menus in Word were full. Although an ever-increasing number of features were implemented only on toolbars, some features still needed menu entries and no room was left for them. Wrapping commands into multiple levels made more room for new commands. More room meant more features.

The downside, however, was clear and eventually terminal: increased complexity. It's much more difficult for people to form a scanning strategy with hierarchical menus: you have to keep track at each moment which levels you've visited and which you've haven't. What was once a simple structure to visualize was now a more complicated, branching structure. Browsing for features was now less like looking at a shopping list and more like traversing a complex data structure.

Word 97 was the first version in which we started to see signs that people were feeling less in control of the program. Office 97 was a huge hit with both individuals and companies, but It was also marked the beginning of a long series of press stories accusing Office of being "bloated."

(How interesting that today some people hearken back to Office 97 as being some sort of ultra-simple software panacea and how different that is from how people viewed it at the time.)

Next time: How Office worked to reduce the perception of "bloat."

The Why of the New UI (Part 1)

jensenh — Tue, 28 Mar 2006 17:00:00 GMT

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

Any discussion about the graphical user interface of computers today has to start all the way back at the Xerox Palo Alto Research Center (PARC) in the 1970s. An amazing and ultimately historic collection of brainpower came together to work on the Alto and later Star systems. A remarkable collection of technologies and concepts that are now commonplace were first incubated at PARC: WYSIWYG (what you see is what you get), the use of the mouse, the desktop metaphor (including folders and icons), overlapping windows, Ethernet, laser printing, and a number of the controls that now encompass the modern user interface: menus, scroll bars, edit controls, check boxes. This picture gives you some idea of what the Star interface looked like. (Some idiosyncrasies of the Star, such as the fact that you had to click on inactive windows in order to cause them to paint, are largely forgotten today.)

(Click to enlarge)

The Star was not a commercial success, and today many technology historians point out that Xerox did not do very much to protect the intellectual property they created. As a result, most people today think of Xerox as just a copier company despite the essential role PARC played in incubating the modern user interface.

Many of the influential contributors to the ideas behind the Star found their way to other companies, notably Microsoft and Apple. Apple was first to borrow and expand upon the ideas of the Star, first in the failed high-end Lisa system and then later in the Macintosh. Lisa standardized a number of designs that are still used in many modern user interfaces: the top-level menu bar, the concept of checking selected menu items and graying out those that are disabled. (The changes weren't all good--some PARC ideas abandoned by Apple, such as proportional scroll bars, didn't make their way back into the mainstream until Windows 95.) If you're interested in a more detailed history with screenshots, Jeremy Reimer has an interesting site.

The Macintosh went on to to inherit much from the Star and Lisa and, of course, the Mac brand name carries on today. Microsoft worked with early Apple prototypes to develop Word 1.0, which shipped in 1984 with the original Mac. Multiplan and Chart were also under development for the 512K Mac, and they eventually shipped together in 1985 as Microsoft Excel 1.0: the first blockbuster retail program available for the Macintosh (and the stated reason many people purchased early Macs.) Here you can see pictures of early Microsoft productivity apps in Apple advertising from 1984

Thus, the roots of the early Microsoft Office programs were rooted in the Mac and of course, the user interface reflected that. As the Mac's first and biggest provider of software (a title Microsoft still holds today), some of the UI decisions made in the original Macintosh were influenced by the needs of Microsoft's development teams. While the extent to which it is admitted this happened varies widely depending on the personal account, it is safe to say that the programs were developed with an intimate understanding of the system and vice versa. Certainly, the basic outline of Office's graphical user interface (especially the use of a top-level menu bar) has its roots in that first Macintosh version.

Next time, we visit "Ye Olde Museum of Office Past" and look at Word for Windows through the ages.