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.
Page-Level Selection
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.
Section Tabs
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?
Finger 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.
