CHAPTER 14: Relativity: Understanding UI Time Warps – User Interface Design for Programmers

CHAPTER
14
Relativity:
Understanding
UI Time Warps

When you write software, you have to remember three rules:

  1. Days are seconds.
  2. Months are minutes.
  3. Seconds are hours.

Confused? Don't worry. I'll explain in a minute. But first, a book review.

In 1956, Robert A. Heinlein, the Grand Master of science fiction, wrote a book forboys called Time for the Stars. It's been a long time since I readit, but here's what I remember. A fairly mysterious organization called the "Long Range Foundation" is planning an interstellar space trip at a velocity pretty close to the speed of light to search out new planets to colonize. In order to communicate between Earth and the rocket, they can't use radio, of course, because it would be limited to the speed of light, and therefore too slow. So, they decide to use mental telepathy, which, as we all know, is not restricted to the speed of light.

Silly enough? It gets better. The Long Range Foundation carefully selects two twinbrothers, Tom and Pat, who have tested very highly on the ESP test. They send one brother away on the spaceship while the other stays home on Earth. And nowthe ship can communicate with Earth simply by using mental telepathy between the brothers. Great!

Now, here's the educational bit. Since the spaceship is traveling near the speed of light, time passes slower on the spaceship. So when Tom (or was it Pat?) comes back to Earth, he has only aged a few years, but his brother has died of old age. It's a very poignant book, as 1950s juvenile pulp sci-fi goes.

Anyway. Back to software. (Aw, do we have to talk about that again? I was enjoying that brief digression into space travel.) When you write software, you have to deal with so much time dilation that science fiction sounds positively normal.

Days Are Seconds

It usually takes days of design, programming, and testing to create a fragment of software that a user will experience in a matter of seconds. For commercial-quality software, a typical small dialog box might take about four days to code, realistically. But the user will only spend ten seconds in that dialog box.

What that means is that some aspects of the dialog may make perfect sense to you as a programmer, because you spent four days thinking about them, but they won't necessarily make sense to a user, who has to figure them out in a couple of seconds.

Figure 14-1, taken from Corel PHOTO-PAINT 9, shows one tab of a print dialog that probably took months to design and create. The attention to detail shows throughout: there's a handy preview pane, which graphically illustrates what the rest of the dialog means.

However, there are still a lot of things here which probably made perfect sense tothe programmer after three months of thinking about printing, but which users will probably not figure out so quickly. What's all that stuff about tiling? What's an imposition layout? The fact that the programmer had so much time to learn about printing while the user has only a couple of minutes, at most, leads to a real imbalance of power. The programmer is convinced that the dialog is quite straightforward and easy to use, and the user is just downright flummoxed. Flummoxed!

The best solution to the "Days = Seconds" time warp is to do hallway usability tests. After designing your dialog, print it out, take it down the hall to the lunchroom, and ask the first three people you see to explain the dialog to you. If there are any serious problems, this will probably uncover them.

FIGURE 14-1


This tabbed Print dialog probably took months of work. But most users will not be willing to spend more than about ten seconds figuring out how to print.

Months Are Minutes

Let's pretend, for the sake of argument, that you discover that there's a real, unmet need for grilled marshmallows in the workplace. "Popcorn and Cappuccinos are passé" you think. So you set out to create a marshmallow-grilling device that you hope will take the world by storm.

At first, your concept is quite simple. There's a slot in the top into which you pop the marshmallows. Seconds later, they emerge, fully grilled and toasty warm, from a tray on the bottom, ready to be eaten.

While you are trying to explain the whole concept to a manufacturer of business-grade heating elements, the guy erupts in laughter. "Grilled marshmallows? Without graham crackers? Who would eat one of those things without graham crackers?" Now you start to worry. Most of the people you talked to seemed to like the idea, and many of them explicitly stated that they hate graham crackers, but a bit more research shows that there's a whole population of people that just will not eat their grilled marshmallows unless they have graham crackers. So you add a second slot to your design, for graham crackers.

As time goes on, more problems are discovered. Certain inferior brands of marshmallows cannot be reliably grilled without catching fire, so you add a little fire extinguisher button on the front panel that puts out any accidental fires. The CEO you hired points out that you're now two thirds of the way to making s' mores, so you add a third slot for putting in chocolate bars, and a S'more button, which makes a tasty chocolate, marshmallow, and graham cracker sandwich (although graham crackers come in two sizes, so you have to add a switch to choose the size).

Then usability testing reveals that some people like their marshmallows almost raw, while others want them virtually charred with liquefied middles (mmmm). It's not just a matter of how long they cook: it's a matter of how quickly you turn them over the heat, whether the heat is radiant or from a flame, and so on. Eventually your little marshmallow-grilling device has six different adjustment knobs and two kinds of heating elements.

"This is for the workplace," your head UI designer tells you. "It will be used by many different people. Those people aren't going to want to remember all their personal settings." So you add a Save Settings button with a little LCD panel, and a Load Settings button. Now, you can file your personal marshmallow-grilling settings under your own name.

"Privacy!" scream the privacy advocates. "What if we want to be able to save our settings without every gossip in the office knowing how we like our s'mores?!" Fine. A password feature is added.

"What if someone forgets their password?" Now it's getting ridiculous. OK. The password feature is enhanced with one of those silly challenge-response questions like "What's your mother's maiden name?" and, if hooked up to the LAN, it can email you your password when you forget it.

By now, the tiny LCD panel has grown into a 15" color screen, the control panel looks like the cockpit of the space shuttle, and it costs $1275 to manufacture. But after two years in development, the thing finally ships!

Your very first customer buys one and takes it home, excited. But when she gets itout of the box, there's a two-hundred-page manual, a software license agreement, a control panel with dozens of buttons, a programming handbook for the scripting language, and the screen is asking her if she wants to sign up for AOL.

The "Months = Minutes" rule is a corollary to the "Days = Seconds" rule. When you create a new software package, even a fairly simple one, it typically takes between six months and two years from the initial conception to shipping the final bits. During those months or years, you have an awful lot of time to learn about yourown program and how it works. When you invent a new concept every month or so for two years, the learning curve is not very steep—for you. For your user, it means there are twelve things to learn right out of the box in the first five minutes of using the dang thing.

The products that we recognize as being the best designs always seem to have the fewest buttons. While those products were being created, it's pretty obvious that the designers kept thinking of ways to simplify the interface, not complicate it. Eventually VCR designers realized that when you stick a videotape in the slot, they should switch from TV to VCR mode and start, um, playing the tape. And then they figured out that when it's done playing the tape, it might as well rewind and eject it. For watching movies, at least, you don't need to press a single button.

As you design and build your product, try to notice if you are adding complications or removing complications. If you're adding complications, remember that something that seems easy when you have months to design itis not going to seem so easy when your user has only minutes to learn about it.

Seconds Are Hours

The third time warp rule is that it doesn't take very long before somebody gets bored and decides that your program is slow. If your program feels slow, your users won't feel in control, and they'll be less happy. "Seconds = Hours" refers to the fact that if you make somebody wait, say, nine seconds, they will whine and cry about how it took hours. People are not very fair. You can give them a Web site where they can find over thirty-four thousand recipes for tuna casserole in seconds, something that used to take a trip to Washington, D.C. and months of researchin the Ladies Home Journal archives of the Library of Congress, butif a recipe takes thirty seconds to appear on the screen, your ingrate users will moan about the "World Wide Wait" and how slow their modem is.

How long is too long? This has been the subject of years of debate among usability experts and Human Boredom Research scientists. I am happy to announce that after an exhaustive survey of over twenty thousand college sophomores, I have the final answer. Boredom kicks in after 2.73 seconds, precisely. So let's all keep our latency to 2.72 seconds or less, OK?

Just kidding!

The real answer is that it's not the passage of time that's boring, it's boredom that's boring. I can walk three miles down Fifth Avenue in Manhattan without getting bored, but walking a thousand feet past featureless cow pasture in Kansas feels like it takes an eternity. Boredom is a function of the rate at which stimulating things happen to your brain.

When someone clicks on a link on a Web site, they are probably not doing anything but waiting for that page to appear. So if it takes ten seconds to show up instead of five seconds, it seems like a really long time. On the other hand, when they start to download the latest Ricky Martin MP3 over a modem, it's going to take twenty minutes, so they find something else to do while they wait. And if it takes twenty-one minutes instead of twenty minutes, it's no big deal.

To fight boredom, create the illusion of low latency. Good UIdesigners use three tricks to do this.

Trick One. Always respond immediately to the user's request, even if you don't have a final answer. There's nothing more annoying than a program thatappears as if it's not responding to mouse clicks simply because it's performing a long operation. You should always give an immediate response, even if it's nothing more than changing the cursor to an hourglass or displaying a progress indicator. (Among other things, this lets the user know that the program received their click. A program that doesn't respond immediately to mouse and keyboard input appears dead to the user. At the veryleast, they will click again.)

Trick Two. Find creative ways to break up long operations. The best example I've seen of this is in Microsoft Visual Basic. The designers of the Basic compiler realized that almost all of the time spent compiling is actually spent parsing the program text (that is, breaking down a line of code into its constituent parts). If it takes, say, half a second to parse a single line of code, and one one-hundredth of a second for everything else, then a hundred-line program will take fifty-one seconds to compile. But the Visual Basic designers put the parser into the editor. When you hit Enter after typing a line of text into the editor, that line is immediately parsed and stored in parsed form. So now, hitting Enter takes half a second, barely perceptible, and compiling a hundred-line program takes one second, also barely perceptible.

Trick Three is the exact opposite of Trick Two. When all else fails, bunch together all the slow operations. The classic example is your extremely slow setup program. It's slow because it has to download files, uncompress them, and install them. There's nothing you can do about that. But what you can do is make sure that all the slow bits are done at the end, after gathering any required input from the user. Have you ever started a long installation procedure and gone to watch TV, only to come back an hour later to find that the setup program has stopped and is waiting for you to OK the license agreement before it starts downloading? When you have a really long operation, always get all the input you need from the user first, then tell them explicitly that "this will take a while. Go get some M&Ms."