Jensen Harris: An Office User Interface Blog : Ribbon

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!

Let's MIX it up!

jensenh — Thu, 21 Feb 2008 11:30:00 GMT

Just a short note to let you know that I'll be presenting a new session during MIX in Las Vegas on Friday, March 7 at 10:00 entitled "The Story of the Ribbon."

In this session, I'm going to present the story of the Ribbon--the customer problems that we were aiming to solve by designing a new user interface for Office, the prototypes we considered (but abandoned), the mistakes we learned from along the way, and the principles we used to create the Office 2007 user interface.

It will be informal narrative, with lots of pictures and screenshots--my perspective as a member of the team who worked on the user interface from day one until the day we shipped. My goal is to keep it light and fun, but hopefully also to share many of the lessons we learned along the way.

The session is part of MIX UX, a three-day user experience track which is new to MIX08.

I'm also going to be participating in a panel discussion on Wednesday, March 5 at 3:00 called "What's the Secret Formula?" This discussion will be focused on how to overcome the challenges seemingly inherent in creating software with a great user experience. I'll be sharing the panel with participants from Mozilla, Adaptive Path, and elsewhere at Microsoft. It should be fun.

If you're at MIX, I'd love to chat, so please feel free to come by and introduce yourself. I hope to meet some of you in person either at my sessions or elsewhere at MIX!

More information about all the great MIX content is on the MIX08 web site.

Giving You Fitts

jensenh — Tue, 22 Aug 2006 17:00:00 GMT

One of the most well-understood and salient principles underlying the ergonomics of graphical user interface design is Fitts' Law.

Named for Paul Fitts, a psychologist at Ohio State University, Fitts' Law is a mathematical model of fine motor control which predicts how long it takes to move from one position to another as a function of the distance to and size of the target area. Papers outlining what became known as Fitts' Law were published in 1954 and 1964.

Fitts himself was an expert in aviation psychology, and he developed his research around more ergonomic layouts for cockpit instrumentation as a way of increasing aviation safety. You can read more about the early history and mathematics behind Fitts' Law on Wikipedia.

Fitts' model proved especially relevant to the early research on computer input devices performed in the late 1970s. Although Fitts' model was originally formulated to project how quickly a human could point at a physical button, it turns out that the same set of rules governs how quickly someone can target an area on the screen with a mouse cursor.

Although there's a great deal of subtlety to Fitts' research, what became known as Fitts' law is a fairly simple intuitive concept.

The farther away a target is, the longer it takes to acquire it with the mouse.
The smaller a target is, the longer it takes to acquire it with the mouse.

The inverse of both statements is true as well (closer and bigger targets can be more quickly acquired.)

One common mathematical formulation of this relationship is:

MT is the average time taken to acquire the target.
a and b are empirical constants determined through linear regression.
A is the distance from the starting point to the center of the target.
W is the width of the target measured along the axis of motion (how close to the target you need to get to count as acquiring it.)
c is a constant which is either 0, .5, or 1, depending on the specific environment.

Here's a cool Java-based applet which lets you play around with Fitts' Law to see how it feels in practice: http://www.tele-actor.net/fitts/

How Fitts' Law Affects User Interface

The key takeaway for interface designers is clear: the farther away a button is from the current mouse position, the larger it needs to be to achieve the same average acquisition speed. Put another way, there are two main ways to improve mouse efficiency: put the controls closer, or make them bigger. (There are other more avant-garde ways to alter the physics of mouse travel which I won't go into today.)

Over the years, as monitors have gotten bigger and screen resolutions have increased, Fitts' law dictates that actual mouse efficiency has gone down.

Think about Word 1.0, which was designed for a common maximum 640x480 screen resolution. Toolbar buttons in Word 1.0 were 20x20 buttons with 16x16 icons in them.

Word 2003, on the other hand, is commonly run at resolutions as high as 1600x1200 and beyond--yet the toolbar buttons remain the same 20x20 size they were in Word 1.0. But because the screen is so much larger, most of the time your mouse cursor will be much farther away than it could have been on a 640x480 screen. Greater mouse distances mean an increased MT target acquisition time.

In other words, the same button takes much longer to click than it did fifteen years ago.

Mile-High Menus and Magic Corners

One of the most useful aspects of applying Fitts' Law to computers is that screen size is bounded. No matter how far you move your mouse to the left, the cursor will never go farther than the left side of the screen.

In a Fitts' Law sense, you can think of the edges of the screen as being infinitely wide.

Think about how long it would take you to move your cursor from the right side of the screen to the left edge of the screen. Now compare that to how long it would take you to move your cursor from the right side of the screen to a spot 2 pixels from the left edge.

Obviously, you would be much faster in the first case because you can literally slam your mouse to the left as fast and as hard as you want and you won't overshoot. It's infinitely wide.

This is the same reason that the Mac user interface has been said to have "mile-high menus." The Mac menu bar is permanently affixed to the top of the screen regardless of what program you're in. As a result, you only have to worry about targeting a menu horizontally. Because the top edge of the screen is essentially "infinitely" tall, you can acquire the menus very quickly.

The Windows taskbar is a mile-high the other direction: you can move your mouse to the bottom of the screen quickly and only worry about targeting horizontally. (If you resize your taskbar to be two rows high, of course, all bets are off.)

Wait, it gets even better. There are four places on the screen that are effectively both infinitely wide and infinitely tall. You guessed it: the four corners.

Regardless of how distant a corner is from your current mouse position, you can get to the corner in no time at all. Acquiring the corner requires very little fine motor control at all because the virtual target is so huge. In GUI terms, the corners are so good they're often called "magic."

The Start button in Windows is seemingly located in an ideal place for fast acquisition, and in recent versions of Windows that's certainly true. Prior to Windows 2000, however, the Start button had a single "dead" pixel along the left and bottom sides of it in which clicking didn't open the Start menu. The result: slower acquisition times and a startling number of missed clicks.

Windows 95: Missed by a pixel
Windows XP: Good to the last drop

Happily, the Windows team fixed this almost eight years ago.

Office 2007 and Fitts' Law

We've tried to pay attention to Fitts' Law throughout the redesign of the Office user interface.

First off, most controls in the Ribbon are labeled. This helps discoverability and usability considerably, but it also makes the buttons bigger and easier to target. As your screen resolution increases, the width of the Ribbon also increases, providing room for more labels and larger buttons.

Larger, labeled controls can be clicked more quickly

In a sense, the Ribbon tries to keep MT from Fitts' Law relatively constant by compensating for the greater average travel distance required at higher resolutions by displaying larger controls.

The Mini Toolbar was designed with Fitts' Law in mind as well. Whenever you select text or right-click selected text, a small toolbar appears directly next to the mouse cursor (you've seen the movie, right?) As you move closer to it, it fades in; as you move away, it fades out.

Mini Toolbar: Close to the cursor

The controls on the Mini Toolbar are small, but because they're located directly next to your cursor, they're easy to target. In this case, you want to have small buttons because it means you can have as many as possible located as close as possible to the cursor.

We did look at other more radical designs (such as positioning the Mini Toolbar directly on the cursor, or a radial design) but we were also trading off with being able to see the text you've just selected and how easy it is to scan the controls on the toolbar. The design we went with provided the best overall balance of efficiency and utility.

The Ribbon is designed to increase W; the Mini Toolbar is designed to reduce A. Both of these affordances help to reduce MT, the time it takes to click a button.

Quick Access a Mile High

The operating system really has the best opportunity to take advantage of the edges and corners of the screen. When Office windows are floating around on the desktop, we're sort of confined to the window we're in.

But there's good news: according to the Customer Experience Improvement Program data, a startling number of Office windows run maximized. Even at high resolutions like 1280x1024 and 1600x1200, Office windows are maximized most of the time. And at 1024x768 and below, we're maximized almost all the time.

Why is this good news? Because when we're maximized, we suddenly get edges of the screen to play with. The right edge of the screen is used for the scroll bar, which we are careful to make sure extends all the way to the edge of the screen so that it's a "mile wide." The left edge of the screen is used differently in each program.

Historically, the top edge of the screen is used for the title bar. Having a title bar is probably necessary, but it's a huge waste of easily-targeted space, especially when your windows is maximized (meaning that you're not dragging it around to move it anyway!)

So, we wanted to take advantage of the title bar space to help make certain controls faster to target; this is why the Quick Access Toolbar is located in the title bar by default.

We designed the customizable Quick Access Toolbar to contain features people use frequently and regardless of the Ribbon tab they're on. By default, it contains Save, Undo, and Redo, but you can add any control in the Ribbon to your QAT by right-clicking it and choosing "Add to Quick Access Toolbar."

Because the Quick Access Toolbar is in the title bar, the buttons are effectively infinitely tall. You can target and click each of the buttons very quickly; they're a "mile high." Finally, you can reclaim this valuable screen edge to put features you want to access ultra-efficiently.

Quick Access that's a mile high...

(Note: In Beta 2, there's a bug which keeps these controls from extending to the top of the screen; it's fixed in the upcoming Beta 2 Technical Refresh.)

And We Didn't Leave Out the Magic Either…

I mentioned before how special the corners of the screen are because they're effectively infinitely tall and wide.

The bottom-left and bottom-right corners are taken up by the Windows taskbar, so those can't be used by Office. The upper-right corner is used for the window close button in each app, so it's kind of off-limits as well.

The upper-left corner, though, in most programs is used for a system menu which is mostly intended to be used via the keyboard: not a good use of the most premium real-estate on the screen.

In Office 2007, we decided to take advantage of that corner by using it for the Office button.

Magic Corner: Office Button in the upper-left corner

Although the button itself is round, the hit target for it actually extends on a maximized window all the way to the upper-left edge of the screen.

As a result, accessing the Office menu to Save, Open, Print, Send (or to access one of your Recent Documents) is ultra-efficient. Fitts' Law was actually one of the driving forces behind the Office Button design.

Summary

Speed of target acquisition is but one of the many characteristics of a graphical user interface, but it's an important one. In Office's redesign, we've tried to take advantage of Fitts' Law in several key ways: the control layout and scaling of the Ribbon, the Mini Toolbar and other "by the cursor" contextual UI, and the usage of the edges and corners of the screen for the Quick Access Toolbar and Office Button.

Evolution of the PowerPoint Home Tab

jensenh — Tue, 01 Aug 2006 17:00:00 GMT

A few months ago, I made an attempt to give you a sense of the kinds of changes to the user interface you'd be likely to see between Beta 2 and the final product.

In particular, I guessed that we had made over a thousand individual tweaks to the contents of the Ribbon, although now I think that was probably a bit conservative. If you consider every command label we've cleaned up, every icon we've tweaked, every punctuation fix or label size adjustment or scaling behavior modification as a change, I wouldn't be surprised if the list totals more like several thousand.

That said, most of these changes fall into the categories of polish (what we call internally "fit and finish") and simple usability improvements based on feedback or a better understanding of the relationship between or the behavior of specific features. In other words, most of the changes are minor and you'd only notice them if you looked at Beta 2 and a recent build side-by-side.

Today, I want to explain probably the biggest change we've made in Ribbon content organization since Beta 2: a rethinking of the PowerPoint Home tab.

I'm going to go through the decision in great detail to give you a sense of the kind of thought process we use for every design decision around feature organization. We've spent three years repeating this process hundreds of times in hundreds of areas, trying to come up with the best possible organization of the thousands of features which comprise Microsoft Office.

Creating the right Home for PowerPoint

One of the longest-standing challenges we've faced is getting the PowerPoint Home tab right. We didn't feel like what we shipped in any of the previous betas was really right, and there were several ideas about how to fix it.

When you look through PowerPoint's functionality with an eye towards organizing the content into Ribbon tabs, it breaks down like this:

First, there's a lot of functionality that's about animating objects and setting up slide transitions--all if it functionality that doesn't exist in any other Office program. This is an obvious logical grouping, and these features are together on the Animations tab.
There's a certain set of features that are about setting up the overall design of the document: the size, theme, fonts, colors, etc. These features comprise the Design tab, another strong logical grouping.
A big part of PowerPoint is determining how your slides come together to comprise a presentation: starting a show, saving custom shows, and determining which slides are part of your show. In addition to these features, we added the most useful features from the old Set Up Show dialog box, such as choosing on which monitor to present the show and what screen resolution to use. All of these features together make another logical tab: Slide Show.

Then, we have three tabs that are generally consistent across the main Office apps, and PowerPoint is part of this consistent story.

Insert is a tab about everything you can put into a document; we try very hard to make this tab as much the same as possible between Word, PowerPoint, and Excel.
The Review tab comprises all of the reviewing, commenting, and proofing tools in a program. PowerPoint doesn't have an overabundance of features in this area, but they are grouped together here.
The View tab contains all of the features involving changing the view, window management, and the state of application- and document-level UI and functionality. This tab is very consistent across Word, Excel, and PowerPoint as well.

Each of these six tabs work out well; the organization of them is clear, with three tabs specifically showing off PowerPoint-specific functionality, and three tabs showcasing features that are relatively consistent across the suite.

In addition to these core features, PowerPoint has a bunch of object-specific contextual tools, such as Chart features, Picture features, Movie Clip features, and the like. We have a consistent model for showcasing object-based features via Contextual Tabs, and so these features don't need to be accounted for in the core Ribbon tabs of PowerPoint.

What's Left

So, with those decisions made, what features still need a home?

A set of features which we consistently place on the Home tabs of each program: the Clipboard features and Find, Replace, and Select.
Text and paragraph formatting.
A set of features around creating, deleting, and changing the layout of slides.
"Fancy" text formatting features, such as the new WordArt gallery and text effects such as 3D, reflection, and glow.
A set of features which provide for the arrangement, positioning, grouping, and ordering of objects on the slide.
Drawing functionality, principally drawing and formatting shapes and text boxes.

Working down the list, Group 1 is probably the most straightforward. Part of making Office easy-to-use is being consistent when possible, and from this perspective, the features in Group 1 really need to be on the Home tab.

Next up are the features in Group 2: basic font and paragraph formatting. These features are heavily-used, need to be accessed efficiently, and, to boot, they're already on the Home tabs of the other programs. So the Home tab for them as well.

The features in Group 3 boil down to four top-level commands: New Slide, Change Layout, Reset Slide Layout, and Delete Slide. Three of these features are used very often by many people, and the fourth one (Reset Slide Layout) is an extremely useful feature we hope people will find and use. The logical place for these features is also the Home tab.

In the end, we all agreed that features in Groups 1, 2, and 3 needed to be on Home tab. One could make arguments for individual commands one way or another, but by-and-large, these feel like part of the motherhood and apple pie of PowerPoint.

Given the average density we aim for in a Home tab, this meant that the PowerPoint Home tab was roughly 75% full. How to best use the rest of the available space?

The Proposals

There were three main proposals:

Put all of the fancy text formatting (Group 4) on the Home tab. This is the version which makes PowerPoint appear the most like Word, because there's an in-Ribbon gallery of Text Styles right there on both Home tabs. It is also nice in that all of the text formatting features end up organized together.

The downside of this proposal: the features in Groups 5 and 6 end up kind of scattered about, and it requires a lot of tab switching to use them together with the Home tab features.

For example, a very common cycle in PowerPoint is: type some text, draw some shapes, format the shapes and the text in them, and then arrange those shapes.

In this proposal, you would type your text, then switch to the Insert tab to draw your first shape, which causes the Drawing Tools - Format tab to show up. You can then draw additional shapes from there and format them from there, but to edit the text in the shape, you need to go back to the Home tab. And then to arrange the shapes, you go to the Design tab, and then back to the Home tab to start again.

This proposal was the most consistent in terms of semantic organization, but the least efficient to use.
Another proposal was to create a top-level core Draw tab. The idea here was that a shape in PowerPoint is more like a paragraph in Word, and as such, we should not treat it contextually the way we do other objects in Office.

In this proposal, all of the text formatting would be on the Home tab, just like in Proposal 1. But the Drawing Tools - Format contextual tab would become a core Draw tab, so that you could switch to that tab and use all of the Group 5 and Group 6 features in one place: drawing multiple shapes and formatting them. You get rid of the weird thing from Proposal 1 where you draw your first shape from the Insert tab and then draw subsequent shapes from the Drawing Tools – Format contextual tab.

While this plan might sound reasonable at first blush, it doesn't really solve many of the scenarios. This proposal's biggest flaw is that there's still a separation between the highly-used core features (Bold, New Slide, Bullets) and the highly-used drawing features (Insert Text Box, Fill Shape, Send to Back.) You could perhaps duplicate 65% of the Home tab on the Draw tab to get around this, but then you have two top-level tabs that are virtual duplicates of one another.

In addition, a major inconsistency is created because the design rule "whenever an object is selected, the contextual tabs are available" is violated. Suddenly, you can't learn and use the drawing tools the same way in PowerPoint, Word, and Excel. We would be creating a one-off, inconsistent model.

In the end, when you analyze this proposal in terms of number of clicks, it becomes clear that it's actually exactly the same as Proposal 1. Doing drawing-related tasks always takes an extra click to navigate away from the other top-level features on the Home tab. Proposal 2 does have the advantage of feeling more stable (you can draw the first and second shapes from the same tab for instance), but it's not really more efficient. And creating a huge inconsistency across Office is not worth it if you're not getting back a great efficiency gain.
The idea behind Proposal 3: Make the Home tab the best possible place for people to work efficiently and live with any downstream inconsistencies.

In this proposal, the fancy text effects and the corresponding WordArt text styles gallery are taken off of the Home tab completely and instead reside with the other OfficeArt tools on the Drawing Tools - Format contextual tab.
In their place, we add the tools for drawing, formatting, and arranging shapes to the Home tab (Groups 5 and 6.) As part of this proposal, we don't do the normal auto-switch to contextual tab set that occurs when you insert shapes from the Insert tab, so that you can draw multiple shapes directly from the Home tab with no tab switching necessary.

The one downside to this proposal: Fewer people would be exposed to the fancy text formatting possible through the WordArt styles gallery, and the commonly-used text formatting and the fancy, artistic text formatting would be on different tabs. This change also means that the Home tab of PowerPoint would look less like the Home tab of Word.

The Beta 2 Design

If you haven't guessed by now, Proposal 1 is what we shipped in Beta 2. Although it didn't really seem to work very well, we did a number of tweaks over the last year to try to make Proposal 1 better.

For instance, a well-known Office newsletter noticed that we moved the Insert Shapes feature to the far left side of the Insert tab in each of the apps between Beta 1 and Beta 2. They chided us because they felt that we made the change to try to advertise features we wanted people to use.

In reality, the left side of a tab is the only place where you can be sure that in every language a control will stay in the same place. We moved the Shapes gallery there so that after you draw the first shape from the Insert tab, your mouse could move to the same location on the Drawing Tools - Format contextual tab to insert the second shape.

By locating the gallery in the same place on both tabs, you didn't have to think about what tab you were in. We then changed Excel and Word to keep the location of features consistent between the three programs' Insert tabs.

We made many changes like this to try to make Proposal 1 more workable.

A Better Direction

During the lead-up to Beta 2, we decided that no matter how many tweaks we did to the Proposal 1 design, it simply wasn't going to be good enough.

So, a few months ago we redesigned PowerPoint's core tabs to implement Proposal 3.

Here's a list of the major changes we made as part of this design:

Removed fancy text formatting from the Home tab. (It's still available with the full set of OfficeArt tools on the Drawing Tools – Format contextual tab.)
Added the Insert Shapes gallery to the Home tab.
Added Text Box to the Insert Shapes gallery so that you can also draw text boxes directly from the Home tab.
Added shape formatting (Quick Styles, Shape Fill, Shape Outline, and Shape Effects) to the Home tab.
Added a compact version of the Arrange tools (Group 5) to the Home tab.
Because they're now on the Home tab, we removed the Arrange tools from the Design tab (making that tab's purpose more clear as well.)
Because Insert Shapes is now on the Home tab, we reverted the location of the Insert Shapes button on the Insert tab in Word, Excel, PowerPoint, and Outlook to where it was in Beta 1. (Insert Shapes is duplicated on the Home tab and the Insert tab in PowerPoint so that the Insert tab remains consistent with Word/Excel.)

Here's a picture of the Beta 2 Home tab vs. the current Home tab at two different sizes:

The evolution of PowerPoint's Home tab
(Click to enlarge)

As a result of this redesign, we ended up with something that feels way more natural and efficient to work with. You have a stable Home tab from which to do most of your slide authoring: adding slides, typing and formatting text, and adding, arranging, and formatting shapes. The most-used features are all in one place. I've been using it for several months now and I'm finally confident we have the right design.

From the beginning, one of our goals for the new user interface has been for each program to be better able to express what it's all about--its "soul."

In the case of PowerPoint, that "soul" is in helping you to quickly create a compelling presentation; we redesigned the Home tab to better enable you do just that.

Nice for Mice: Menu Tabs

jensenh — Mon, 24 Jul 2006 17:00:00 GMT

Last week, I wrote about some of the work we've done to make the minimized Ribbon work well with the new keyboard model. I even posted a movie showing the new feature in action if you want to see what it looks like.

A few months ago as we were doing the work to build this feature, the developers mentioned that it appeared we had all of the architectural pieces in place to make the minimized Ribbon work better for mouse users as well.

(Keep reading, there's a movie down there!)

But first, a flashback to early 2004: A couple dozen of us are sitting in a first floor conference room conducting the very first Ribbon spec review.

In this first draft spec for the Ribbon was included a feature we called "Menu Tabs." The idea was this: you could minimize the Ribbon as today, but once it was minimized, there were two ways you could use it.

Left-click un-minimized the Ribbon like usual (exactly like it works in Beta 2.) But if you right-clicked on a tab, you got a popup version of the tab. Once you used a control on the tab or clicked away, the popup tab disappeared and you were back in the minimized state.

Well, Menu Tabs ended up getting cut from the Ribbon design in order to make room for other components of the UI to get built; the cost of developing the feature was too high. And that's where the feature lay, discarded on the cutting room floor, until just a few months ago.

All of the architectural work done over the two years between mid-2004 and mid-2006 made it possible to re-evaluate doing the original Menu Tabs design as part of filling out the minimized Ribbon scenario. So, we decided to give it a try.

The developer dug in and in less than a day she had a great prototype running. Our test team agreed to take on the extra burden, and they spent a couple of weeks filing bugs and to make sure we could get the feature to ship quality. And now, Menu Tabs is in the builds and ready to use.

In reconsidering the feature, we decided to make a few changes to the interaction design from what we originally spec'd in 2003.

Specifically, we decided that once the Ribbon is minimized, left-click activates the tab as a popup. You can double-click a tab to un-minimize the Ribbon, or right-click anywhere on the Ribbon to un-minimize from the context menu. We felt that this gave better overall symmetry to the design: double-click, right-click, or CTRL+F1 to minimize or un-minimize the Ribbon. You exit the state the same way you enter it.

I can hear you thinking "what does it look like?" I'm glad you asked. I've prepared another movie to show Menu Tabs in action in a recent internal build of Word:

Watch the Menu Tabs Movie
(Windows Media, 38 seconds, 7.3 MB)

Watch the Menu Tabs Movie (Smaller, Lower Quality)
(Windows Media, 38 seconds, 3.3 MB)

Now you know the full scope of the work we've done to make the minimized Ribbon work great for keyboard and mouse users. (And I forgot to mention last week: yes, we do remember the state of the minimized Ribbon between sessions; if you exit a program with it minimized, it will be minimized when you launch it again.)

While we do still view the minimized Ribbon as a secondary mode of interacting with the product, I'm sure some people will use it frequently. Especially if you use Office on a limited screen-size device (such as an Ultra-Mobile PC), you'll appreciate this simple minimization which maximizes your screen real-estate.

Taking the Minimized Ribbon to the Max

jensenh — Thu, 20 Jul 2006 17:00:00 GMT

One of the many areas in which we've spent time since Beta 2 has been making working with the collapsed Ribbon a more realistic option.

Since the very first public build of the new user interface, you've been able to collapse the Ribbon to just the names of the tabs by using CTRL+F1 or by double-clicking the selected tab. The design goal here was that when you wanted a maximum amount of screen real-estate in which to work with your document, you could get all of the UI out of your way at once. In fact, one of the main advantages to consolidating all of the UI into one place is that you can turn it off or on all at once.

The "collapsed" Ribbon in Excel 2007

In this "collapsed" mode, your document expands to fill virtually the entire available window. One piece which remains on the screen is your customizable Quick Access Toolbar, into which you can put any commands, buttons, or groups of controls you wish.

I often use this mode myself when I'm reading or performing simple formatting on a document; I use the Mini Toolbar and context menus to perform my basic tasks and then bring up the Ribbon when I want to do some more in-depth work.

Anyway, we got a lot of feedback in Beta 2 that the collapsed Ribbon was a great idea in principle, but that it didn't work very well in the real world. So, we dug in and did a number of features designed to make working with the Ribbon collapsed a better experience.

The first thing we did was simply to make collapsing the Ribbon more discoverable. What we used to call unofficially "collapsing" the Ribbon has now officially become "minimizing" the Ribbon. In current builds, you can right-click anywhere in the Ribbon to bring up a context menu which includes an option to "Minimize the Ribbon." This is in addition to CTRL+F1 and double-clicking the selected tab, which are still available.

A context menu item for Minimizing the Ribbon

Another big improvement: Many people have tried to keep the Ribbon minimized but use the keyboard primarily to access functionality.

Unfortunately, in Beta 2 every time you type a KeyTip to use a command in the Ribbon using the keyboard, the Ribbon expands and you have to manually close it every time. This was quite inefficient and basically made it infeasible to work with the Ribbon minimized for any length of time.

We've now done the work so that if you minimize the Ribbon, when you press ALT+H to bring up the Home tab, it comes up over top of your document like a little floating window. Then, when you've pressed the key for the feature you want to use, the Ribbon goes away, reverting back to its minimized state.

I made a little movie to show what this looks like and how it works. I put Excel in some extremely small resolution in order to keep the movie small (I think something like 690x440 or so), but you get the idea of how you might use the Ribbon minimized with the keyboard.

Watch the Minimized Ribbon Movie
(Windows Media, 21 seconds, 716 KB)

To un-minimize the Ribbon, you just right-click again and uncheck "Minimize the Ribbon" or press CTRL+F1 or double-click a tab.

Now, read Part 2, where you can see how this same feature works with the mouse. (C'mon, you know you want to watch another movie!)

Let's Talk About Customization

jensenh — Tue, 27 Jun 2006 17:00:00 GMT

One topic that has come up frequently in our private beta newsgroups as well as here in blog comments from time to time is the issue of customization.

As with every component of the Office 2007 user interface redesign, we put a lot of thought into how much customization to provide; today I'm going to try to walk you through our thought process.

Many of you have been passionate in conveying feedback that you wish the UI had absolute customizability. As in my article on the size of the Ribbon, I'm going to lay the facts out on the table and hopefully it will help you to at least understand the rationale behind the decisions we made (even if you wish we had made different ones.)

What is Customization?

There are many aspects to customization in a software user interface. The ability to change the visual appearance, to change preferences, and to turn pieces of the UI on or off are all aspects of customization.

Most frequently among power users, the term "customization" is used to represent the ability certain programs have to add, remove, and relocate commands within the UI.

The History of Customization in Office

Command Bars, introduced in Office 97, were kind of a nirvana of customization capabilities. With Command Bars, you could change virtually anything imaginable within the organization of the menus and toolbars: create new ones, move buttons from toolbars to menus and back, use a built-in icon editor to directly edit the pixels of the icons, etc.

Unfortunately, this flexibility came at a price in terms of the complexity of Command Bars and the kinds of layouts and controls it could support. One of the reasons that many of the prior attempts to simplify the UI were unsuccessful was that any feature had to work within this ultra-customizable framework where you could never predict where a control might live or how it might be presented to the user.

There were downsides for normal users as well. When we go on site visits to watch people use Office 97-2003 in their place of business, we often find that Office has been ravaged by the effects of accidental customization.

In fact, one of the most frequent questions we are asked by people during on-site usability research is: "How can I get the menus back to the top of the window?"

Because of the ultimate flexibility of Command Bars, you can make one small misplaced click and suddenly the menu bar is docked to the left side of the screen or floating in space. Of course, this could have been improved somewhat by some sensible measures such as locking the UI by default, but it does illustrate the different ways a power user and a more typical user think about the same feature.

How Many People Customize?

When we started designing the Office 2007 user interface, one of the first and frequent discussions we had was: "what is the right kind of customization to include in the UI?"

We started collecting research by talking to some of our expert users within large companies, who in several cases assured us that "everyone" customizes their UI to optimize it for the most efficient use possible and, furthermore, that any new UI needed to be at least as customizable as Command Bars (preferably even more.)

An interesting perspective, but it can be dangerous to base decisions on just a few opinions (especially when the first word in the opinion is "everyone.")

The next step was to see what was actually happening in the real world: were people customizing as much we assumed?

Given that we already had one of the most customizable user interfaces of all-time in Office 2003, looking through the real-world data could help us to confirm objectively how many people were customizing their UI and exactly how they were customizing it.

Looking across a hundred million or so people using Office 2003, here's what we found:

In fewer than 2% of sessions, the program was running with customized command bars.
Of the 2% of sessions with customizations present, 85% included customization of four or fewer commands.

Needless to say, we were surprised, but when we looked at the statistics in detail, this data matched that which had been collected from other sources and in historical research.

It breaks down like this: in ~1.9% of sessions, buttons have been added, removed, or moved between toolbars and menus. (Changing the docking position or location of an entire toolbar is not counted as a customization. Buttons added by add-ins or templates are also not counted.)

Of the customized sessions, around 85% of them had only what we'd call minor customizations: four or fewer buttons. Most of these are added toolbar buttons, either from the command well or from a toolbar people don't want to keep up all the time. And even within these 85% of 2% of sessions, there are patterns that emerge.

The most popular single customization? Removing the "Read" button from the Standard toolbar in Word.

The PowerPoint team helped by collecting hundreds of screenshots of heavily-customized versions of PowerPoint from professional slide designers. It turns out that many of the same customizations are widespread among these users, such as adding Send to Back as a top-level command so that it's not buried four-levels deep in the Drawing toolbar.

Finding so many patterns in the customizations was a heartening revelation, because it implied that if we got enough of the details of the command organization right based on these common customizations, many fewer customizations might be necessary.

Furthermore, because Office 2003 is still relatively new, it is deployed disproportionately among power users--the very people who most likely to customize. In all of our analyses, we try to be aware that the raw statistical data skews slightly towards early-adopting power users. This is probably much less true today than it was more than two years ago when we first compiled customization statistics.

(One metric that causes us to believe that the Office 2003 data slightly skews towards power users even today: Every month, the average screen resolution of people using Office 2003 decreases as more of the core installed base adopts it.)

Using the Data to Drive the Design

Even though Microsoft is a big company, we don't have unlimited design or development resources. Given how ambitious our plans were for reinventing the Office user interface, we had to be realistic and optimize for the most common scenarios first.

So, we took a pragmatic approach and decided to focus on the 99.7% case: people who don't take advantage of customization or only use it to customize four or fewer commands. Out of this goal was born the Quick Access Toolbar.

The Quick Access Toolbar is designed to make it easy to add controls, galleries, and groups from anywhere in the Ribbon: just right-click the thing you want to add and choose "Add to Quick Access Toolbar" from the context menu. We designed the customization model to be efficient but with the goal of "zero customization complexity"; it would be unacceptable for customization to cause the user interface to degrade as it did so often with Command Bars.

Adding controls to a persistent toolbar allows people to have one-click access to the features they choose from anywhere in the product, and can help eliminate problematic command loops as well.

We also paid close attention to common customizations in Office 2003, making sure that commands are organized together for maximum efficiency. This helps to further reduce the need for customization.

Command Location Customization in Office 2007

What command location customizations are supported in Office 2007?

Here's a list of the major capabilities:

Add any control in the Ribbon to the Quick Access Toolbar
Add an entire Ribbon group to the Quick Access Toolbar as a single icon
Add a gallery to the Quick Access Toolbar
Add individual menu items to the Quick Access Toolbar
Add any command from the command well to the Quick Access Toolbar
Add macros to the Quick Access Toolbar and choose an icon and label for them
Add separators to help organize the Quick Access Toolbar
Reorder controls within the Quick Access Toolbar
Full-width Quick Access Toolbar mode below the Ribbon
Auto-assigned keyboard shortcuts given to customized Quick Access Toolbar commands
Customize the content of many galleries (especially in Word)
Customization based on use of many galleries (Recent Documents, Margins, Shapes, Themes, etc.)
Complete customization of status bar
Customize the Ribbon via XML in document template
Use RibbonX XML to customize Ribbon content through a COM Add-in

As you can see, there's quite a lot of customization available in the Office 2007 UI. The laser focus on the Quick Access Toolbar is evident as a result of mapping the design of the product to real-world use.

That said, the last two items on the list will be of interest for expert users who are craving more control over customizing Ribbon content. RibbonX, which has been written about in this space many times, provides an XML interface for describing Ribbon content, including repurposing built-in controls and groups.

You can build custom tabs and groups in RibbonX already; it's just a matter of loading the XML into the program you're using. There are a few ways to do this, including saving the XML into your default document template.

Undoubtedly, people will write tools to help take the XML coding out of using RibbonX to customize Ribbon content. Patrick Schmid has illustrated many of the techniques necessary to make this work on his blog. We've added some additional capabilities to the object model post-Beta 2 that will help these tools along, such as the ability to query for the icon of a command or to execute it directly from code.

Beta Feedback

Nevertheless, throughout the beta cycle we've received requests for additional customization capabilities. There have been discussions about the desire for it in private beta newsgroups, and people have posted comments on the topic here as well. One reader in particular has graced me with at least five personal flame-mails, complete with speculation about my ancestry and theories about the difficulty I will have finding future employment once I've been fired.

If we really optimized for the 99.7% case (98% + (85% of 2%)), why are we hearing so much about this issue?

Because 0.3% of the 450 million paid Office customers still represents 1.35 million people.

And given the strong correlation between expert users and customization, one would expect that these 0.3% are precisely those who download early betas, participate in private beta programs, visit enthusiast web sites, read technical blogs, and generally are interested in and participate in the software development process.

On the other hand, in our long-term broad deployments of Office 2007 Beta 1, Beta 1 Technical Refresh, and now Beta 2 at customer sites, customization has not been a particularly hot issue--nor has it been in Send a Smile feedback.

I have definitely heard those of you who spend the time and effort necessary to build totally custom menus and toolbars in Office 2003, and I hope that a combination of the Quick Access Toolbar and RibbonX-based customization will provide you with a similar level of flexibility in Office 2007, albeit using different technologies.

Addressing Feedback

In a way, all of this attention around customization is a bit like a TV show getting canceled.

Even the least successful network shows attract a lot of viewers in absolute terms--just not relative to the opportunity cost of keeping them on the air. Financially, it doesn't make sense for a network like NBC to keep around an underwatched sitcom like "Joey," but if you're one of the people who like "Joey" it doesn't sting any less when it's canceled. The fact that you're in a small minority doesn't console you.

In other words, the decisions we made around customization in Office 2007 weren't based on absolutes ("no one should be allowed to customize the Ribbon") but instead based on pragmatic use of resources ("let's start by getting the core aspects of the design right for everyone's benefit.")

Is additional customization against the design philosophy of the Ribbon? No, provided that we could add it in such a way that it added no additional complexity for the vast majority of people who aren't interested in it.

Within our resource and schedule constraints, we've acted on the expert user feedback by continuing to add additional customization throughout the beta cycle.

In Beta 1, we added the ability to move the Quick Access Toolbar below the Ribbon to allow many more controls to be added to it. In Beta 1 Technical Refresh, we introduced the ability to add whole groups to the QAT, the ability to add galleries to the QAT, separators, and new command well functionality. In Beta 2, we added the ability to assign custom keyboard shortcuts by adding controls to the QAT.

Are there other customization features we'd like to add eventually? Of course. One example is the ability to customize the contents of the Mini Toolbar--this was an affordance we included in the original spec, but ultimately didn't get done for Office 2007. In future versions, could I imagine adding built-in facilities for customizing Ribbon content? Yes, I could imagine it.

At the same time, I honestly believe that Office 2007 as it stands will be a great user experience for people of all skill levels. If you're a power user (as I am), there's a lot we designed just for you, and even more coming post-Beta 2.

The fundamental principles and constructs of the new UI--galleries, Ribbon layout and command organization, Live Preview, Contextual Tabs, the Mini Toolbar, and all the rest--have been designed to benefit everyone who uses Office, power users and novices alike.

Other Aspects of Customization

A different kind of customization people ask about occasionally is the ability to relocate certain parts of the user interface. The two biggest feature requests in this area are for a vertical version of the Ribbon (to take advantage of widescreen monitors especially in Word) and the ability to "float" and drag around certain parts of the UI.

Some day in the not-too-distant future, I plan to write a post about why we built a horizontal version of the Ribbon instead of a vertical one. There are several compelling reasons, but needless to say we looked at prototypes of both aspect ratios in great detail before making a decision.

Could I imagine a hypothetical version of the Ribbon designed to dock to the side of the screen instead of the top? Of course. Will we build it in a future version? Nothing's for sure, but if it's the right thing for the UI platform moving forward, we'll definitely consider it.

The story with floating UI is similar. Floating toolbars in Office 97-2003 caused a lot of problems, primarily because they were forced on people as the primary means of accessing many features. As a result, toolbars were always popping up over top of what people were working on, needing to be dragged out of the way, or mistakenly docking to the side of the screen.

Our design mantra for Office 2007 was that default feature access wouldn't rely on floating things popping up on top of the document; the UI would be in a single, consolidated, consistent place.

But there are a few repetitive action scenarios in which it would be useful to be able to float UI just to make it closer to the area of the document you're working in. While the data shows that the vast majority of people don't take advantage of this functionality in current versions of Office, we've definitely prototyped a more expert mode in which you could "tear off" groups from the Ribbon or the Quick Access Toolbar, or even a whole tab of the Ribbon to move to a secondary monitor.

Again, were we to build such a feature in a future version, it would be in a way that had no possibility of accidental misuse, and in a way that added minimal complexity to mainline cases.

Last but not least, there's always a lively discussion to be had around choosing a visual appearance for any piece of software.

Unlike in past versions of Office, we allow you to choose your color scheme directly in Office 2007. You can change between the three schemes from the first page of the Options dialog box. People always want more color choices, but I hope with the addition of the third scheme in the final product that most everyone will be able to find a look for the product they're happy with.

Summary

As with everything in the Office 2007 user interface redesign, we informed the design both by analyzing the usage data and then by adding a sprinkling of anecdotal feedback. We focused first on the most common scenarios which benefit the broadest set of customers. Then we've used the feedback from the beta process to drive iterative improvements to the design to help satisfy more of the specialized uses of the product.

In the next version of Office, we will undoubtedly look at all of the feedback we get on the completed product (which, as more people use it, will be more fully representative of the entire user base) and decide how to continue to move the UI platform forward.

One goal won't change however: to empower people to do great work in Office as easily as possible.

Drawn Together

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

Creating a drawing in Office is different is a few key ways from other features we expose on the Insert tab of the Ribbon.

Most notably, individual shapes are usually part of an overall drawing. It's less common that someone intends to draw a solitary circle than that the circle joins together with other shapes and lines to communicate an idea as a complete drawing. Unlike a table or a picture, which is usually by itself a complete expression, shapes and lines tend to work together.

This creates some interesting usability and efficiency issues for the drawing UI. The first realization we had very early on in the design process was that drawing is a cyclical task. Unlike the simple Insert -> Format workflow of a table, the workflow for drawing often looks more like Insert -> Format -> Insert -> Insert -> Insert -> Format -> Insert -> Insert -> etc.

Sorry for another gratuitous diagram today--
I can't get seem enough of using these new Office 2007 diagram tools!

So we knew that we needed to support this process of inserting and formatting a lot of things together well. Although Contextual Tabs are a crucial part of the new user interface, they were originally conceived for use with tables and pictures, in which you tend to insert the object once and then spend the rest of the time adjusting the content, layout, and formatting.

With the drawing model, however, contextual tabs got in the way, because every switch between Insert and Format required a tab switch between the Insert tab and the Drawing contextual tabs. Although I like to point out at this juncture of the discussion that even with an added click for tab switching , the total of number of clicks required for this scenario is still far fewer due to the Ribbon, it felt inefficient for people. One thing that I've learned during this design process is that if something feels inefficient, it is just as bad as if it is inefficient (no matter how much objective proof you can offer to the contrary.)

In order to break this cyclical tab switch, just before Beta 1 we added the same Insert Shapes gallery that's in the Insert tab to the Drawing Tools contextual tabs. Now, you could insert shapes from either the Insert experience or the contextual experience, and you could perform the cycle of inserting and formatting without needing to tab switch at all.

This was also when we designed and built "lingering" into the product to help address scenarios in which you were jumping between objects in a drawing to format them in succession.

This was the state of things circa Beta 1 Technical Refresh. But the feedback kept rolling in.

In general, people liked that they could do the drawing from both tabs, but a new problem came up. Because the shapes gallery was in a different location between the two tabs, you could never dependably and rapidly move your mouse into the same area again and again to draw out many shapes. You had to insert the first shape from one place in the Ribbon and draw subsequent ones from another place.

Well, it turns out that because of the way the Ribbon scales up and down, there's only one place you can put content so that it remains constant between tabs--in the leftmost position. So, we redesigned the Insert tabs in each of the apps so that the Shapes gallery appears to the far left side. This ensures that the drawing tools remain in the same exact place in the screen regardless of which of the two tabs you're using.

The Insert Shapes gallery remains in a consistent position across tabs

Another piece of feedback we received is the importance of being able to efficiently choose exact font sizes for text contained in drawings. Prior to Beta 2, the Mini Toolbar did not include the font size picker (just a simple size up/size down set of controls). So, in order to make sure that the key text formatting controls are at hand when editing text in drawings, we added exact size to the Mini Toolbar for Beta 2.

The Mini Toolbar in Beta 2 has exact font size control

As with everything in the Office 2007 UI, we continue to refine the designs based on feedback. So many areas of the product have been iterated on as many as a dozen times as we learn more about the way people interact with the new UI and expect it to work. Beta 1 was our version 1.0 product: promising but rough.

By continuing to evolve the designs based on feedback, we hope that Beta 2 will exhibit greater levels of refinement and efficiency.

The Size Of Things

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

One of the most discussed aspects of the new Office 2007 UI has been: "Does it take up too much room?"

It isn't a straightforward question to answer, above all because to answer it requires a subjective opinion. What seems just right to one person might seem to another person to be too much.

So today, I'm going to try to take an objective look at the size of the new UI just by presenting the facts--and then you can form your own opinion. I'll also discuss some of the background about why we made the design decisions we did.

One of the tricky things about measuring the size of the Office user interface is figuring out what to measure. The size of the Office 97-2003 user interface, in particular, is greatly affected by the number of toolbars and Task Panes brought up to use the features in the product.

To sidestep that problem for the time being, I'm going to compare the out-of-box experiences of Office 97 and Office 2007. Why these two versions? First of all, Office 97 was the first version of Office with command bars, and it's the version often cited as representing a cleaner, smaller brand of UI. It's also before the introduction of Task Panes, so we don't have to take that into account. Also, it was (and is) an extremely successful version of Office which many people have installed, so it seems like a good comparison.

Why measure the out-of-the-box experience? Given that fewer than 2% of Office 2003 users customize their UI according to the data reported through the Customer Experience Improvement Program, the out-of-the-box experience is the one most users will see.

Furthermore, the out-of-box-experience is the mainstream experience which paints the old UI in the most positive light, primarily because it includes only the default toolbars--not all of the other ones which regularly appear as part of using the product.

Nonetheless, this comparison at least gives us some basic numbers to work with. All screenshots were taken in Windows XP at 1024x768 screen resolution with the Office window maximized.

Word 97 vs. Word 2007: Out of the box

Here are comparison pictures of Word 97 and Word 2007. The same document is loaded in both, and you can see that the text in each line as well as the line spacing match up exactly.

Word 97 - Click to enlarge

Word 2007 - Click to enlarge

Word 2007 document area: 1007 x 573 pixels
Word 97 document area: 979 x 573 pixels

Horizontally, you gain 28 pixels of space in Word 2007 out-of-the-box. On a web layout or landscape-oriented document, this advantage would be most useful.

Results: Arial 10 pt., Page Layout View

Word 97: 26 lines of text
Word 2007: 26 lines of text

So there it is. You can fit the same number of lines on the screen, out-of-box, in Word 97 and Word 2007.

We achieved this relative parity in terms of the size of the document workspace by cleaning up some other parts of the UI. We changed the horizontal scroll bar to only appear when necessary, and moved the view switcher buttons into the status bar. We also designed the rulers (which data indicate most people never use) to AutoHide, and added a quick toggle button to turn it on or off at the top of the vertical scroll bar.

Another way to visualize the comparison is by laying the document areas side by side. Because the Ribbon consolidates the UI into one space, it pushes the document down in the window a bit--giving the illusion of there being less space than there really is.

Here are the document areas of the 1024x768 maximized windows laid side by side. Notice that the lines of text line up exactly vertically, although the words don't line up due to the more precise positioning of letters in Word 2007's ClearType.

Comparison of document space - Click to enlarge

Excel 97 vs. Excel 2007: Out of the box

The Excel numbers paint a similar story to the one we just saw in Word.

Excel 97 - Click to enlarge

Excel 2007 - Click to enlarge

Excel 97 document area: 1004 x 581 pixels
Excel 2007 document area: 1008 x 534 pixels

Horizontally, there's more space in the new version by default, vertically there's a little less. As with all of these comparisons, this assumes that the Office 97 user isn't showing any toolbars except for Standard and Formatting.

In terms of rows and columns, the amount of data on the screen ends up being similar.

Results: Arial 10pt., Normal View

Excel 97: 31 rows, 15 columns
Excel 2007: 30 rows, 15 columns

The default cells in Excel 2007 are a single pixel less tall--not really perceptible when looking with the naked eye, but it's enough to bring the amount of data on the screen to within one row.

What this shows me is that, more than the UI or anything else, if you're interested in getting more data on the screen in Excel, optimizing the font choice and cell size is by far your most important lever. Even minuscule changes have a large effect over many rows or columns.

PowerPoint 97 vs. PowerPoint 2007: Out of the box

PowerPoint's usable canvas can be measured best based on the size of the slide that fits in the window. Because of its unique slide scaling behavior, PowerPoint is the most directly impacted equally by both horizontal and vertical dimensions.

PowerPoint 97 - Click to enlarge

PowerPoint 2007 - Click to enlarge

PowerPoint 97 document area: 1008 x 575 pixels
PowerPoint 2007 document area: 1024 x 573 pixels

A similar story to Word and Excel: more horizontal space, a tad less vertical room. The impact on the size of the slide itself is minimal. In fact, the default AutoFit zoom level within the available space is exactly the same between the versions.

Results: Normal View

PowerPoint 97: 76% zoom
PowerPoint 2007: 76% zoom

PowerPoint was the only program to ship with three toolbars turned on in Office 97, so it is not surprising that the size comparison is a dead heat.

As with Word, because the slide is positioned further down in the window in PowerPoint 2007, it gives the illusion of a smaller workspace than actually exists.

The Design Process

That ends the simple, factual, out-of-the-box comparisons. The numbers are on the table.

For the vast majority of people who use the product without spending tons of time tweaking every setting, the new UI will give them about the same amount of workspace as they would have had in Office 97 on the same computer.

Of course, today, we're designing for much larger screens than would have been common back in 1996. The most common screen resolutions for Office 97 were 640x480 and 800x600. The most common screen resolutions for Office 2007 will be 1024x768 and 1280x1024 (with a fairly sizable percentage running even higher resolutions).

As a percentage of average available screen size, the Office 2007 UI takes far less space than the Office 97 UI would have on a 640x480 monitor. As you've seen, even when you equalize the screen size, the work areas are similar. The result is that far more of your bigger screen is used to show your document, as it should be.

But also keep in mind--we think about the Ribbon as a kind of flat tax. Unlike the toolbars model, where new UI was constantly coming up and taking extra space on the screen, the Ribbon never gets any larger.

What if you need the Reviewing and Drawing tools in Word 97? Suddenly, you can only see 23 lines of text instead of 26 lines of text. What if you ever inserted a Picture? Now you've got the Picture toolbar covering up your document--or dock it and lose another 2 lines of text. Or maybe you need the Table toolbar? There goes another 2 lines of text.

This build-up of "extra" stuff is one of the most common complaints about the menus and toolbars-based UI. Once a toolbar comes open, people don't want to close it because they fear losing it. Experts, of course, know how to manage all of the UI widgets on the screen, but more often than not when we do site visits to watch people use Office in their place of business, their screen looks like this:

Stuff everywhere taking up room in Office 2003 - Click to enlarge

I wrote about how the Ribbon doesn't degrade over time in March, but this same aspect of the UI has a profound impact on size. As more and more clutter is added to the mix, the Ribbon's advantage in screen real-estate usage becomes pronounced.

With the addition of even one additional toolbar in any of the programs, the Ribbon already comes out ahead (even measuring at the exact same resolution!)

But What About... Task Panes?

As you may remember, Office XP and Office 2003 boot up with the Task Pane turned on. Because most of the command Task Pane usage scenarios have been absorbed into the new UI, we no longer boot with it on in the new UI programs of Office 2007.

Getting Started Task Pane in Office 2003 - Click to enlarge

If we pedantically wanted to look at true "out-of-the-box" for Office 2003 vs. Office 2007, we'd have to consider the space taken up by the Task Pane.

In default Office 2003, for instance, the Task Pane is 200 pixels wide, greatly decreasing the amount of space you get in each program. You only need to watch the candidates on The Apprentice use Office 2003 with the unused Getting Started Task Pane open all of the time to realize that most people don't spend the time to get these pixels back. (We see this frequently in site visits as well.)

Any sort of UI space comparison between Office 2007 and Office 2002/2003 with the Task Pane on comes out with the new UI far in front. I went through some of those numbers last September.

But What About... Rafted Toolbars?

Starting in Office 2000, the ability to "raft" toolbars on to a single line was introduced. The out-of-box retail experience included this feature turned on in some cases.

Turning this option on saves you 25 vertical pixels because the Standard and Formatting toolbars share a single line. On the other hand, this design proved to be confusing because the presence and position of toolbar buttons is constantly changing, trying to optimize themselves based on your use.

The vast majority of business customers, therefore, turn this feature off as part of deploying the product. Many computer manufacturers also turn it off because of the support calls it generates. So, while this design might have made for a great screenshot, not many people use this product in this mode and therefore I'm not going to spend a lot more time discussing it as a common scenario.

Suffice it to say, "rafting" is one way a person could have taken back 25 vertical pixels in the old UI.

If you're struggling with this feature in Office 2000/XP/2003, you can turn it off easily. Click Customize on the Tools menu, and then on the Options tab, check the box next to Show Standard and Formatting toolbars on two rows.

But What About... Customization?

Once you get beyond out-of-box experience, you're in the realm of the few who spend time customizing their Office workspace to optimize the use of space.

As I've mentioned before, the data indicates that fewer than 1 in 50 people have customized their Office UI, which is one of the reasons I've spent up until now discussing the mainstream out-of-box experience.

But it is true that both Office 97-2003 and Office 2007 provide affordances for those who wish to spend time customizing in order to get more space for their document.

Getting Space Back in Office 97-2003

If you have a big enough monitor, you might be able to move certain toolbars onto a single line, depending on their size.
You could turn off all of the built-in toolbars and create a custom toolbar with the set of buttons you want.
You could turn off the toolbars and use menu accelerators and keyboard shortcuts to perform all tasks. Because not all features are in the menu system, you would have to move buttons from toolbars or the command well into the menu system in order to use them via the keyboard.

Getting Space Back in Office 2007

You can collapse the Ribbon, either by double-clicking the selected tab or by pressing CTRL+F1 on the keyboard. The entire bottom part disappears, leaving only a single row of tabs across the top.

Collapsing the Ribbon in Office 2007 - Click to enlarge

You can use the keyboard system to use all features in the Ribbon while it's collapsed. Because all features have efficient keyboard access, you don't need to mess around in the command well, adding features to menus to get keyboard access to work. (Note: in Beta 2, the Ribbon expands when using KeyTips... we're hoping to have this solved for RTM.)
You can add controls from the Ribbon to your customizable Quick Access Toolbar. You can even add groups of features as a single icon to save space. Of course, you could collapse the Ribbon and use only your custom Quick Access Toolbar, giving you tons of space back. Note that because the Quick Access Toolbar receives automatic KeyTips, you also have hyper-efficient keyboard access to these features or groups of controls.
You could use RibbonX, the XML-based extensibility model for the new UI, to replace the entire Ribbon (or a tab of the Ribbon) with a custom user interface designed by you.
One last note about Office 2007: Because additional UI elements never come up without you requesting them (toolbars, Task Panes, etc.), you can rely on the space considerations remaining static over time.

Summary

Whew, this has been a long post--but it's an important topic so I wanted to make sure to give it the space it deserved.

In short, the majority of people who use Office 2007 will have about as much space for their document content as they would have running Office 97 on the same computer. Someone who used several toolbars or the Task Pane will likely get more space for their document content in Office 2007.

Given today's average screen resolution, the Office 2007 UI will take up a historically small percentage of the average window size.

And, if you are one of the few willing to customize to make more space, there are many options available, both in the old UI and the new UI.

Is the Ribbon larger than a toolbar? Of course. Is it bigger than all of the UI it replaces? In most cases, no.

We really have attempted to preserve as much space as possible for the document canvas while ensuring that the Ribbon has enough room to host all of the UI of the product in one location--a key usability goal.

In common, long-term usage of the product, I believe that most people will end up with more usable document space in Office 2007 applications than in any previous version of Office.

There's No Place Like Home

jensenh — Wed, 22 Mar 2006 15:30:00 GMT

A long-open issue in the designs of the Ribbon content for the Office 2007 programs has been what to name the first tab of the programs.

In Beta 1, Word's first tab is called "Write," Excel's first tab is called "Sheet," and PowerPoint's first tab is called "Slides."

Where did these names come from? Well, we made them up. We thought it was important that the names of the tabs helped describe what that tab was used for--but the first tab proved the most challenging.

"Write" seemed to most people to be the most successful name. It's a verb, so it matches well with other task-based tab names, like "Review" and "Insert." And, it's a relatively short name in English with good, short translations in most languages.

"Sheet" started out being called "Enter Data" in Excel, as we tried to come up with a term which matched "Write" in spirit. But it was a long and clunky name, conflicted with the "Data" tab of Excel, and worst of all (in my opinion), it makes working with Excel sound like drudgery.

PowerPoint started out with a "Create Slides" tab (again, to make the first tab a verb like "Write"), but that proved to be a usability disaster. The name was so specific that some people thought the only thing they could do was to create slides, and they would look elsewhere for formatting and layout features.

So, we were not at all happy with the names. The first tabs were very similar in concept, but far apart in naming. Should they be verbs or nouns? Concrete or abstract? We knew that we needed to make a change for Beta 2.

We started the discussion by looking at usability data, which indicates that it doesn't matter what the name of the first tab is as long as it's generic enough (not to repeat the "Create Slides" fiasco.) This is borne out in our command organization research, in which users feel by far the least relationship between the tab name of the first tab and the content of it. "Review" helps people make a decision about whether to look somewhere for a command, but "Sheet" doesn't help to inform their decision.

And as much as we originally thought the first tabs needed to have unique names, in reality the concept behind the first tab of each app is totally consistent: presenting high-usage features people need efficient access to most frequently. If we were trying to be really pedantic about literal tab names, we'd have to call the first tab something like "Highly Used Commands."

So, in a sense, a per-app name (Slides, Sheet, etc.) was just window dressing the real issue--that the first tab is the place to get to the most fundamental features.

Anecdotally in conversation with Office 2007 users, this seems to be true just based on the fact that the vast majority of references to the first tab are "the main tab," "the home tab," "the first tab," etc. In fact, the research has shown the current first tab names are much less sticky than "Review" or "Insert" or "Animations," which are descriptive and accurate.

People are already forming the concept of the first tab as a special place--it's where you start, it's where you spend most of your time, it's where you keep coming back to, and, in fact, it already has a set of special behaviors based on it (like we put you back there when a contextual tab goes away.)

So, when time came to revisit naming for the first tabs, we considered the following inputs:

Research indicated that it didn't matter what we called the first tab as long as it was generic enough
The current names weren't adding any value at all in terms of usability
The tabs are actually highly consistent in their design: fundamental, high-usage commands
People already vocalize and think about the tabs as primary, main, home, first...

Based on that, it seemed like it made sense to rename the tab to match the user's own conception of how the UI system works and have a consistent name that indicates the specialness of the high-usage features tab of each program (it's where you start, it's where you spend most of your time, it's where you keep coming back to, it's where we put you back to.)

Once we agreed on this, it was just a matter of choosing from a set of potential names: Home, Main, First, Primary, etc. A couple of people suggested "Edit"--but we found out in Excel that's a bad choice because it's a loaded term and it biases people's expectation of what would be on it negatively.

We also looked at calling this tab the name of the program, but that took away the consistency we had come to think was a good thing. We really needed a short, friendly, name which communicated what the tab was all about.

In the end, we made the decision to go with the name "Home." We think that it's the best overall choice: it describes the common usage of the tab and it matches people's conception of what the tab is all about. Undoubtably, some people will wish we were naming it something else (or will miss the old names), but I feel confident that this is the right decision.

The change was introduced into the build directly after the Beta 1 Technical Refresh, and it will be in Beta 2.

Lingering Around

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

One of the key concepts in the Office 2007 user interface is Contextual Tabs. Whenever an object is selected, the tools for working with that object are made available in the Ribbon. I've talked about them in an introductory article and just last week I posted a design history of the steps we took along the way.

Table Contextual Tabs in Office 2007 - Click to enlarge picture

Diagram Contextual Tabs in Office 2007 - Click to enlarge picture

A number of people have asked the question "When do Contextual Tabs appear?" Today, I thought I'd share the (fairly simple) algorithm underlying the design.

The first, incontrovertible rule is this: whenever an object is selected, the Contextual Tabs for that item are available. You can, of course, continue to use the core tabs, but the object-specific tools are also available. This rule applies 100% of the time, for all objects in Office. Pretty straightforward so far, eh?

Most of the time, what people are really asking is: "in which scenarios do the Contextual Tabs automatically bring themselves forward?" The answer to that is a tad more complex, but still basically straightforward.

Whenever you insert an object, you are brought to the first tab of the Contextual Tab set for that object.
Whenever you double-click an object, you are brought to the first tab of the Contextual Tab set for that object.

So far, so good. There's only one additional rule:

If you deselect a selected object and then click right back on it without performing any other commands in-between, we put you back in the Contextual Tabs where you were before you deselected the object.

This third item was a feature called "lingering" that we added based on very early real-world research. What we found was that an extremely common scenario involved people using an object, clicking away from it to make the selection handles go away (to get a better look at it) and then clicking right back on the object to continue formatting it.

Before we made this change, someone would be using the Layout tab of the Chart Tools. They would click away for a second, then click back on the object and when they would go to use the Ribbon, they were suddenly back on the Sheet tab. Confusion reigned. Since implementing "lingering," the usability results on Contextual Tabs have become very solid.

So now you know the three rules which determine when we navigate to a Contextual Tab.

Adding Groups to the Quick Access Toolbar

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

A great deal of the time spent in an Office development schedule after Beta 1 is put towards addressing feedback collected through the use of the product, both in our private beta program and through other research.

One of the key areas in which we continue to make improvements is the Quick Access Toolbar.

You may remember that the Quick Access Toolbar is the customizable place in the UI in which you can store frequently-used features so that they're always a single click away (even when the Ribbon is closed!)

Probably my favorite improvement to the Quick Access Toolbar ("QAT") in the Office 2007 Beta 1 Technical Refresh is the ability to add Ribbon groups to it.

That's right--just like you would right-click a command to add it to the QAT, you can now right-click a group to add the whole group to the QAT as a single icon. The group is added as a "popup group" which kind of works like a menu in that it pops down, you can use the controls in the group, and then it disappears back out of sight. As with Ribbon groups in general, the 2-D layout puts features closer to your mouse cursor than a flat list, and the layouts will be familiar because they're the exact ones used in the Ribbon itself.

Adding groups to the Quick Access Toolbar - Click to view full picture

This works great for packing a large number of features into a very small space, and it's more convenient than adding each feature individually. Some power users have indicated they plan to use the feature to enable them to take advantage of the improved organization and layout of the Ribbon while not needing to have it open all of the time.

It's just one example of a broadly useful feature which came directly from the feedback on Beta 1.

Picture This: A New Look For Office

jensenh — Thu, 09 Mar 2006 20:00:00 GMT

This morning at the CeBIT conference in Germany, we revealed the new visuals for the Office 2007 user interface.

You can see a few screenshots of the new look on the Office 2007 UI Preview Site. If you've got a craving to see even more, I've created a mini-gallery of full-size screenshots from a recent build of the product below.

I've also posted a guest article written by my colleague Brad Weed, head of the Office Design Group. He's penned an in-depth, behind-the-scenes look at the new visuals from his perspective as a designer.

Screenshots of the Office 2007 User Interface

First, here are some basic screenshots of the Office 2007 programs.

There are so many changes from the Beta 1 visuals that it would be hard to make a complete list, but a couple of the things you might notice right off the bat: the Quick Access Toolbar in the title bar, group titles on the bottom of groups, and the Office Button (more on that below.)

Click each thumbnail to open a full-size version of the picture.

Word 2007 - Click to enlarge picture

Excel 2007 - Click to enlarge picture

PowerPoint 2007 - Click to enlarge picture

Outlook 2007 - Click to enlarge picture

Access 2007 - Click to enlarge picture

Close-up Screenshots of the Ribbon

If you don't have the bandwidth to download the full-window pictures above and you just want to see the Ribbon, these pictures are for you.

Word 2007 Ribbon - Click to enlarge picture

Excel 2007 Ribbon - Click to enlarge picture

PowerPoint 2007 Ribbon - Click to enlarge picture

Contextual Tabs

As I've written several times here on the blog, Contextual Tabs are at the heart of the new user interface. When designing the visuals, we wanted the Contextual Tabs to feel special and part of a group--but in the end, they also need to feel like real tabs. This is one of many places in which usability results informed our visual design decisions.

Table Tools in Office 2007 - Click to enlarge picture

Diagram Tools in Office 2007 - Click to enlarge picture

The Office Button

The Office Button provides access to all of the document and system-level functionality in the program. This is where you go to start doing things with your document in Office--from simply opening a file to saving as a PDF to starting a workflow or publishing the document on a server. This is where you start a document, and this is where you finish a document.

There's so much more to write about this in the future, but here's the simple screenshot of what you get when you first click the Office Button.

Office Button - Click to enlarge picture

Adjust To Taste

In Office 2007, we've done something else that we've never done before: given you a choice of skins for the user interface. If you don't like the default blue skin and would prefer something more neutral, we've got you covered with the striking new black skin.

Going Dark in Office 2007 - Click to enlarge picture

On Windows Vista, of course, we fully support glass in both skins. I'll get you some screenshots of that in the not-too-distant future.

Coming Attractions

The team is beyond excited to finally be able to show you what we've been up to recently. There's so much to write about now that we can start showing in more detail the changes we've made since Beta 1 and how the parts fit together.

In the coming weeks, I'll detail more of the thought process and analysis that went into these designs, along with additional perspective from a few guest writers.

The Beta 1 Technical Refresh, from which these screens were taken, will soon be in the hands of our private beta testers. Meanwhile, we remain hard at work on Beta 2.

It's not too late to sign up to receive Beta 2 of Office 2007 when it's ready later in the year. I hope you'll consider giving it a try and letting us know what you think.

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.

Designing Against a Degrading Experience

jensenh — Thu, 02 Mar 2006 15:00:01 GMT

I'm sure many of you have experienced being the "one who knows about computers." In social and family situations this often means having to help to fix, clean up, or otherwise restore a computer experience which has fallen into disrepair.

There are a million reasons software experiences can degrade: unintended installation of add-ins or spyware and seldom-used programs eating up disk space and memory (or launching on Windows startup) are just two of the popular ones at which people like to point fingers.

Office is not immune to the perils of a user experience which degrades over time. But in Office's case, it's not usually a spyware or a performance issue: it's the UI.

One of the fun parts of my job is going on site visits, in which I have a chance to watch people use Office in their actual work environment. You learn so much about how people interact with software by seeing them use it, in their cubicle or office, along with the other artifacts of their work: calendars, sticky notes, staplers, physical inboxes, piles of forms, etc.

In site visits, I seldom see a real-world Word screen which looks anything like the beautiful marketing screenshots we create. You know the ones--the menu bar at the top with a single untouched toolbar below it and the rest of the screen clean and full of document.

What do we see more often in the real world? Toolbars everywhere--floating over the document, floating outside of the window, docked to the side, sometimes even docked above the menu bar. The menu bar itself tends to get dislodged through an unfortunate click or two and ends up docked to the left side or even floating. In short, the longer and harder people use Office, the more messed up their UI gets.

The reason? Current versions of Word or Excel or PowerPoint tend to reveal more and more of the UI as you go, and seldom does that UI get put away. So, because someone used a picture once, the Picture toolbar is floating, but everything is grayed out because there's no picture in the document. And the reviewing tools are up. And the Table toolbar. And Mail Merge. And Drawing. There are tiny icons everywhere.

But when we ask people why these toolbars are up, they don't know and the top question we get asked is "is there some way to close these without losing the features?" People are worried that they won't be able to find the tools they need again once they close a toolbar, so they just defer to keep it open, using up space (or covering their document) even though they hardly use the features in question.

As a result, one of our goals for the Office 2007 user interface is that Day 1 looks like Day 101.

We hope to walk into a site visit after someone's been using Office 2007 for a year and have it look as clean as it did in the screenshots on the back of the box.

How do we work towards that goal? The main enabler is one of the design tenets of the Ribbon: a single home for features.

Sure, the Ribbon might be a little bigger than a single toolbar, but everything's in there--it's like a flat tax. You give us a little bit more screen real-estate up front (about the same amount as two toolbars in Office 2000 or 2003) and that's all we'll take. Additional features reveal themselves within the Ribbon through Contextual Tabs, and they put themselves away when they couldn't possibly be used. (For example: You can't use the Table Tools if you don't have a table in your document anyway; everything would be disabled.)

Our hope is that we've created a user interface which will stand the test of usage over time--one which doesn't get more complicated just because you're using it.

One which doesn't require you to clean up after the software.