Jensen Harris: An Office User Interface Blog : History

The Story of the Ribbon

jensenh — Wed, 12 Mar 2008 10:00:00 GMT

I was reading through commentary from people who attended last week's MIX conference in Las Vegas. Running across Miguel de Icaza's kind words reminded me that I hadn't posted a follow-up about my MIX talk yet.

Last week, I presented a session at MIX called "The Story of the Ribbon." I talked a bit about the general design process we used to come up with the Office 2007 user interface, to iterate on it, and to evaluate it. As part of the discussion, I showed for the first time some of the early prototypes we worked on (and abandoned or refined) along the way.

It's always fun to present substantially new content, and this was my first time giving large portions of this talk. The audience was great and, although you can't hear them on the video, they seemed to be into it and enjoying the presentation. It was a lot of fun!

Watch "The Story of the Ribbon"
(Video, audio, and slides)

Download "The Story of the Ribbon"
(Slides and audio only, Windows Media, 146 MB)

Alternate Formats:

Download for iPod
(.mp4, 121 MB)

Download the PowerPoint slides only
(.pptx, 20 MB)

Dowload the slides only as a PDF
(.pdf, 19 MB)

Although I showed a few prototypes, I truly only scratched the surface of what the team created during the design phase of Office 2007. I spent a weekend painstakingly going through thousands of pictures to choose a few representative samples to show. Because I only had 75 minutes, I knew clicking through 25,000 pictures probably wasn't going to work.

Here are photos of the beginning and the end of the talk courtesy of Long Zheng. (You'll have to watch the presentation to see what's in-between!)

Over the last few days, the screenshots of the evolution of Word from version 1.0 to 2003 have been lifted from this presentation and subsequently posted and reposted all over the web.

That's OK, but if you want to see the full, original screenshots along with the commentary and discussion, please read parts 2, 3, and 4 of the Why the UI? series of posts.

While at MIX, I also participated in a panel discussion called "What's the Secret Formula?" along with Mike Schroepfer from Mozilla, Dan Harrelson from Adaptive Path, and Daniel Makoski from the Surface team at Microsoft. This was an interesting discussion about some of the challenges inherent in delivering on great user experiences.

Watch "What's the Secret Formula?"

Thanks to everyone who came up and introduced themselves after the session and throughout MIX. I enjoyed talking to you and meeting so many of you face-to-face!

The Spelling Check is Complete

jensenh — Wed, 14 Jun 2006 17:00:00 GMT

Yesterday, I mentioned the new contextual spelling feature that is part of Office 2007. Writing the post reminded me of a story from years past...

One of the things we've tried to do from time to time is reduce the number of modal alerts that pop up as part of working with Office. Most people don't spend the time to read the text of message boxes--as a result, unless there's an action that needs to be taken, most people just click OK.

Long before we had the Customer Experience Improvement Program in Office 2003, we relied on data from something called the "instrumented version." This was a special build of Office we gave to a few hundred test subjects to collect a small amount of objective information on how people used the software. It was not nearly as complete or as representative as the CEIP data, but it was better than nothing.

So, when a team was tasked with reducing the number of alerts, they developed a magic formula for deciding which alerts to target: look for the most frequently-appearing alerts (based on the data) which contained only an OK button. Because we know that any alert with just an OK button is simply informative, and we know that most people don't read the text of alerts, knocking just the first 10 or 20 off the list held the promise of reducing the number of dumb alerts seen by Office users by billions and billions.

Dutifully, the team removed these seemingly useless alerts. The very top one on the list seemed like an absolute slam-dunk to remove: "The spelling check is complete." It's a totally unactionable alert--just an extra click people have to do every time they check their spelling. A perfect example of a useless, intrusive dialog box, interrupting your work and getting in your way. Bad design. Right?

Within hours, the complaints started to roll in. Within days, the complaints became deafening from all corners. It wasn't long before the alert was put right back in the product.

Why? People who were spell checking their document manually had no idea when the process was complete. If you've grown up expecting a dialog box to come up once all of the spelling errors are corrected, and now the software just sits there silently--well, it’s no wonder people thought the program was just broken. Or very, very slow.

Spell check is one of those great features that have a beginning, a middle, and an end. The beginning is you clicking the spell check button. The middle is the computer conversing with you about potential misspelled words and giving you an opportunity to fix them. And the end is the computer telling you that the process is complete.

It’s a truly collaborative, uncomplicated interaction between user and computer. The "spelling check is complete" alert is a form of exactly what dialog boxes are named for: dialogue. The computer telling you that it’s finished rounds out and completes the process. It's no different from a checker at a grocery store saying "Here's your receipt, thank you for shopping at Thriftway." It’s a very human way of ending a transaction.

I guess the meta point here is that it's hard to do interaction design by formula. Not many great works of art are achieved through Paint By Numbers.

You Windows 3.1 Lovers!

jensenh — Thu, 08 Jun 2006 17:00:00 GMT

Earlier this week, I somewhat humorously referred to people who close windows on the left side as "Windows 3.1 lovers." What did I mean by that?

The now-ubiquitous close button in the upper-right hand corner of windows was only added to the operating system in Windows 95. Previously, as you can see in this picture of Word 6.0 running on Windows 3.1, the only caption controls on the right side of the title bar were minimize and maximize/restore. The way you closed a window was by double-clicking the little horizontal line icon in the upper-left corner of the window.

Windows 3.1-style title bar and MDI menu

Historical departure:
The keyboard shortcut for "open the system menu" in Windows has always been Alt+Space. Why? Because the icon that the menu comes out of looks like the space bar on the keyboard.

How, you might ask, do you open the MDI system menu located directly beneath the normal system menu? You guessed it, Alt+Hyphen, because the icon looks a lot like a hyphen. Of course, since Windows 95, neither of these icons looks anything like a space bar or a hyphen, yet the keyboard shortcuts remain the same even in Windows Vista (and likely forevermore.)

Back to the story:
Anyway, in Windows 95 the close box was added to the upper-right corner, but they kept the ability to close windows by double-clicking the product icon on the left side of the title bar. As a result, even some whippersnappers like me who barely remember computers pre-Windows 95 learned to close windows that way.

Whoops, I let out my big secret.

You see, I'm a left-side double-click closer myself. It's embarrassing, I know, but I just can't break the habit. Oh so many times during the beta of Office I've moved my mouse to the upper-left corner, realized that I couldn't close the window, and then jumped to the other side of the screen to hit the close box.

We removed left-side close as a planned experiment. If people could get used to closing on the right side, we'd be better off because there wouldn't be two ways of doing the same simple action. Clearly if we were building a new window manager from scratch with no pre-existing users, we would only have one way to close windows.

But, of course, we have hundreds of millions of users, many of which (like me) literally have left-side close burned into the lower levels of our brain stem, along with breathing and keeping the heart beating. Honestly, I can seem to relearn anything except for this.

Nonetheless, we tried taking this out--we shipped Beta 1 Technical Refresh and Beta 2 this way and waited for feedback. Could people adapt? Not really, as it turns out.

Honestly, we knew all along that there was a strong possibility we would have to find a way to add this functionality back. It was worth a shot, but in the end, creating an affordance for left-side closing eliminates one huge annoyance that stands in the way of some people's enjoyment of the product.

Soon, I'll explain a bit about the design we decided on and the thought process behind it.

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.

The Long Road to Contextual Tabs

jensenh — Tue, 07 Mar 2006 15:00:00 GMT

Contextual Tabs are among the most important components of the Office 2007 user interface. They provide quick access to the contextual features which work with an object, much like context menus do. When you're working on a table, we add the Table Tools to the set of features presented. When there's no table present, the Table Tools are gone, greatly simplifying the Office apps. I wrote a whole post detailing how Contextual Tabs work last fall.

Click to view full picture

But coming to this design didn't come quickly or easily.

The earliest designs of the Ribbon had no concept of Contextual Tabs at all and instead had a Format tab. This Format tab changed its content depending on the object you were working with to present the features for use with that object.

This design had some major disadvantages. First, the Format tab was constantly changing its content. One of the design tenets around the Ribbon was predictability and consistency of UI--visiting a tab should always look the same. Yet, the whole idea of the Format tab violated this tenet; we had six top-level tabs which were consistent and one which was always changing. Not good.

Also, we found that the breadth of tools available to work with an object varied greatly. A simple drawing, for instance, has a relatively small set of tools, mostly formatting and aligning. A chart has most of the drawing tools plus chart-specific formatting and all of the layout and data analysis features of charting. A PivotChart combines all of the features of PivotTables, charts, and drawing into one experience. So, while a single Format tab worked OK for simple things, it wasn't capable of supporting the feature set of rich objects.

So, we knew that a Format tab wouldn't work and that some of the object-specific features would need to span several tabs. Our next iteration was something called Immersive Experiences, and we actually built this into the product for a while.

The idea behind Immersive Experiences was that as you started working with an object (say, a picture) the main tabs of the app disappeared and were replaced with a new set of tabs (the Picture Tools.) When you were truly working with your picture, the entire UI scoped to help you work with the picture. We even imaged totally changing the look of the app to show that you were kind of focused in on a specific object, and we spent a bunch of time thinking about how to deal with navigating back and forth between the main ribbon and the Immersive Experience.

As we got further into designing these experiences, however, we started to run into problems--both tactical and usability in nature. The tactical problems started here: You can add text to a shape. Well, if you have text, you can bold that text. So, I guess we copy the Bold button into the Immersive Experience. And Italic. And, in fact almost everything on the first tab.

But wait, it gets better. Think about tables: what if I want to put a picture in the table? I need the Insert tab also. And what if I want to change the margins of a paragraph in a text box? Well, then I need the page layout tools.

The kicker is this: in Word, your entire document could be inside a table cell. For certain kinds of East Asian documents, this is not at all uncommon. You literally need all of Word in the Immersive Experience for tables, and we kept having to move more and more of the app into the IX (as we called them).

And, as I mentioned, there were also usability problems. In particular, people felt jarred because it looked like another app launched and they wondered "why Excel went away." The "immersive" part of the design was what was throwing people off, and it felt unnatural, off-putting, and confusing.

As a result, between our first and second coding milestone, we iterated the design again and changed Immersive Experiences to Contextual Tabs. The idea was this: if you have to enable Bold for an object, then let people use it where they're used to it being: on the home tab. Similarly, if people want to add a comment to a table cell, why not let them do it where they always do it (on the Review tab) instead of designing some one-off UI.

Contextual Tabs, then, leave the core tabs of the program alone and simply add tabs for the object you are using. People can continue to use core commands just where they always have, yet the object-specific features have an expansive space in which to express themselves. Even better, the app experience feels more stable because the core tabs don't change, and this was a huge step forward in usability. For the first time, people were getting how the model worked and going crazy using their newly-found contextual tools.

Beyond this point, we still had a lot to figure out in terms of how the visual design of contextual tabs and the triggers to bring them up would work, and in a future post I'll get into these deeper aspects of the design.

Everything in this story happened well before Beta 1, and it was an incredible luxury to have a development team willing to adjust the product in such a major way once we found where we were headed wasn't working.

For me, it helped illustrate the value of planning for iterative design.

Which menu items get icons?

jensenh — Mon, 06 Mar 2006 15:00:00 GMT

One of the mysteries of the menus-and-toolbars based UI of Office 97-2003 is "which menu items get icons?" If you look at the top-level menus of any of the Office programs, you'll see that some items have icons and some don't.

As it was told to me by one of the designers who worked on it, originally the icons were given to menu items which also appeared on toolbars. As a result, there was a visual link between the toolbar icon and the menu item which would help to communicate their relationship. On the other hand, items which were not present in any toolbar (such as Format.Font in Word) didn't have an icon.

However, the rules for when to use an icon weren't really set in stone, and over time people started to use them for other reasons--to help a feature stand out on the menu or because the designer working on it wanted the sexy new feature to have an icon.

So we ended up with a bit of a mish-mash of features with icons and features without them. I'm not sure if it actually impacted usability at all (I sort of think it probably didn't), but if you were trying to discern meaning from the presence or absence of icons, there was not much to go on.

In the Office 2007 user interface, we're trying to be more consistent about which features have icons.

Specifically, all features represented in the top-level Ribbon have icons. This gives the visual design a more uniform appearance and helps guide the eye to the feature names. It also helps scaling, because in situations in which the Ribbon needs to shrink down into a very small space (think < 500 px.), we can scale features down to their icons and rely on the tooltips to reveal the feature names.

Crafting icons for so many features is an extremely time-consuming and expensive process, but one that should be worth it when evaluated as part of the overall fit-and-finish of the product.

The Feature Bob Invented

jensenh — Tue, 24 Jan 2006 18:00:25 GMT

It was a cold winter afternoon early in 2004, and we were in the midst of doing some of the first usability tests with a working, clickable prototype of the Ribbon. (Prior to that, most of our prototypes had been paper-based.)

This particular prototype was put together in PowerPoint as a fairly inexpensive way to mock up a basic Ribbon and to see whether people got the concept. Basically, we put a picture of each tab of the Ribbon in a separate slide in the PowerPoint deck. We turned off the "click to advance" functionality for each slide, and then drew a nearly transparent square around each tab of the Ribbon. Each of these squares was hooked up to an action so that clicking on them advanced to the slide that revealed the picture of the tab you were clicking on.

In this way, we were able to simulate a tabbed user interface just by drawing 8 or 10 pictures. None of the commands within the Ribbon really worked in these early prototypes; we just would watch and listen to see where they clicked within the tab.

The Ribbon is made up of tabs (click to view full picture)

Anyway, this afternoon our subject came in to the usability lab. I don't remember his name; I'll call him "Bob." Middle-aged and friendly, he was one of our least experienced test subjects, yet he caught on to the Ribbon paradigm quickly. Soon, he was finding the target features faster than anyone in previous tests, zooming from tab to tab as efficiently as we could imagine. Especially when he was asked to find features repeatedly (to test the learnability of the design), Bob was able to whisk to his target tab and acquire the requested feature extremely fast.

My colleagues and I were back in the usability control room, watching Bob's performance on TV, so we couldn't see exactly what he was doing with the mouse. But we could tell something was up.

So, after the test, the usability engineer started the debrief with Bob, asking how he liked what he used.

"Great!" he replied. "I especially love the way you can use the scroll wheel of the mouse to riffle through the tabs; it's so fast and easy!"

All of a sudden, we realized what had happened. Although we turned off the "click to advance" functionality in PowerPoint, it still has a built in behavior in Slide Show mode whereby scrolling the mouse wheel one tick advances your show by one slide. Reversing it takes you back by one slide. Because we had each of the Ribbon tab pictures in order in the slide deck, Bob was able to use the scroll wheel to browse through and acquire any tab he wanted. This was a totally unintentional and coincidental feature of the prototype, yet it was Bob's favorite part of the new UI.

Bob went on his way and we never saw him again. Unbeknownst to him, he helped design a major part of the interaction design of the Ribbon. Although we didn't get it working in time for Beta 1, in current builds you can use the scroll wheel to zoom between the tabs, just as Bob envisioned. It's great for quickly jumping to a tab, clicking a command, and then flicking your finger all the way up to get back to the main tab. It saves me clicks and time. (Using the scroll wheel below the Ribbon still scrolls the document, of course.)

Although the fact that many tabbed web browsers use the scroll wheel to switch tabs means that we might have thought of it anyway, I like to think of this as the feature Bob invented.

Thanks, Bob!

The End of Personalized Menus

jensenh — Fri, 20 Jan 2006 18:00:20 GMT

As faithful readers of this blog, you no doubt know that not every program shipping with the Office 12 "wave" of products has the new user interface.

This means that, at least for the time being, menus and toolbars are still alive as a part of many important programs, such as Publisher, Project, Visio, and several others.

The good news for fans of usability worldwide is that an historical moment is upon us. As of Tuesday, we have officially flipped the switch to turn off Personalized Menus by default for all apps in all future builds of Office 12. (New UI programs based on the Ribbon, of course, were designed without Personalized Menus from the beginning.)

Don't know what Personalized Menus are? You can read all about them in Part 3 of the "Why The UI?" series, including my take about why they weren't a good idea.

The option isn't going away, so if you do love this feature for some reason, you can still manually turn it on in Office 12. But the default setting for "Always show full menus" will be set to on, reversing the default first introduced in Office 2000.

A small but significant victory for humankind.

Fare thee well, Personalized Menus, an experiment whose time has passed...

Didn't know you could turn off Personalized Menus in your version of Office? Click Customize on the Tools menu, and check the box next to "Always show full menus."

A Better Box Of Crayons

jensenh — Thu, 19 Jan 2006 18:00:00 GMT

Perhaps because I was never the kid who had the super sized 128-pack of crayons, I never developed much of an artistic eye, especially for colors. Having only the 16-pack, with nary even the free crayon sharpener is something I obviously rue to this day. (Made worse by the fact that, only a few years later, my younger brother got a 64-pack of crayons complete with built-in crayon sharpener. Sigh.)

Anyway, the point is, if anyone needs help with colors, it's me. That's why I love that Office 12 helps me make better looking documents by improving the selection of colors throughout the product.

Now, it is true that many of the core Office 12 products (including Word, Excel, and PowerPoint) support a new model for document themes, which let you change the color scheme, font scheme, and special effects scheme on a per-document basis. Much can and should be written about how all of this works in the future.

But putting that aside for the time being, every document comes with a "default" theme which contains a color scheme full of well-matched colors. The result is that, even if you don't mess with the new theme or color scheme features at all, your documents look modern and well-matched. (Of course, it doesn't hurt that all of the default object styles in the contextual tab galleries will be based on these colors as well--so when you put a chart or table in, all of the styles you can choose between will match by default.)

In general, Office programs started out by supporting 16 colors. These were the standard "Windows 16-color palette" colors, and they're formed by trying out various combinations of 0, 128, and 255 as red, blue, and green amounts. For instance, RGB(0, 0, 0) is black, RGB(255, 0, 0) is bright red, and RGB(0, 255, 255) is bright teal (a mix between full blue and full green.)

As the Office programs continued to improve, certain programs were upgraded to 32 or even 64 colors in their color picker. These were still generated based on binary mathematical principles instead of on aesthetic design principles, but at least if you allowed some of the RGB values to be 64 or 32, you could get a wider range of colors. And, of course, in recent versions of Office you could always bypass the color picker and choose from any possible color--but this was a one-off selection and did not make choosing matching colors easy unless you are a graphics designer.

The new Office color gallery has two parts: the top half contains 10 fully saturated colors (meaning as bright as possible) and then a number of less saturated variants. The colors have been selected to look good together, and many of the default styles in Office use gradients between a lighter and darker variant within a color column. The bottom half of the color picker contains 10 "standard" colors that don't change based on the color scheme. Here you have a true red, a bright yellow and green that you can use, for instance, to mark up a spreadsheet with good values green and bad values red.

The Office 12 Beta 1 Color Gallery showing the default color scheme

Just as always, whenever possible you can choose to bypass the color gallery altogether and choose from any of the 16.7 million colors supported by Office.

But using the color gallery ensures that the objects in your documents match and helps you choose colors that look a lot better than the "computer colors" brought to the foreground by old-school Office. And, it makes it a lot easier to choose colors for gradients and shadows by going up and down the column of matching tints and shades.

There's a lot more to write about the Office 12 themes and color schemes story, but this gives you a small glimpse of how the products work even if you don't explicitly use these new features.

The Myth of the Orange Dot

jensenh — Tue, 10 Jan 2006 18:00:15 GMT

One thing you might have noticed in Office 12 demos and screenshots is that certain commands in the Ribbon have an orange dot as their icon. People have speculated on what the orange dot represents; guesses have ranged from highlighting features you've used recently to indicating "hot" features in the new version.

The real answer is simpler: the orange dot icon is used to represent places in which we don't have the final artwork. Long ago it was discovered that if you put in too much "temporary" artwork, sometimes people didn't notice until it was too late and it never got replaced with final art. With literally thousands of pieces of artwork being managed, it's a humongous task to make sure nothing falls through the cracks. So, the orange dot is used as the universally understood symbol within our team that an icon is missing.

When the final version of Office 12 comes out, it won't have any orange dots. (Knock on wood.)

The reason you've never seen the orange dot before (even if you've participated in past Office betas) is that this is the first release in which we've used it. In the last few releases, we used the "Magic 8 Ball" icon included in the Office command bar icon editor to have this same meaning. (I think the joke was "look in the 8 ball, who knows what icon will appear?")

Unfortunately, we spent a lot of time during the Office 2003 beta cycle responding to internal bug reports from people saying "I don't know, it doesn't seem like Magic 8 Ball is that good of an icon for Insert Table Row".

Hence, the orange dot. And now you know the rest of the story.

The 50/50 Rule

jensenh — Mon, 09 Jan 2006 18:00:00 GMT

Much is made in the business world about the 80/20 rule. Also known as the Pareto principle, the basic idea is that in many phenomena 80% of consequences stem from 20% of the causes. Wikipedia has a good discussion of the principle, its myriad applications, and its common misuse and abuse. (I should have called this post "The Principle of Factor Sparsity"; that would definitely have merited an honorary doctorate down the road...)

80/20 and its variants play an almost mythical role in all facets of mainstream software design. You'll hear that 80% of users only use 20% of the features. Or that 20% of bugs account for 80% of the problems people find in released software. Of course, none of the numbers are exact, and people are quick to point out that the principle is in effect even when the numbers aren't exactly close.

For example, it turns out that it's more like 5% of the crashing bugs account for 95% of the error reports people send. Is this still the 80/20 rule? Can I just substitute any numbers and there's still some validity to the model? If so, I'll coin the Harris Principle--that X% of consequences stem from Y% of the causes. It's bound to be applicable to an even wider array of scenarios!

Sarcasm aside, there is something valid to be learned from the 80/20 rule. In general, in mainstream software, we do try to design around how the majority of people expect it to work. In such a broadly used tool as Word or Excel, we hope we can suit more like 90% or even 98% of the people; the value of the data we gather from the Customer Experience Improvement Program is that we really can tell how we're doing.

One of the challenges of designing a piece of software for 400 million people is that even if you are extremely successful with a design--even if you totally hit it out of the park and delight 99% of your customers... well, you still have roughly the population of New Zealand who think you made the wrong decision.

The good news is that although most design decisions fall somewhere along the lines of 80/20, it doesn't have to be a zero-sum game. There's often ways to satisfy the 80% and the 20% both because they work in different ways of have different expectations of the software.

For instance, sometimes the 80% are "normal" users and the 20% are "expert" users. In order to satisfy both groups, you must determine how to enable expert-level functionality in a way that adds no complexity for people who have no need for it. It can be done, but it takes some thought.

I think a good example of this is the "Lock Toolbar" feature in recent versions of Internet Explorer and Windows. You can't drag the toolbars around unless you right-click the toolbar and uncheck "Lock the Toolbars" on the context menu.

For "normal" people, the toolbars just work the right way. They don't move unexpectedly, and they don't end up mysteriously disappearing or floating in the middle of the screen. The software feels more predictable, and because most people don't right-click on the toolbar, the complexity is hidden from them.

On the other hand, for the expert user like me who does want to move around their toolbars, finding the setting to unlock them is just a minor inconvenience. The Windows taskbar adopted the same design in Windows XP and I believe this is a good thing. (No more explaining to people how to get the taskbar back on the bottom of the screen!)

The hardest problem in user interface design is when you come face to face with the 50/50 rule. Although rare, occasionally you will discover a a situation in which the needs and wants of half of your customers are diametrically at odds with that of the other half.

Here's a simple example of a 50/50 scenario in the Outlook keyboarding model. Everyone in the world knows that CTRL+F performs Find within a program, right?

Well, actually, that's the newfangled shortcut, standardized around 1993. Before that, most programs used F4 as the standard shortcut for Find. (Just like CTRL+X, C, and V used to be Shift+Del, Ctrl+Ins, and Shift+Ins before they were changed in Windows 3.1.)

So, with F4 firmly cemented as the shortcut for Find, early 1990s-era Microsoft electronic mail products used CTRL+F for Forward. Of course, forwarding e-mail being one of the most common things you do in a mail program, in retrospect that design decision makes perfect sense.

Fast forward to today. Millions of loyal customers have learned to rely on CTRL+F in Outlook to forward mail and brace at the thought of it going away. Millions more are confused by their inability to use CTRL+F to Find in Outlook and can't understand why new mail windows keep popping up. "F4?!?!?" they gristle under their breath.

What to do? If you change CTRL+F to Find, millions of people have their productivity impacted for no positive gain at all. If you don't, millions of people are confused by your software and find it hard to use. Of course, you could make it a customizable option, but experience and data show that hardly anyone would think they could change it. There's no easy way to satisfy both groups out-of-the-box.

When the 50/50 rule bites you, it leaves a mark.

A Brief History of the Status Bar

jensenh — Wed, 04 Jan 2006 18:00:07 GMT

The status bar. A ubiquitous piece of the modern user interface, hardly anyone seems to pay it mind. That attitude often extends to interaction designers as well.

The status bar, if you are new to the world of computers, is the (usually) gray strip commonly found at the bottom of application windows. First introduced as a standard OS control as part of the Windows 95 common control library, the status bar has its roots in character mode programs, in which the bottom row of text was reserved space to show information about the program, document, or selection. Commonly, the status bar in character mode programs would tell you which keys to press to perform certain actions. For example, here's a rather advanced version of the MS-DOS Shell application complete with menus and its own status bar.

The MS-DOS Shell status bar (Click to view full picture)

Fast forward to today. Most programs have status bars, but do they need them? If you've read my post on the value of screen real-estate, you can guess what my answer is. If I were starting design on a brand new piece of software today, I certainly wouldn't start with the assumption that a status bar was required. This is a case where people seem to often confuse function for form.

The most egregious misuse of the status bar is probably the case of "an empty status bar just so my window gets a resize grippie." Most resizable windows today include a little widget in the lower right-hand corner to give people a bigger grab handle by which to resize the window. This is probably inspired by the original Macintosh which not only had a resize handle in the lower right-hand corner, but only allowed you to resize windows by using the widget. (Unlike Windows which allows people to resize windows from any border.)

A program with a status bar and integrated resize widget (the "grippie")

When a designer wants a resize grippie, in many cases the easiest way for the developer to get one is to throw a status bar into the window. Set a few bits and, voila, the resize grippie comes for free. Unfortunately, this method is easier than carving out widget space in the window and handling the right non-client messages to make the resizing work right... hence, we get programs with an entire wasted line for nothing other than a resize widget.

Things don't get much better once people start using the status bar space, however. How should the status bar be used? No one seems to agree.

In the olden days (pre-Windows 95) the most popular use of the status bar was to include a clock in the application frame. Of course, everyone implemented the clock differently, so some blinked, some showed seconds, some updated on a timer, some polled every second, some updated the time only when the window was in the foreground. I remember lining up a bunch of windows in the college computer lab and noticing how they all showed different times.

Some designers have made the decision to use the status bar as a kind of help mechanism; I have several programs running that just say "For Help, press F1" most of the time. In fact, in old versions of some Office programs, as you hovered over menu items, descriptions of them would appear in the status bar.

I have several web pages open in Firefox and the status bar is empty except for the word "Done." Internet Explorer shows the same thing but helpfully adds the word "Internet" on the right side. I have a Windows Explorer window open and the status bar reads "505 bytes" and "My Computer."

When we sat down to think about the status bar as part of the Office 12 redesign, the first question we asked was simply: "Do we need a status bar at all?" Opera comes to mind as a program which at one point had a design in which the status bar would appear when there was truly status to impart, and then disappeared to give you the space back once the page was loaded. In the most recent version, they've turned off the status bar altogether and integrated progress into other parts of the UI--something I think is a very clean design for a reading experience.

We've put a lot of thought into creating the right status bar experience for Office. Tomorrow, I'll describe the details and the thought process behind the design.