Use Split Windows for Navigation as Well as for Lists

The left-hand list can be a navigation device as well as a set of items. For example, the tree in Figure 4-2 shows various parts of a database management system, from “Connection” information to “Management,” “Security,” “Tools,” and “Preferences.” Users can move through the system by opening and closing the branches of the tree and clicking items. Once they find what they want, then they can turn their attention to the object area.

In this example, “Tables” is selected on the left and the tables in the system are listed at the right in the object (or detail) area. Users can click the buttons in the rows to change the tables. So if a user clicks the “Structure” button on the “Account” table, the structure definition frame replaces the “Tables” list (Figure 4-3).

Consider Heterogeneous Windows

The hybrid list+object windows described earlier are perfect for power users such as system administrators or database managers. These users like to have everything in one place, even when the various items are very different. For example, being able to run a wizard (Figure 4-4) from the same window as they use to restructure databases would probably not disconcert them.

However, keep in mind that they can be difficult for casual or inexperienced users to understand or get used to. Check users’ workflows and test for usability before you try heterogeneous windows. They may seem too messy for some people; the wrong activities may be bundled together; and functionality may be too hidden.

Use Lists for Parts of an Object

The left-hand list can be all navigation, listing parts of one complex object rather than many different objects. For example, in Figure 4-5, the tree on the left shows sections of a single mortgage application, from the basic applicant information and the good-faith estimates to the Fannie Mae report.

Note that this is a different sort of list+object strategy than the ones described above, since the entire window is one object. The list of all objects would be managed on a different window.

Consider Using Pictures

Some data-input jobs entail setting up pieces of equipment—for example, entering the IP addresses and other local characteristics of a server.

When the user is working with physical equipment, consider using a photo or schematic of that piece of equipment instead of a text list (Figure 4-6).

Note that graphs, diagrams, and geographic maps are actually lists, but they show the objects as icons or shapes rather than as rows of text. Visualization is a very powerful tool in troubleshooting, analysis, and decisionmaking situations—for more information, see the chapters on graphs, diagrams, and maps later in this book.

Potential Problems with the List-Object Strategy

Besides being confusing to some users, splitting the browser window into list and object can bring up other issues.

There are no clear solutions to these three and other, as-yet-unidentified, problems. However, the first might be resolved by letting users turn the object frame on and off—in other words, if the users need to find a particular record or set of records, they toggle the object area off and show the list with an extended set of search or filter fields.

A solution to the second might be to transform the whole window into a more graphical representation. For example, if the tree contains equipment, with parts inside parts inside parts, consider switching to a picture or schematic of the piece of equipment. The relationships would become concrete wide Dreamweaver). rather than abstract. Although the visual version might not be as compact as the text version, it would probably be easier to understand. Again, you might provide a toggle between the tree and graphic versions.

A solution to the third might be a “visual pivot,” as described by Robertson, et al. (2002, pp. 423–430). In this experimental strategy, the user picks a item of interest and then pivots or turns from one database to another via a metadirectory. The metadirectory provides a common interface to all of the relevant databases and the interface provides a visual metaphor (an animation) for the intellectual movement from one direction to another. See Figure 4-8 for one shot from the animation.

How to Select the Right List-Object Strategy

With all these options, how do you know which strategy to use? Here are some guidelines:

Be sure, however, to test your ideas with users before committing to one strategy over another. In fact, consider providing different strategies for the same window for different audiences: simple, separate list and object windows for occasional or nontechnical users and a tree hierarchy mixing data, settings windows, and applications for power users. The key is to pick the type of list that makes the most sense to the people who are going to use your system.

Selecting Multiple Rows

As well as providing a way to select heterogeneous rows, checkboxes let users act on a set of records as a group-for example, delete them, assign them to someone, change their statuses, or set them aside (flag them) to work on later. In Figure 4-9, for example, you can select the entire list by clicking the topmost checkbox and then click Delete, Block, Mark as Unread, or Put in Folder … to act on all the rows at once. (Note that you can have a column of radio buttons, too, but they restrict users to one selection per list.)

Another reason to have multiselect checkboxes is to manage network traffic better. Experienced web application designers say that it’s too time-consuming and uses too many network resources to update web-based records one by one. Instead, they recommend a three-step process.

You can design the system so that users will be able to post changes in batch without selecting individual rows. However, if they don’t mark the ones they’ve changed, the system has to compare each record on the list to its original in the database to see if there were any changes. This is very inefficient from a systems point of view. It is not more efficient from a user’s point of view, however, who is likely to complain about being forced to mark each record he or she wants to change. If you want to use this type of design, consider automatically turning on checkboxes for all of the records that the users touch and letting them turn off the ones they decide they don’t want to change after all.

To decide on the right answers, you will have to check the users’ workflows.

• You don’t “go” anywhere—you stay on the home window and dip in and out of individual records as you need to.

• You can build validation into the popups and dropdowns and handle most of the error checking in small, easily digested bites.

• Using a list lets you change one or two fields in many records at the same time. For example, say you want to assign a dozen sales leads to one sales representative. You check off all the records you want to go to that representative, select his or her name from a dropdown list or other control above the list, and then click “Assign.” Poof, all done.

How to Show Actions

To show actions, use buttons, dropdown lists, toolbar equivalents, and tabs.

Also consider these issues.

Where to Put the Actions

Put actions affecting multiple rows—in Figure 4-13, “Remove,” “Show Paths,” and so on—above the list.

Embed actions in the rows when the actions can be taken only, or primarily, on the individual rows—see the “Actions” column in Figure 4-14, for example.

Put tools in the cells themselves whenever possible—see Figure 4-15.

Put window-level buttons (like Save and Continue) on the top and the bottom of the window. People often drop to the bottom of a window, even if the same buttons are visible at the top, out of habit—buttons in most desktop applications appear at the bottom.

Use Popups for Secondary Data

One of the problems with changing data directly on a list is that users can’t always tell whether they’ve changed the entire record or only some small part of it or—perhaps more importantly—whether they’ve canceled all changes to the record or only to a piece of it.

You can clarify matters by popping up a box whenever users ask to change information (Figure 4-16). This box has the traditional Save (or OK) and Cancel operations. When the user closes it, the changes should appear in the original row (perhaps by marking the row as changed), thereby providing both good feedback and a clear interaction.