Using HTML Input Controls to Accurately Capture Users' Data

This chapter is from the book

Making the Web Work: Designing Effective Web Applications

Learn More Buy

This chapter is from the book

This chapter is from the book 

Making the Web Work: Designing Effective Web Applications

Learn More Buy

Common Interaction Problems and Solutions

Lest you conclude there's nothing more to forms than a series of independent, isolated input controls, this section focuses on common interaction problems requiring multiple input controls working together. These problems include the following interactions:

• Selecting a single item from a small, medium, or large number of options

• Selecting multiple items from a large set of options

• Selecting a date

Although it would be impossible to anticipate or explore every interaction problem, the analysis of these problems should give you an understanding of how to approach and solve complex interaction problems in general.

Picking a Single Item from a List

One of the most common input operations in a Web application requires the user to select a single option from a list. Depending on the situation, the user might need to select an item from a list of 2, 20, 200, or even 2,000 possible options. Regardless, the interaction requirement remains the same: an exclusive choice from an exhaustive list.

There are three basic solutions in these situations, depending on the number of options and whether the list of options is fixed or variable. The simplest solution relies on a group of radio buttons and is appropriate for a small, static number of options. The second solution, appropriate for a large set of options, uses a list box. The last solution uses a menu and is appropriate for situations somewhere in between.

Small Set of Choices

The least complex incarnation of the single-selection problem requires the user to select an item from a fixed small set of options, generally between two and seven. There are two reasonable solutions in this situation: a group of radio buttons or a menu.

Although many designers faced with this problem use menus in place of radio buttons, the advantage of visual efficiency that menus offer comes at the price of hidden options and usability concerns. Although this may be an acceptable tradeoff for seldom used features or very lengthy forms, as a general rule, options should not be hidden from users. Menus hide options; radio buttons don't. Call it a guideline, call it a rule, call it a suggestion: Whenever possible, use radio buttons instead of menus.

When the number of choices depends on the user's data or the application's state, however, this choice isn't possible. For example, a stock portfolio application typically allows users to create custom views of their portfolios, displaying the list of views as a menu in the main portfolio page. The menu is an appropriate solution in this case because it enables the page layout to remain consistent regardless of the number of views the user creates.

Online clothing stores are an instructive example of a design that uses menus when a group of radio buttons would be more appropriate. For most clothing articles, users have to indicate both a size and a color. This is typically handled as two independent selections and presented as two different menus. However, size and color are not independent selections. Rather, they are two distinct characteristics that combine to describe a single item. In addition, the number of options in either control is typically fewer than seven.

Figure 8.8 shows a typical solution that uses menus for selecting clothing size and color. Figure 8.9 shows an alternative design, with text links in place of the menus. Compared to the standard menu solution, the text link solution has these key advantages:

• Visibility of choices. The full set of choices is instantly visible without the user having to explore the contents of one or more menus.

• Reduced click count. The click count has been reduced by substituting a single link for the two menu choices and the Add to Cart button. An action that took three clicks—select size, select color, and add to cart—has been reduced to one.

• Simple mechanism for communicating unavailable size/ color combinations. This solution easily handles unavailable size/color combinations. By contrast, the menu required the user to first select the size/color combination before the interface reported whether it was available.

• Ease of use. As an interface control, text links are physically easier to operate than menus, so this solution is easier to use than a solution relying on menus.

Figure 8.8 To purchase an item, the user has to navigate both the size and color menus, optionally indicate a quantity and ship-to address, and click the Add to Cart button.

Figure 8.9 In this alternative design, size and color menus have been replaced with a two-dimensional matrix of links.

As is typically the case, however, this solution also comes with some clear disadvantages. Determining whether the following disadvantages are a reasonable tradeoff compared to the advantages is no simple question:

• Limited scalability. Although this solution works well in the illustrated situation, if the number of sizes or colors grew past seven, the size of the matrix would be so large that it would overwhelm the page.

• No clear Add to Cart action. The most suspicious part of this design is removing the Add to Cart button. Although the text link is a reasonable way to add an item, the interaction goes against convention and could easily confuse users.

• Difficult error recovery. By equating a link with the Add to Cart action, the solution does not have a simple method for users to review their selection before adding it to their Shopping Carts. This problem is compounded by the solution's inability to give users a way to recover from an incorrect selection, other than deleting the incorrect item from their Shopping Carts.

One way around these disadvantages would be to replace the text links with radio pictures, which would enable the Add to Cart button to be added, thus eliminating the two major problems. However, the visual weight of a radio picture would likely make the design even less scalable.

Other changes to the original design include eliminating the Quantity text box and placing the Ship To menu at the top of the shopping area. Because users rarely order multiple quantities of the exact same article of clothing—socks, T-shirts, and underwear being exceptions—the quantity option has been moved from the main product page to the Shopping Cart. In addition, because the Ship to option is less frequently used, it has been placed in a less visually prominent position.

Whether this solution represents a definitive, meaningful improvement over the original is a question best left to a usability study. Clearly the design represents a departure from convention—a move that should always be viewed with skepticism. In the perpetual search for improvement, however, examining the conventional solution in light of alternatives is always useful and often educational.

Medium or Unknown Number of Choices

With more choices—7 to 21, give or take—a different approach is required. The use of radio buttons is ruled out, thanks to the sheer number of options. The remaining options are a menu or a scrolling list box, although the former is suspect owing to its ever-present usability problems.

Still, menus do have their place, and Figure 8.10 is one of them. This page from The Motley Fool's portfolio tracker allows users to create a customized view of their portfolio. Instead of starting each new view from scratch, users can base a view on an existing one by selecting it from a menu.

Figure 8.10 The "Start From a View" option is an appropriate use of a menu because the control is not required and because the number of choices is variable but unlikely to be more than 20.

Three main factors justify the use of a menu in this situation:

• Unknown number of items. Depending on how many views the user has set up, the list could have 3 to 33+ different options. Because of this variability, radio buttons are inappropriate.

• Small to medium range of options. The number of options in the list, although variable, is unlikely to be more than 20. After all, how many different portfolio views is one user likely to create? With a range of 2 to 20, the number of options is reasonably manageable with a menu.

• The control is optional. Users don't have to select an existing view as a starting point. Therefore, the control doesn't warrant the visual weight and prominence of a scrolling list box.

In situations calling for the user to select a single item from a medium or an unknown number of choices, the challenge is ultimately one of balance. Although a menu or scrolling list box can be used, the optimal solution is the one that best allocates screen real estate given the situation.

Large Number of Choices

A third type of design challenge involves selecting a single item from a large list. What constitutes "large" is open to interpretation, but generally speaking, it's a number north of 21. In these cases, radio buttons and menus are ruled out by the volume of options. This leaves scrolling list boxes as the only viable alternative.

An educational point is found on almost every address entry form on the Web. The conventional design for address forms incorrectly uses a menu as the input control for U.S. states and Canadian provinces. The solution requires the user to navigate a menu of 50+ items, even though the same input could be captured with a scrolling list box (see Figure 8.11). Granted, the list box requires more screen real estate, but that cost is outweighed by the usability benefits of revealing all the options and providing an easier-to-use control.

Figure 8.11 This figure illustrates the use of a scrolling list box as the input control for U.S. states and Canadian provinces.

The use of a scrolling list box has been extended in Figure 8.12 to demonstrate how the contents of an especially long set of choices can be filtered by using an additional control. In this example, the standard list of U.S. states and Canadian provinces has been divided into two smaller groups. This style of interaction works well when the list can be filtered in two to four different ways. With a larger set of filter choices, a menu can be substituted for the radio buttons.

Figure 8.12 This example shows how radio buttons can be used as a filtering mechanism for a long list of choices.

When users are required to select a single item from an exhaustive list of options, there are two key considerations: the number of options and whether the number of options varies. Although radio buttons, menus, and scrolling list boxes are all acceptable solutions, the ultimate challenge is to find a balance between the need to make all the options visible, the ease of use of the input controls, and the visual weight of the different interface elements.

Picking Multiple Items from a List

A second common interaction problem is the ever-present "picking multiple items from an exhaustive list." Although multiple selection and single selection pose similar design challenges, the two are far from identical. In both cases, the elements supporting the interaction have to indicate the list of options as well as the current selection. For single–select controls, such as menus and list boxes, one interface element serves to simultaneously indicate the selection and the available options. With multiple selections, however, the interface has to communicate a selection involving any combination of options and, as a result, a different set of interaction mechanisms is required.

In situations calling for a relatively small number of choices, the issues parallel single-selection problems. Check boxes are substituted for radio buttons, and everybody moves on. As you might expect, however, that simplicity evaporates if the number of choices is variable or expands much beyond seven choices.

One potential solution for multiple selections is a scrolling list box in multiple-select mode. In this mode, users select multiple items by holding down a modifier key while simultaneously clicking items in the list. Unfortunately, multi-select list boxes have a host of usability and feedback problems, not the least of which is that many users don't even realize they exist.

An alternative solution uses two single-select list boxes working in concert with two or more command buttons. In this solution, one control contains the possible options, and the other contains the currently selected items. In addition, a group of command buttons is used to move items back and forth between the lists. Figure 8.13 from Evite shows a good example of this solution.

Figure 8.13 Evite's address book supports selecting multiple items through the use of a list box containing possible options and another containing the selected items. Items are moved between the lists by clicking a command button.

Harkening back to the days of Macintosh O/S 1.0, this motif is sometimes called "font/DA mover" or, in the more modern vernacular, "source/target list." Although this solution requires JavaScript, it is almost always the preferred alternative, certainly warranting the extra code and effort.

A redesign of the Edit View form from Yahoo!'s portfolio tracker illustrates how source/target lists can clean up a complicated multiple-selection problem. Figure 8.14 from Yahoo! is used to customize users' views of their stock portfolio. In this implementation, the user can customize up to 16 columns, each containing one of 76 different options.

Figure 8.14 Yahoo! portfolio tracker allows users to customize the view of their portfolio. The design relies on 16 menus, each containing 76 elements.

The most conspicuous problem with this design is the use of a menu containing 76 items—a poor showing in the usability race when there's only one such menu, much less 16 of them.

Aside from their function as selection mechanisms, the menus are also used to control the order of the columns. Unfortunately, although the menus are stacked vertically, the top-to-bottom ordering is translated to a left-to-right ordering when the view is being used. In addition to the oddity of this vertical to horizontal mapping, the use of menus as an ordering mechanism has another problem. Because the design doesn't provide a way to insert a column, users are required to change multiple menus if they want to place a data element between two existing elements. For example, if a user wanted to insert a new data element in column 2 but wanted to retain the order of the next 12 columns, he or she would have to reselect the elements for columns 2 through 13—a tedious task, even without 76 elements in each menu.

Finally, because there is no interactivity between the menus, this design does nothing to prevent users from displaying the same data element in more than one column.

On the positive side, the page includes a categorized list of all 76 possible data elements. By including this reference, the design mitigates some of the problems created by hiding the options.

Working backward from the implemented design, you can infer the following requirements:

• Limit the number of columns to 16.

• Do not use JavaScript or DHTML.

• Any element can appear in any column.

• Data elements can be custom sorted.

With these requirements in hand, there are a few alternatives worth exploring.

Option 1: Check Boxes

As shown in Figure 8.15, one alternative is to replace the menus with check boxes. Although this approach doesn't satisfy all the requirements, it does have some important advantages—as well as disadvantages—to consider:

Advantages

• Obvious presentation of available choices

• Simple selection interaction

• Prevents users from adding the same data element twice

Disadvantages

• No ready mechanism for limiting the selection to 16 data elements, thus requiring an error notification if more than 16 elements are selected

• No support for column ordering

Although the first disadvantage could be handled through an error alert, addressing the second would necessitate a reconsideration of the requirements.

Figure 8.15 This redesign of Yahoo!'s Edit View page does not support customizing the order of the columns, but it simplifies the interaction in the original design.

Because the data elements can be grouped together in a meaningful way, the lack of support for column ordering might not be an issue. The nature of the data elements is such that determining a prescribed order that addresses most user's needs is possible. Ultimately, the questions rests on whether column ordering is essential to the primary persona and, if so, at what cost?

Option 2: Source/Target List

A second alternative, relying on a source/target list, is shown in Figure 8.16. This option includes a source list containing the full complement of data elements and a target list containing the elements currently selected. This design also includes buttons for moving items in and out of the selection and for reordering the selected items. The combination of two list boxes and four buttons provides all the functionality of the original design but without the complexity of 16 menus.

Figure 8.16 This design simplifies the interaction by reducing the number of input controls needed. It also enables users to reorder data elements easily.

Compared to the other alternatives, this solution has the following advantages and disadvantages:

Advantages

• Clear communication of the current selection

• Easy reordering of selected items

• Simplified interaction using fewer input controls

• Visually compact and approachable

• Depending on the preferred use, elements can or cannot be added more than once

Disadvantages

• No obvious way to limit the selection to 16 items

• The scrolling list cannot display all options in a single glance

• Requires JavaScript

A variation of this design could integrate a menu as a filtering mechanism for the source list box. This would limit the number of items displayed in the list at any given time and help users locate specific items quickly.

Like the check box alternative, because this design requires JavaScript, it does not fully satisfy all the requirements. However, the improvement in the user experience is again enough to question the requirement.

As these examples show, designing an interface that allows users to select multiple items is no trivial matter. The unique environment of Web applications requires creative use of multiple input controls and a thorough understanding of the product's requirements and target users.

Selecting Dates

The selection of dates, a problem found in many Web applications, is another complex interaction problem worth exploring. Because HTML doesn't provide any input controls specifically designed to select dates, Web applications are left to use the standard set of input controls to accomplish this rather complex task. Unfortunately, the Web's lack of interface standards is nowhere more apparent than in this particular problem. The following sections analyze the most common solutions to this problem with attention to the unique pros and cons of each.

Interface Requirements for Date Input

Not surprisingly, the purpose of a date input control is to enable users to specify a date—that is, the combination of a month, a day, and a year. In a desktop application, this is typically accomplished with a simple text box or some sort of custom UI widget. In both cases, the application has special logic allowing it to instantly recognize and report invalid dates.

With those controls as a baseline, it is reasonable to assume the following requirements for a proper date input control:

• Provide context. Where appropriate, the input control should place a date in context. A travel itinerary or future appointment should be displayed in the context of a calendar, for example, but a user's birth date or credit card expiration should not.

• Prevent errors. The input control should prevent users from selecting an invalid, a nonexistent, or an incorrect date.

• Be efficient. The input control should be quick, efficient, and simple to operate.

Although Web applications are a different medium from desktop applications, these basic requirements remain the same.

Text Boxes

As shown in Figures 8.17 and 8.18, the option at the low end of the sophistication scale relies on a single text box or a group of text boxes for date input.

Figure 8.17 Although a single text box is a simple approach, it fails to offer any context or do anything to reduce errors.

Figure 8.18 Although a group of text boxes does not address all the shortcomings of the single text box, at least it removes the question of the correct order for the three pieces of data.

Regardless of whether the design uses one text box or three, this approach fails to meet any of the requirements. Although the single text box solution offers an example of the correct date format, nothing in the interface forces the user to follow it. By contrast, the solution with multiple text boxes more clearly communicates and enforces the required format. From a technical perspective, a solution using only text boxes represents the least amount of effort, but the obvious usability shortcomings generally make it a poor choice.

Group of Menus

The most common interface for selecting dates relies on a series of menus, one each for the month, the day, and the year (see Figure 8.19). Despite the popularity of this design, however, it is not without substantial usability issues.

Figure 8.19 Despite its widespread use, this solution fails to provide context or prevent input errors.

As an improvement on the text box approach, menus help reduce some input errors by ensuring the following:

• Values are entered in a controlled manner.

• The application clearly knows which input value represents the month, day, and year.

• The month, day, and year values are limited to an appropriate range.

Although the design could support logic dependencies between the day and month menus—for example, limiting the options for day based on the selected month to prevent the user from selecting February 30—these dependencies have their own host of usability concerns and engineering complexities. As a result, most applications that use this motif rely on server-side validation to confirm whether the indicated date is valid. Although this approach helps limit input errors, it does not completely eliminate them.

Another concern is the failure of this solution to provide context for the date. By simply reflecting a disembodied date with no reference to a monthly or weekly calendar, the solution doesn't communicate the date's relationship to past or future time. In some cases, this relationship is not important—credit card expiration dates, for example—but in others, such as travel itineraries, it's critical for the user to quickly understand that the 15th is next Tuesday.

Two factors account for this solution's popularity: conservation of screen space and technical expediency. In some situations, these advantages clearly outweigh any of the disadvantages; in others, however, a more sophisticated solution is necessary.

Calendars

Another solution for handling date input relies on a calendar as the primary interface element. Although it's no great intellectual leap to conclude that calendars offer an easy-to-use input control, many applications don't use them because of the additional technical overhead. Of the solutions described so far, however, the calendar is the only one to satisfy the two fundamental requirements: context and error prevention.

Unfortunately, providing calendar-style input is no simple engineering task in an HTML environment. Although it is possible to create a calendar with nothing but standard HTML, changing the calendar's displayed time frame typically requires a trip to the server and page regeneration. For multiple date entries—travel reservations, for example—this behavior renders calendars disruptive and unwieldy. For a single date input, however, a fully HTML-based calendar, such as the one Evite uses (see Figure 8.20), can be a useful approach.

Figure 8.20 This page from Evite uses a calendar built with HTML. Clicking a date creates a new invitation for the indicated date.

Instead of placing the calendar directly in the layout, another common solution is displaying the calendar in a secondary browser window. Figure 8.21 from JetBlue exemplifies this approach. From the flight search page, the user can click the calendar icon, opening the calendar in a new window. When the user clicks a date, the calendar window closes and main page is updated to reflect the selected date.

Figure 8.21 The flight search page includes typical menus as well as a calendar option.

Of the options discussed so far, this is the only one that satisfies the requirements for providing context and preventing errors. Unfortunately, it also compromises this functionality by introducing a secondary window and thereby violating the basic page model of the Web.

Another solution worth consideration also relies on a calendar motif, but instead of opening the calendar in a secondary window, it is integrated directly into the form. As shown in Figure 8.22, the Broadmoor Hotel's reservation page includes two one-month calendars as well as links for changing the month being displayed. When the user selects a date, its color changes to white. In addition, after two dates have been indicated, the dates falling between the two are also highlighted, giving the user a clear, obvious way of viewing the date range of his or her stay.

Figure 8.22 The Broadmoor's reservation form uses two monthly calendars appropriately integrated into the reservation form.

Although this implementation requires additional engineering effort and image production, it is clearly a superior design from a user's perspective. It not only satisfies the requirements for providing context and preventing errors, but it does so without introducing usability problems.

Owing to the transaction orientation of many Web applications, selecting and entering dates are common interactions. Unfortunately, the requirements for an ideal date interface dictate significant design and engineering efforts. The results of this effort, however, are more control for the user and fewer errors—two benefits worthy of substantial effort.