Published: February 20, 2007
In a previous Communication Design column, “Refining Data Tables,” I alluded to the importance of Web forms in online commerce, communities, and creation. As arbitrators of checkout, registration, and data entry, forms are often the linchpins of successful Web applications.
But successful Web applications tend to grow—both in terms of capability and complexity. And this increasing complexity is often passed on to and absorbed by a Web application’s forms. In addition to needing more input fields, labels, and Help text, forms with a growing number of options may also require selection-dependent inputs.
Selection-dependent inputs are, in essence, a pretty simple concept: Once a user initially makes a selection from one or more options in a form, the user must provide additional input related to the selected option before submitting the form. Figure 1 illustrates this behavior by showing two steps from the eBay Create a Download Request form. After an eBay seller selects the Sold option in the Listings and records drop-down list, the form presents additional input fields for selecting a date range. Were the user to select a different option in the Listings and records list, completing the form would require a different set of additional options.
Figure 1—An example of selection-dependent inputs
It’s worth pointing out that, in most cases, users cannot submit a form with selection-dependent inputs until they fill in the additional fields. In other words, selection-dependent inputs introduce additional requirements to forms.
While selection-dependent inputs may seem like a basic user interface design problem, the myriad solutions to this problem on the Web indicate there’s more to this interaction than one might initially assume. The problem becomes particularly interesting when a form requires many additional inputs of varying types once a user makes a simple initial selection.
To illustrate just how interesting, here are a number of user interface design solutions for the selection-dependent input problem that I’ve seen work—and not work. Of course, I encourage others to share their unique approaches to tackling this issue.
Perhaps the simplest way to address selection-dependent input within a form is to divide the process into two clearly defined steps. On the Web, this most often translates to two separate pages. The first page—or step in the process—shown in Figure 2 presents users with an initial set of options. Once they select one of the options, the appropriate set of selection-dependent inputs replaces their initial selection.
While the relationship between their initial selection and the dependent inputs is clear to most users, the two-step model removes valuable context once users make an initial selection and is likely to be slower than inline solutions. As a result, page-level selection is often not a viable option.
Figure 2—Page-level selection
To avoid additional pages within key workflows, designers have explored several inline approaches to exposing selection-dependent inputs. In one approach, section tabs arrayed across the top of a panel, as shown in Figure 3, let users navigate to a section of the form that contains selection-dependent inputs. The tabs present not only the initial set of options, but also provide a strong indicator of the current selection.
While most users are familiar with the concept of navigation tabs on the Web, the manner in which they fill in Web forms frequently impairs the effectiveness of the section tabs approach. When completing a form, many users move from top to bottom and, as a result, often ignore horizontal options. There is also a lack of clarity about whether section tabs are mutually exclusive. Will I submit my selections on all three tabs with the form—or only the selections I made on the active tab?
Figure 3—Section tabs
To compensate for the lack of visibility of left-to-right section tabs within Web forms, using top-to-bottom finger tabs can better align with common patterns of form usage. When users move from top to bottom through a form, vertically stacked finger tabs, as seen in Figure 4, are consistently more noticeable.
To address the mutual exclusivity question inherent in the use of both section and finger tabs, you can include radio buttons to the left of the finger-tab labels to clearly communicate that they are mutually exclusive options.
Figure 4—Finger tabs
Both the section and finger tab methods maintain a unique interface element—in this case, a tab—for each initial option. This keeps all the initial options visible, but requires considerable screen real estate to do so. When the number of initial options grows, these methods tend not to scale very well.
The section selector method shown in Figure 5 utilizes a drop-down list and group box to confine all selection-dependent inputs to a specific area of the form. Though this method obscures most of the initial options—as only one option is visible in the drop-down list at a time—using a single control better communicates the scope and impact of the initial selection.
Figure 5—Section selectors
Expose Below Radio Buttons
Another inline method of selection-dependent inputs involves vertically separating the user’s initial options from any exposed additional inputs. This approach, shown in Figure 6, has the advantage of always keeping all the initial options—and a user’s selection among those options—visible. However, in usability testing, I’ve seen considerable confusion about the relationship between the initial selection and additional inputs.
Since, by default, one of the initial options is selected, it is not immediately clear that a dependency exists between the two sections. Also, the jumping effect that occurs when users change their selections and the screen updates to show a revised set of additional inputs can disorientate users.
A strong visual indication of the dependency between the initial selection and its additional inputs can help communicate their relationship more clearly, but isn’t likely to resolve all of the issues with this approach.
Figure 6—Expose dependent inputs below, following an initial selection
Expose Within Radio Buttons
Similar to the expose below approach, the expose within method reveals additional inputs within a set of initial options, as shown in Figure 7. When the set of additional inputs is quite small—one to two additional inputs—this method can maintain the context of a user’s initial selection while introducing the required selection-dependent inputs where they are most relevant.
If the number of selection-dependent inputs is substantial, however, this method breaks down quickly. The combination of page jumping and the movement of the initial set of options—as the elements between them are revealed and hidden—makes for a disorientating interaction that frequently has users questioning which user interface element triggers which set of options.
Figure 7—Expose dependent inputs within, following an initial selection
To address the disorientation caused by movement of the initial options when a user selects a different option—because of the page jumping that results from revealing and hiding selection-dependent inputs—the exposed, but inactive method shown in Figure 8 keeps all additional inputs visible, but makes only one set of options available. The other selection-dependent inputs are unavailable and most commonly appear dimmed, or grayed out.
While this method keeps all additional inputs visible and within the context of an initial selection, the sheer volume of inputs that are visible can quickly overwhelm users. Also, when there are many additional inputs for each initial option, the association between the user’s selection and the other initial options can get lost. Adding to this effect is the fact that the visible difference between inactive and active elements is frequently too subtle.
Figure 8—Expose inactive dependent inputs
To compensate for the disassociation between the set of initial options in the exposed inactive method, Figure 9 uses visual groupings to bound each set of selection-dependent inputs beneath an initial selection.
In this method, however, the visual weight of the many additional inputs can quickly reduce the visibility of the initial set of options.
Figure 9—Expose dependent inputs in groups
Each of the aforementioned solutions for selection-dependent inputs within Web forms has both advantages and disadvantages. As with all design decisions, it’s best to consider which solution is right within the context of the problem being addressed. If you’ve found success tackling the issue of selection-dependent inputs in other ways, let me know!