Jensen Harris: An Office User Interface Blog : UI Design Issues

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.

Iterative Design Process Applied to Charting

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

I know I seldom do two posts in a day, but in addition to Rich's guest article, I wanted to point to a very interesting article Sander, one of our designers, wrote on the Excel blog.

The article is focused around the charting experience, but he posted some of the screenshots of the early prototypes we used to test Office 2007 UI designs in general.

These wire-frames, mockups, and paper prototypes were all used before we had written any code at all, as a way of evaluating how successful a design direction might be. Sander gives his perspective on how the iterative design process we used helped to shape the charting user experience. I think you'll find it interesting.

Keen eyes will notice many things that are similar to how they are in the product today, and many concepts which have changed.

Anyway, at some point in the not-too-distant future, I plan to post a set of prototypes for posterity (and for your enjoyment), but I thought Sander's article might help whet your whistle in the meantime.

Check it out.

Usability: Art and Science

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

Yesterday morning we were sitting in the office of one of our usability researchers watching some DVCAM tapes from tests conducted a few weeks ago.

We had a discussion that got me thinking about a set of tests we ran several years ago to determine the discoverability characteristics of contextual tabs.

At the time, contextual tabs were struggling in the usability lab. The visuals and triggers were not obvious enough, and even when people noticed them, the tabs looked so different from normal tabs in the UI that participants thought they were decorative or unactionable.

We kept iterating and iterating on the design, and one of the desperate ideas we had was to pop up a little yellow balloon the first time a contextual tab set appeared saying something like "Hey you, contextual tabs have appeared, you better click here get to the tools for working with your table."

(I'm sure the real wording was a lot more Microsoft-esque.)

Anyway, we wrote a little app to enable us to pop up the balloon at the right time--but it was a totally manual process. We had two keyboards hooked up to the usability computer, and when the contextual tabs appeared, one of us in the back room would press F10 on our keyboard to make the balloon appear. So the timing was a little weird, but it was cheaper than building the feature directly into the product itself.

The balloon wasn't the only change to the design in the new build being tested, however--we also tested improvements to the visuals and the triggers that activated the contextual tabs as well.

The result of the tests? The usability characteristics of contextual tabs improved dramatically.

But now we had a quandary: which improvements precisely had caused the uptick in usability? The balloon? The substantive changes to the interaction model? The clearer visual design?

One could imagine a world in which we ran controlled, double-blind studies to test the impact of each element of the design separately to assess the best possible combination.

In reality, though, we tend to use an iterative process in which we bring an entire design to a next level and then (if the design is successful) figure out which are the non-critical parts of the improvements. The advantage to this process is that it lets us move faster and abandon bad ideas sooner.

In this particular case, we felt kind of icky about the balloon, so we decided to run another set of tests to see how much not showing it changed the results from the previous successful test. It turned out that the test results didn't change at all mathematically; the usability of the feature was being impacted much more by the substantive changes to the design than by the notification balloon.

Developing a contextual tab design that worked well took well over six months of concentrated iterations, followed by tweaks over the last two years or so as we continued to make progress on the design surrounding them.

The biggest reset recently was when we introduced new visuals for Beta 1 Technical Refresh last winter and we had to reevaluate usability of the entire UI based on the new look.

Some of the most interesting studies we did were eye tracker comparison tests which enabled us to see how and where the new visuals affected the scanning pattern of the UI. It turns out that moving group labels to the bottom of each group in the Ribbon, for instance, helps people target the control they're looking for a bit faster than in the Beta 1 visuals.

So, could we apply an even more incremental method of usability confirmation to more fully test each element of a design change in isolation?

Perhaps, but a design is much more than the sum of its parts, and the usability of one piece always has to be weighed against the usability of the overall product. This is where art meets science.

There's a talk I give to program managers internally at Microsoft in which I present a 100% guaranteed way to improve the discoverability of a fictitious "Send via Telegraph" feature in Word:

You can't evaluate the usability of just one feature or component of an overall design without understanding its impact on the entire product.

Good design is the art of balance.

It's an art that can be infused and informed by scientific rigor, but in the end it's still an art.

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.

Catching the Plane

jensenh — Fri, 19 May 2006 17:00:00 GMT

One of the most challenging aspects of developing the new UI has been making sure that everything ends up loaded into the airplane before it takes off. Confused? Let me explain.

Sometimes I think about shipping Office like an airplane taking off. Our job is to load up the plane with the right passengers, the right luggage, enough soda and snacks, professional pilots, lavatory service, and great in-flight entertainment.

But once the airplane takes off, it's gone--there's no turning back. It's going to land at its destination regardless of if all the pretzels came on board. The insect which flies in through the airplane door two seconds before it closes ends up halfway around the world at the plane's final destination. On the other hand, a piece of luggage which is late to the plane by thirty seconds misses the destination entirely and can only be returned with a great deal of cost and effort.

Our job, then, is to make sure that all of the features find their way onto the plane before it takes off. With so many features buried in menus, toolbars, Task Panes, context menus, and the command well in Office 2003, there are thousands of moving parts to track. Sure, we'll make sure that Bold finds its way to Sydney, but what about "Collapse Subdocuments?"

We have a number of systems in place to triangulate this problem and to help ensure that we don't leave anything behind. We have documents which track every visible piece of UI in Office 2003 in all languages and editions and where it's moved to in the new version. How do we create these documents? Someone manually goes through every menu and toolbar, noting everything they find.

We also have a SQL database which tracks all of the commands programmatically and can spit out a list of where in the UI each feature is accounted for. This database also backs the various migration tools we're making available such as the Ribbon Mapping Tool--a clickable simulation of the old UI and new UI used to help locate any command in the product.

Just like with baggage moving through the bowels of the airport, being routed, security screened, and weighed, each feature has a set of trials it goes through before it can be marked as "ready to go."

For example, each top-level feature needs a Super Tooltip: a brief summary of what the feature does and why you might want to use it. We wrote well over a thousand of these. We also created tooltip pictures to help better explain certain features.

Every feature needs an icon in several sizes and color depths. In most cases, the hardest part of this process is developing a metaphor to illustrate what a feature does.

Every feature needs to be checked to ensure that it uses proper spelling, branding, and capitalization. We use Title Case for features exposed through the Ribbon. In dialog boxes, we use sentence case for labels and Title Case for push buttons. This review is underway internally as I write. Every label fixup in the product then needs to be translated into every language in which Office will ship.

Help then needs to be written about the location of each feature, and that help needs to be translated into each of our supported languages.

We have to get all of Office's features accounted for, beautified, documented, localized, and on the airplane before the cabin doors close and the plane taxis to the runway.

It's a part of the job that requires painstaking meticulousness and coordination between many people to ensure that the luggage isn't lost.

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.

Not So Set In Our Ways After All

jensenh — Mon, 27 Feb 2006 15:00:00 GMT

Back in the article "Set In Our Ways?" I talked about one of the design issues we were thinking about at the time--namely, whether or not it was OK sometimes to break commands out of a set.

In particular, we were thinking about the Mini Toolbar which comes up on selection and as part of context menus in Office 2007. As you may recall, in order to make the best use of the limited space available, we needed to cast a critical eye on the content included in this UI.

With many people clamoring for indent, outdent, highlighter, and styles, it seemed like a waste of space to include much less frequently-used features such as right justify and underline.

As it often does, an interesting discussion ensued, and many of you encouraged us to break with convention.

So, for Beta 2 we decided to take the plunge and really optimize around the most frequently-used commands, breaking the restriction that all of the commands of a "set" (such as Bold, Italic, Underline) have to be together.

Here's what we decided on as Beta 2 content for the Mini Toolbar in Word:

(Remember, the complete set of commands is still always available in the Ribbon--the Mini Toolbar is for super-efficient mouse access to the absolute most frequently-used commands.)

An overview of changes from Beta 1:

Styles were added (the button next to Format Painter on the top row)
Underline, left justify, right justify, and numbering were removed.
Highlighter, Indent, and Outdent were added
Center is now a toggle button which toggles between Center and Left Justify (if you click Center on centered text, it left justifies.)

As a result, the set of features available maps much more closely to the most frequently-used features in Word while taking even less screen real-estate than the Beta 1 Mini Toolbar.

We made similar enhancements to the Mini Toolbar in Excel, PowerPoint, and Outlook based on the same design criteria.

So, as always, thanks for taking the time to write your thoughts--it was because of feedback from the internal beta program as well as the discussion here that we made this change.

I'm finding the updated Mini Toolbar to be a lot more useful, especially because of the indent/outdent and highlighter that I missed so much on the Beta 1 version. And I know, based on overwhelming feedback, that many people will be happy to have access to Styles as well.

So, while I'm optimistic about the improved design, only time will tell as we get the next round of feedback based on Beta 2.

Prototyping With PowerPoint

jensenh — Mon, 20 Feb 2006 15:00:00 GMT

A couple of weeks ago when I talked about The Feature Bob Invented, I mentioned that we use PowerPoint as an easy way to prototype UI, especially in the early stages of design. A number of people have asked me for more details, and so today I thought I'd go through it step-by-step.

We use PowerPoint as kind of a better version of paper prototypes. This technique has several advantages: prototypes can be made to feel somewhat interactive, because the content is electronic it can be modified more easily than paper, and (best of all) the usability participant uses the mouse and is on the computer, so it feels natural to them.

In my opinion, paper prototypes always suffer a little bit because of the weirdness of asking people to pretend paper is the monitor and a pencil is the mouse. (Although I guess with the advent of Tablet PC's, this is becoming less weird...)

Note: The following technique will only work for PowerPoint 2002 and above. Previous versions did not include sufficient support for transparent AutoShapes.

The way we normally set up PowerPoint prototypes is this:

Put screenshots of all of the different UI states you want to test onto different slides.
If your UI is mostly popups on top of a static frame, you might consider putting that static frame into the slide master background; that way, you only need to put the UI which changes on each slide. (Click View, Master, Slide Master to access the slide masters.)
Next, you want to make sure PowerPoint doesn't advance your slide show to the next slide whenever the user clicks. This is so you can simulate interactive click behavior within the prototype. Click Slide Transition on the Slide Show menu, turn off the setting to Advance Slide On Mouse Click, and then click the Apply All button to apply the setting to all slides.

Now, that your overall prototype is set up, it's time to add interactivity. Let's say you have a button, and when someone clicks on that button, you want it to simulate bringing up a menu. Easy enough, assuming you have added slides containing pictures of both states (pre-menu and while the menu is up.)

Using the Drawing toolbar at the bottom of the screen, draw a box over the hit target for the button. (You can use any other AutoShape you want, it doesn't have to be a rectangle.)
Now, right-click the shape and click Format AutoShape on the context menu.
On the Colors and Lines tab, set the Transparency to 1% and remove the border entirely. This will make the shape virtually invisible, yet will still allow you to receive mouse clicks on it. (If you make it entirely transparent, PowerPoint doesn't register mouse clicks on the shape.)
Now, right-click the shape again, and click Action Settings on the context menu. This is where you determine what should happen when the button is clicked.
Normally, I choose "Hyperlink to:" in the dialog and then choose to which slide it should navigate. You could also be fancier and have an external program launch, a sound played, or run a custom macro. If you wanted a snazzy rollover effect, the Mouse Over tab in this dialog would be the place to do that.
Repeat this process for each slide to which you want to add interactive behavior.

You're good to go! We've found that this technique has yielded some very useful prototypes with a minimum amount of work.

Set In Our Ways?

jensenh — Thu, 09 Feb 2006 15:00:01 GMT

Today, just thinking aloud...

A minor design conundrum we face is as follows: based on the data we collect, we can see that within certain sets of related features, some of them are used much more frequently than others. Should we ever act on this data by showing only the most-used features in a set?

Let's take three of the most common "sets" of icons in Office: "Bold - Italic - Underline", "Left Justify - Center - Right Justify", and "Undo - Redo".

Conventional wisdom and common practice dictate that wherever one of these icons tread, all of them should appear. I don't think I've ever seen a user interface with just Bold and Italic and not Underline. (At least not one that actually has an underline feature...)

Yet, when you look at the data, Bold is one of the most-used features in Excel but Underline hardly registers. Left Justify and Center are used 100x more than Right Justify in Word. And Redo might as well not even exist next to the towering fame of Undo.

The design challenge comes when we want to pack high-usage commands into a small space, such as when we decide on the default content of the MiniBar or the Quick Access Toolbar. People want efficient access to Bold, but they probably don't need as quick access to Underline. In the past, we've always treated those three icons as a set, but could we get away with only Bold and Italic?

Same with text justification: the data would dictate only putting Left and Center on the MiniBar, perhaps to give way to a more-used command like Highlighter. But would people wonder and criticize why Right Justify isn't there? Do the Left and Center buttons stand alone, or do they require Right in order for people to intuit what they do?

There are other options, of course. We could turn text justification into a dropdown menu, as recent versions of another commercial word processor does. But then you're requiring an extra click to get to any of these features--and at that point, having it on the MiniBar isn't saving you much time anyway.

It is safe to say that we're at least considering dropping a few icons from the MiniBar (only) in order to make room for features people use more.

Perhaps the hardest pill for me to swallow though is having Redo on the Quick Access Toolbar. Undo absolutely belongs there; it is one of the most-used features in Office and it needs to almost feel like part of the frame--something always available regardless of the tab of the Ribbon you're on.

But Redo is used in fewer than 3% of work sessions. And the Quick Access Toolbar is prime real-estate--a place we don't want to take up any extra space whatsoever for superfluous icons. So could you have Undo without Redo? Where would Redo go? It's not used so infrequently as to remove it altogether, so it has to have a home. The current design, in which both Undo and Redo are in the QAT, is the trade-off we feel best with so far.

Does the product's complexity go up much because of the extra Redo icon next to Undo? The good news is "probably not," because you expect to see Undo and Redo together--in this case the extra icon just completes the Back/Forward metaphor seen in so many apps today (especially the web browser.)

I guess a related question would be: Does having a well-known icon missing from a set (say, only Bold and Italic and not Underline) actually cause cognitive dissidence because it feels wrong? These are all interesting questions to look into...

Flea Market of Functionality

jensenh — Tue, 31 Jan 2006 18:00:00 GMT

Last Monday, I set out a simple brain teaser for the Word gurus out there. I listed a number of seemingly unrelated features in Word 2003 and asked the question "what do these have in common?"

John Topley got the answer I was looking for in the very first comment to Monday's post: all of the features I listed are on the Tools menu. Many of you also sent me the correct answer via e-mail.

The point I was trying to make is simply this: don't over-romanticize how ideal the current menu structure of Office is. Although any organization of disparate features is going to have strengths and weaknesses, there's nothing "magical" about File Edit View Insert Format Tools Table Help. I don't want to belabor the subject any further—if you want to read more about the relationship between familiarity and the classic menus, read last Monday's post.

Instead, I wanted to get to an interesting comment Ben R. made last Monday: is it inevitable that there's always going to need to be a "junk drawer" of leftover commands in an application and how is that handled in Office 12?

It caught my eye because "junk drawer" is a term we use as well. I think of a junk drawer as being features piled together primarily for the convenience of the UI designer. The Tools menu is a great example of a formalized junk drawer—an entire menu envisioned as a kind of flea market of functionality.

The upside of the Tools menu is that it's easy to design. When the next four unrelated features get created, you know in which menu to stack them. The downside is that it creates a huge rock that people have to turn over every time they want to find something. There's no way someone could ever rule out "Tools" as a place a feature could be; predictably, when we watch people look for features, they spend a ton of time being sucked in by Tools. (Even though the thing they're looking for is hardly ever there.)

Feature organization is an inexact science. Whenever we propose a new content organization for a set of features, one of the standard questions we ask ourselves is "is this a junk drawer?" And, honestly, sometimes it's a painful question to ask because you really have to force yourself not to create one. Some features flow completely naturally into a feature organization and some are always outliers. In a program as vast as Word or Excel, there are a lot of outliers, and finding the right home for each of them takes thought and creativity.

What tricks do we use to help avoid junk drawers? The first is that we try to force ourselves to use descriptive labels for tabs and groups. We specifically avoid words like Tools, Properties, Options, Edit, and Advanced, which lend themselves to the junk drawer mentality. When we do need a more generic term to help describe what's in it (for instance, the Design tab in PowerPoint), we try to use a word that hasn't been overloaded with meaning in Office already. This helps us to assert the meaning of that word and frees us from the expectation that it maps 1-to-1 with an old menu or toolbar.

The most important technique, though, is just vigilance. There have been a few times in which we almost resigned ourselves to relying on a junk drawer in a certain area and then someone came up with the key insight that brought it all together. Internally, we're constantly shifting content around in the Ribbon, improving the organization and relationship between features.

Why is it important to avoid junk drawers? In our experience, the more specific and logical your feature organization is, the less time people spend hunting around the UI to find things. Every junk drawer in the product is going to take a click any time someone's looking for something—so the productivity cost can be enormous.

So, to answer Ben's question. No, I don't think it's inevitable that even a large program like Word has to end up with a junk drawer. Ensuring that your program doesn't have one will likely cut down the time required to find and use features. The downside is that it's really hard to avoid this design pitfall, and might be extremely difficult to pull off in an existing product without performing a full, ground-up reorganization as we're doing in Office 12.

Obsession to Detail

jensenh — Thu, 26 Jan 2006 18:00:25 GMT

The success of a user interface depends on getting the details right. That's not to say that a little bit of fit-and-finish work can save a horrible design, but a good idea won't thrive either unless enough of the little details are right.

I know that I am sometimes frustrating to work for because I can be a bit of a perfectionist around the UI. Especially during the last part of the product cycle, I'm constantly prodding and poking (and asking those around me to prod and poke) to make sure that every decision we make is as good as it can be. (I mean, you only get one chance to do something like this, right?)

Our development team has gone out of their way to provide us the opportunities to get the details right. Unfortunately, sometimes getting the small stuff right costs way more time and energy than doing something "most of the way." Yet, the whole team has remained committed to going beyond the "good enough" mentality so that the user experience is seamless in ways you wouldn't even notice unless we got them wrong.

One of my favorite examples of this was a design change we made a number of months ago called "Eat Dismiss Clicks."

Here's the setup. Let's say that you drop down a menu in Windows. Now, instead of clicking a menu item, you click somewhere else on the screen. This has always dismissed the menu and sent a mouse click to wherever you clicked. Nothing surprising so far; this is just how the Windows focus model works.

Now, let's say you insert a Picture in Office 12. As you know from my discussion of Contextual Tabs, the Picture Tools appear in the Ribbon because the picture is selected. So far so good.

You decide you want to add a shadow to the picture. So, you drop down the Shadow gallery from the Ribbon and look through the shadows available. You don't see anything you like, so you click somewhere other than the gallery to dismiss it.

BAM! Your click goes through to the document. Because the click wasn't on the picture, the picture gets deselected. Because the picture got deselected, the Picture Tools disappear. Now, all of a sudden, just because you didn't see a shadow you wanted, all of your tools disappeared and you have no idea why.

It's easy from a developer point of view to explain this as the "correct" behavior. The behavior is perfectly logical, and it follows the way focus has worked in Windows for decades. It would have been tempting to have just left this as is, and to have rationalized that people should make sure to hit "Escape" or to click somewhere on the Ribbon or title bar to dismiss the gallery instead.

But when we looked at people actually trying to use the product, they didn't "aim" their "dismiss the menu" click at all. They weren't actually trying to both make the gallery go away and also perform some action with a single click. Clicking away from the gallery was just an efficient and discoverable way of making it disappear. The software was behaving rationally, yet it nonetheless managed to completely confound the user's expectations.

So, we had a quandary. Making a fix was expensive, complicated, and involved working around the Windows focus model. The test team was concerned that a lot of unforeseen quality regressions would occur. Code down deep in each of the apps would have to change. It was the kind of scary technical problem no one wanted to touch with a ten-foot pole.

Did we make the change? You betcha.

Because it was too important to get the details right not to. We bit the bullet, worked through the technical issues, found and fixed the bugs, and checked it in.

And now? People find this part of the experience to be seamless. No one ever notices the work the team did to get that detail of the design right, because it works the way you'd expect if you just sit down and start using it. Sure, there's a detailed and complicated technical story behind how it works--but that's what we get paid for, figuring out how to put technology at the service of delivering great software experiences.

The "Eat Dismiss Clicks" story is emblematic of how our team has tried to go beyond to get the little things right in the Office 12 UI. If we do the job well, the experience is seamless, responsive, and predictable, and it makes all of the extra work worthwhile.

It's the obsession to get the details right that makes all the difference.

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.

I Am Your Density

jensenh — Thu, 15 Dec 2005 18:00:00 GMT

A comment we've heard again and again about the Office 12 interface after people use it or see it demoed live is: "wow, it's so much better than I imagined just by seeing the screenshots." Several people made that comment to me once again after my talk at PARC Tuesday night, and I wanted to write down some thoughts on the subject.

Fundamentally, there's a kind of UI that is built with great screenshots in mind. Generally including big, shiny buttons with copious whitespace on all sides, these interfaces look extremely simple and easy-to-use in "back-of-the-box" marketing screenshots. The screenshot-optimized interface is generally low-density, with only a few controls on the screen at once.

We've definitely thought about this in designing boxshots for marketing materials in past releases of Office. The picture we show on the back of the box is what the product looks like the first time you run it. But one of the problems with the current Office user interface is that it tends to degrade over time--toolbars pop up over your document and never go away, things get accidentally moved, Task Panes pop up automatically, etc. When we do site visits, we often see Office screens that look more like the picture below than the one on the back of the box.

Back of the box vs. Real world screenshots

This is not deceptive advertising in any way, it's just the reality that today's system of menus and toolbars and Task Panes tends to present more and more complexity over time. It's true for today's Office, and it's equally true with dozens of other full-featured software packages.

That's because to build efficient productivity software that wears well over time, the interface needs to be relatively high-density. Having only five shiny buttons on the screen is very simple-looking, but it means that using any functionality beyond those buttons requires at least one extra mouse click. (Probably more.)

Based on just a screenshot, the Ribbon appears fairly involved. This is because the density of controls, especially on the first tab which tends to be shown in screenshots, is fairly high. Yet, when people use the new UI or see in action--actually interacting with the software and not just staring at it--it doesn't feel cluttered. The first tab is high-density because it's designed for high efficiency, and you wouldn't want most of those features an extra click away. Bold and Italic and Center have small, unlabeled icons because they tend to be among the handful of features people can use without text labels.

One of the design tenets we've embraced from the very beginning was that the Ribbon was going to be a flat tax on screen real-estate. Yes, it takes up a few more pixels vertically than the two toolbars from the back of the Office 2003 box, but it won't degrade over time. We won't pop up extra UI over top of the document, or from the side, to advertise features. Our goal is that when you boot Word 12 five years from now, it looks as clean as it did the first day you brought it home.

We don't worry about the screenshots; we worry about getting the product right for everyday use. We worry about the long-term ramifications of our current design decisions, not how they'll look on the back of the box. And if that means that some people don't react as positively as we'd like to static screenshots, then we need to redouble our efforts to get people to watch, read about, and use the UI in action.

A friendly, high-density productivity interface that demonstrates respect for your screen real-estate is one that will wear well with time.

Fast At Any Speed

jensenh — Fri, 09 Dec 2005 18:00:00 GMT

One of the major engineering feats associated with shipping Office is making sure it runs fast enough. This effort, which we classify under the broad heading of "performance" includes responsiveness (how quickly a button responds when you click it), throughput (how fast Excel can recalculate a spreadsheet), and "perceived" performance (do the fade out of menus seem right?) Depending on the program, there might be other issues as well, such as network throughput and latency issues, document save/load times, graphics rendering engine speed, etc.

A software legend has somehow arisen that Microsoft waits until the last release candidate and then tunes up performance at the very end before the software goes out the door.

Nothing could be further from the truth; good performance needs to be fundamentally designed and architected into the product--something far too risky to do at the last minute. From Beta 1 onward, a large portion of the resources of Office development are spent making sure that the software is speedy enough: testing on memory-constrained computers, processor-constrained computers, terminal services, Run From Network, x64, and all sorts of different configurations.

From the perspective of the Office 12 new user experience, performance is critical. The very visual nature of the Ribbon, with lots of galleries and Live Preview, lends itself to experimentation. A key goal of the Ribbon is that it's easy to poke around to find and use new functionality. However, most people will only poke around if the interface is responsive and crisp. For example, if it took two seconds to switch between tabs, it might dissuade you from browsing the Ribbon as readily. In fact, we've noticed a profound link between performance and usability; some usability tasks that totally fail when the interface is laggy and lethargic suddenly do great once the software is responsive enough.

With the huge number of improvements in Office 12, making sure the software is responsive is a really critical task. But it's one that we're totally committed to, because great performance is one of the fundamental building blocks of great software experiences.