Section 3.2. THE COST OF NAVIGATION


3.2. THE COST OF NAVIGATION

When you walk into an unfamiliar room, you look around. In a fraction of a second, you take in the shape of the room, the furnishings, the light, the ways out, and other clues; very quickly, you make some assumptions about what this room is and how it relates to why you walked in. Then you need to do what you came in to do. Where? How? You might be able to answer immediatelyor not. Or maybe you're just distracted by other interesting things in the room.

Similarly, bringing up a web page or opening a window each incur a cognitive cost. Again, you need to figure out this new space: you take in its shape, its layout, its contents, its exits, and how to do what you came to do. All of this takes energy and time. The "context switch" forces you to refocus your attention and adjust to your new surroundings.

Even if you're already familiar with the window (or room) you just went into, it still incurs a cost. Not a large cost, but it adds upespecially when you figure in the actual time it takes to display a window or load a page.

This is true whether you're dealing with web pages, windows, dialog boxes, or device screens. The decisions that users make about where to go are similar, whether they use links or buttonslabels still need to be read, or icons decoded, and the users still will make leaps of faith by clicking on links or buttons they're not sure about.

3.2.1. KEEPING DISTANCES SHORT

Knowing that there's a cost associated with jumping from page to page, you can understand now why it's important to keep the number of those jumps down. Two of the patterns in this chapterGlobal Navigation and Pyramidgive you specific ways to do that in complex applications and sites, by taking common navigation paths and turning them into easy single jumps. Patterns in other chapters, like Card Stack (Chapter 4), can help you pack more into a single page, thus sparing you the need to jump to a new one.

But the real efficiency gains come from the structure of the application. One of the nastiest things a designer can do is force a user to go into multiple levels of subpages or dialogs. every time they need to accomplish a simple, everyday task. (Worse is to lead him there, tell him he can't accomplish it because of some missing precondition, and send him back to Square One. Happens to the best of us.)

Can you design your application to do the most common 80 percent of use cases with zero or one "context switches"?

This is hard to do with some kinds of applications. You might think that some kinds of tools just have to be inside dialog boxes, two levels down in your site structure, or wherever. Is a certain tool too big to put on your main page? Try shrinking it: eliminate controls, shorten labels, and use specialized controls that save space (see Chapter 7). Is it too distracting when combined with everything else on the main page? Again, try shrinking it or putting it in an out-of-the-way spot. Do you need that wizard? Maybe its functionality is better rendered in one page than many. Be creative!

Now that I've given you a rule to follow, I'll tell you to break it.

Sometimes it's appropriate to bury functionality inside pages that take more than one jump to get to, such as that extra 20 percent left over from the 80 percent you made easily available. It also could be that on your application, simplicity of presentation is more important than saving one or two jumps. Extras on Demand is a pattern from Chapter 2 that recommends putting little-used functionality behind an extra "door" (also using the 80/20 rule). As always, use your judgmentand usability-test it if you have any doubt.

Designers today seem to be taking all this to heart. Most modern desktop applications now are built around a single main window, often tabbed or tiled, with assorted toolbars and panes around it. It's become less fashionable to use separate windows or dialog boxes for every piece of functionality, and that's a good thing. Web applications also use more clientside validation, progressive disclosure, and other techniques for presenting changeable content without loading a new page each time something changes.

Yet sometimes, you still end up four dialog boxes deep in an application (see Figure 3-1).

Figure 3-1. Four dialogs deep in Microsoft Outlook


Vocabulary check: dialog boxes, windows, pages, or screens?

On the surface, it seems like web sites and applications are hopelessly different with respect to navigation. They're not. Whereas web sites, web applications, and hardware devices have you move from page to page, applications often make you move from window to window or dialog box. Yes, you can keep several windows in view at once. But users really only can pay attention to one at a time, and there's still a high cost associated with shifting that attention from window to window.

Because pages and windows are similar in this respect, I'm going to simply refer to these virtual rooms as "pages" from here on in this chapter. When you see that term, you can generally assume that whatever I'm talking about also applies to windows, dialog boxes, and screens.


3.2.2. TOO MANY JUMPS

To demonstrate what I mean by reducing the number of jumps, I'll walk through a short case study of an interactive site that's not actually all that bad. The task is probably common, though the site designers obviously didn't optimize the site for this task. You'll see what I mean.

I am visiting Amtrak's web site to find out how much it might cost to ride the train from Boston to New York City. My departure and arrival times are flexible, so I'd like to look at several to find the cheapest ones. To my delight, there's a "Fast Fare Finder" on their home pageI can get this information in one quick step! All I need to do is .ll in this mini-form (Figure 3-2), click Go, and I'm there. Right?

Figure 3-2. Amtrak's home page


  1. Click "Go".

    I guess not. Looks like I'm being asked for the same information again (Figure 3-3).

    Figure 3-3. Schedules and Fares

  2. Click Show Schedules.

    Close, but no fares are shown here (figure 3-4). I guess I have to choose one of these three options, which probably all have different prices. I'll choose the first one and see what it costs.

    Figure 3-4. Your Departure and Return Options

  3. Pick the first radio button, scroll down, and click a button labeled "Show Fares."

    $156. Finally! Now let me see another one, for comparison.

  4. Click "Return to Train Availability."

    Now, back at "Your Departure and Return Options" (Figure 3-5), I'll pick the second train…

    Figure 3-5. Your Fare Information

  5. Click "Show Fares" again.

    $128. Not so bad.

  6. Click "Return to Train Availability" again.

    And now pick the third train…

  7. Click "Show Fares" again.

    Also $128.

Seven steps. Seven context switchesand eight page loadsfor something that I thought could be done in one step. Remarkable!

Figure 3-6 shows what this use case looks like using a UML sequence diagram hacked for use as a navigation diagram. Each vertical line represents a page, each arrow represents a jump, and each rectangle shows what page I'm on. As you follow the arrows down the page, the diagram shows how the interaction progresses over time.

Figure 3-6. Sequence diagram for the Amtrak scenario: four pages and seven jumps


How can we streamline this process down to one jump?

First, can we remove the extraneous "Schedules and Fares" page back at the beginning when we simply confirmed information we'd already typed in? Well, it turns out that that page asks the user for one more critical piece of information: the actual train stations in the source and destination cities. We could solve that problem with two new client-side dropdown lists that .ll in with default stations after the cities are typed. (The default train station often is what the user wants anyway.) Alternatively, we could do this on the second page. With that hand-wave, we're one jump gone, five to go.

The next improvementthe big oneis simply to show the fares on the same page as the rest of the train info. We can add a "Fares" column to the table, which eliminates the remaining five jumps! Figure 3-7 shows the much-simplified navigation.

Figure 3-7. Two pages, one jump





Designing Interfaces
Designing Interfaces: Patterns for Effective Interaction Design
ISBN: 0596008031
EAN: 2147483647
Year: 2005
Pages: 75

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net