Visible Navigation

Making the translation from a task to a set of features can be simple, especially if there is a direct mapping from the task to a single window and the path to that window is obvious. The translation is most difficult when the user is required to navigate through a series of windows, especially when the path between the windows isn't obvious. In this section, I will focus on the problems of navigation and show how to make navigation visible. Visible navigation is an essential requirement for creating visible tasks.

Wilderness Training

How do you make a task easy to navigate? Well, what do you need to navigate easily in the real world? To navigate in the real world, you need an easily identifiable starting point, a clearly understood destination, and a clearly marked path from the starting point to the destination. At any point in time, you need to have an idea of where you are, how to go forward, and how to go backward.

In wilderness training, you are taught how to identify landmarks and find your way using a map and compass. Interestingly, the ability to go backward is given almost as much attention as going forward. You are taught to periodically turn around so that you can recognize where you came from and how to get back to where you started. You would clearly prefer to get to your destination instead of your starting point, but if you can always get back to your starting point you can then determine what you did wrong and either try again or give up. The inability to move forward to your destination or return back to your starting point is known as being lost.

Navigation Essentials

Since the typical user hasn't had wilderness training, your user interface needs to guide the user through the task. Here are the essentials to visible navigation:

• A starting point Provide a clearly marked starting point so that the user can readily determine how to begin the task. A menu command is often the best starting point because the menu text combined with the command's context within the menu help the user understand the command. Toolbar buttons and keyboard shortcuts work well as alternative shortcuts to the starting point. Make sure the starting point is in the program itself and not within some other program. If the task is performed by another program, use the menu command to make the link; otherwise, the user will never find it.
• A destination Make it easy for the user to predict which starting point will lead to the desired destination. This is accomplished by using natural mapping, which I will describe in detail later in this chapter.
• An escape route Provide a clearly marked exit command in case the user changes his mind or wants to start over. This is usually accomplished with a Cancel button or through direct access to the starting point, as with a Home button.
• The current step Provide a clear indication of where in the process of the task the user is, especially when multiple windows or multiple steps appear within a window. This is usually accomplished with a descriptive window caption. In a multistep process, adding text like (Step 1 of 7) also helps.
• The next step Make it clear to the user how to get to the next step. This is usually accomplished by providing the user appropriate options and commands. Make sure that the command buttons are descriptively labeled so that the user can accurately predict what clicking a button will do. Also make sure that the labels clearly differentiate the available choices so that the user can select the right option. Often, adding an extra word or two makes a big difference.
• The previous step Make it easy for the user to get back to the previous step. This is usually accomplished with a Cancel button in modal dialog boxes or a Back button in wizards.

In short, at any time the user should know where he is, where he has been, and where he is going.

What to Do

You need to help the user navigate within a window and between windows. Let's now look at some specific ways to make navigation visible.

Identify the steps within a window

You need to make navigation clear within a single window. This is typically accomplished by arranging the controls in logical groups and displaying the groups in a logical order, usually from top to bottom. One effective technique to make the steps in a task clear is simply to number them and describe them within the window. Don't rely on Help to sort things out. This example from Microsoft FrontPage makes it clear that creating a new FrontPage Web requires two steps and what those steps are:

The numbers used in this example are quite large, and it's possible that they might distract the user from the instructions. Smaller numbers will do just fine.

Use a single window whenever possible

When possible, the easiest solution is to let the user perform a task using a single window. You can combine related windows into a property sheet or a dynamic dialog box, such as with this Page Setup common dialog box in Windows:

Putting everything the user needs to perform the task in a single window is a technique commonly used in Web pages. Web browsers also have a highly visible navigation model. I'll discuss this subject in more detail in Chapter 13, "Learn from the Web"

Use wizards

Wizards are ideal for complex tasks because they guide the user through the task and allow the user to focus on one step at a time. Wizards have all the elements required for visible navigation: they clearly identify the starting point, ending point (with the Finish button), escape route (with the Cancel button), next step (with the Next button), and the previous step (with the Back button). Some problems with wizards are that they require too much effort for commonly used tasks and they are modal so the user can do only one task at a time.

Use modal dialog boxes

Cascading dialog boxes, while inelegant, can provide visible navigation. Although you want to avoid performing a task with a big pile of modal dialog boxes, they can be effective when there are only a few of them. Again, a problem with using modal dialog boxes is that the user can do only one task at a time.

What to Avoid

Now let's look at some examples of what to avoid.

Don't use unrelated windows

The most invisible form of navigation is when the user has to access several unrelated windows to perform a task. These windows might be accessed from different menu commands or, worse yet, from different programs. In this case, the user simply has no clue what the steps are or even where to start. For example, suppose you want to use the Find utility to look for a system file, such as Commctrl.dll. If you can't find the file, you might be tempted to change an option by using the Options menu.

Unfortunately, the only option you have is for a case-sensitive search. To search for system or hidden files, you have to use the View tab of Windows Explorer's Folder Options property sheet.

In this case, the starting point isn't obvious. Navigation doesn't get any more invisible than this. Note, however, that there is some logic behind this technique. The Folder Options property sheet sets the folder options for the entire Windows system, and the Find utility is regarded as part of the system. But how many users know this? Clearly, the Find utility would be easier to use if you could change its options directly from its Options menu.

TIP

---

The most invisible form of navigation is when the user has to access several unrelated windows to perform a task. Try to make the connection between such windows visible.

Don't cross paths

Another common navigation problem: two tasks that have similar steps cross paths, making it difficult for the user to figure out what the next step is and how to get the paths uncrossed. For example, suppose you have two different tasks that share their first three steps. You could combine the starting point for both tasks and have the user determine which task to pursue at the fourth step. Although this technique requires you to write less code, it's very confusing. There isn't a clear relationship between what the user wants to do and the mechanism for doing it. Furthermore, the user is unable to predict what is going to happen in the initial steps. How is the user supposed to know that he will be able to choose what he really wants to do in the fourth step? A far more visible navigation technique is to offer two independent paths right from the start.

My favorite example of a crossed path is the Add/Remove Programs Control Panel applet:

Can you predict what clicking the Add/Remove command button will do? If you didn't read the instructions carefully, you might predict that clicking the button will uninstall the selected program. But that is only partially true since clicking this button also allows you to add or remove components to an installed program. Consider the navigational hurdles a user has to leap over to add a component to a program. First the user has to know that the way to add a component isn't through the program or the setup program but from the Add/Remove Programs Control Panel applet. The user then has to understand that even though he doesn't want to either add or remove a program, the way to install a component is by clicking the Add/Remove button. Even expert Windows users have trouble with navigation like this.

There's nothing wrong with using the Add/Remove Programs Control Panel applet to add components. What's missing is visible navigation. There needs to be a link to this applet from the Help menu of a component-based program as well as a link from the setup program. There then needs to be two separate, well-labeled buttons: one that says Add or Remove Program Components… and another that says Add or Remove Program….