Fashionable Web Forms: Traps and Tips

Sliders

The standard set of form controls—text boxes, radio buttons, check boxes, and drop-down list boxes—has served us well for many years. However, recently a new form widget has surged in popularity: the slider. I say new even though, in the physical world, slider controls have been around for many decades, on everything from air conditioning units to graphic equalizers.

In the physical world, sliders are similar to knobs: they enable selection along a continuous range. For something fine grained, like adjusting the amount of treble or bass on a sound system, this is an appropriate control. But most sliders on the Web don’t offer such graduated settings. Instead they just provide an alternative way of choosing from among a limited set of predefined options.

Figure 6 shows an example of just such a case. A user must choose one of eight different amounts. Giving these options in a list box would make this user interface more usable and accessible.

When users must choose among a relatively small set of predefined options, the use of a list box is preferable for the following reasons:

• The control itself communicates to users that they can select just one option from a predefined set, whereas a slider suggests a continuum of options.
• Users can manipulate list boxes using either the keyboard or the mouse, whereas sliders usually require mouse manipulation.
• Users are more familiar with list boxes and know how to operate them.
• List boxes are highly accessible.

Interestingly, Australia’s number one job site SEEK tested the use of a slider in place of a pair of list boxes. The SEEK home page primarily facilitates users’ searching for a job, including setting their desired salary range, as shown in Figure 7.

In a typical A/B test, SEEK presented this page to 24,000 visitors with either a salary slider, shown in Figure 8, or salary-range list boxes, as shown in Figure 9.

SEEK found that the conversion rate for users of the slider was 8% lower than for users of the list boxes. That is, fewer users included salary range as a criterion of their search when the mechanism for doing so was a slider when compared to a pair of list boxes.

Anecdotal evidence suggests this may be because the slider is a relatively new and unfamiliar form control. When visitors come to the SEEK home page, more often than not, they are looking to quickly get to a list of jobs that meet their criteria. They may see a novel widget like a slider as a barrier to achieving this goal. Consequently, SEEK has decided to use the pair of list boxes rather than the slider for salary-range selection on their home page.

It is worth noting, however, that SEEK has decided to use a slider on the panel that lets users refine their search results, as shown in Figure 10. Here the thinking was that the unconventional control might help draw attention to the relatively new refinement capability.

Sites often use sliders to offer users a fine-grained continuum of options when a small set of predefined options would suit their needs perfectly well. For example, the slider shown in Figure 11 moves in $10 increments, enabling users to select a maximum cost per night somewhere between $0 and $1,000 when searching for accommodations. But do users really need to be able to differentiate between $740 per night and $750 per night? Surely a few values would be sufficient, in which case a series of check boxes showing these would be a better solution. (For the reasons why check boxes rather than list boxes would be best, see Greg Nudelman’s column “Numeric Filters.”)

Sliders aren’t all bad, though. In some cases, they can really enhance a user experience. For example, the slider shown in Figure 12 lets users indicate the value of their car for insurance purposes. A user can leave the slider where it is when the page loads; this is the market value. Alternatively, a user can adjust the slider within some predefined range, indicating what they consider their car’s replacement value to be. As soon as the slider stops at a value, the premium adjusts accordingly.

The slider in Figure 12 works nicely for a number of reasons, as follows:

• In this case, it is important to communicate the end points of the range from which a user can choose a value, so the visual representation of a slider is highly appropriate.
• There is a continuum of fine-grained options a user can select.
• The slider lets a user easily and immediately see the impact of selecting different values on the premium.
• If users know the exact value for which they want to insure their car, they can type it into the text box at the middle of the slider control.
• The slider introduces a somewhat interesting interaction at the end of a fairly boring form—boring by necessity. This is insurance after all.

Hidden Contextual Help

Contextual Help provides just-in-time, supplementary information within a form. An example would be a tip about acceptable password formats beneath a Password text box.

You don’t have to look far on the Web to find forms that hide contextual Help behind some sort of icon, like a question mark, as in Figure 13. Like red asterisks for mandatory fields, this has almost become a de facto standard.

But if contextual Help exists to help users fill out a form correctly and with confidence, why hide it? Presenting Help directly on a form page means it is there for users, whenever they need it, without clicking or hovering. Plus, you can style Help so it has less visual prominence than other form elements. The testing I’ve done with users suggest they do not get distracted by such Help, but find it when they look for it. Figure 14 shows an example of such contextual Help.

Hiding contextual Help behind an icon means users are much more likely to miss it—especially, but not only, users who are using a keyboard or assistive technologies. Not seeing or having access to Help increases the occurrence of validation errors and results in greater user dissatisfaction.

Using icons to provide a pathway to contextual Help also means users must stop what they are doing and click a Help icon to even see what the content behind it is about. The need to take this separate, flow-breaking step may result in disappointment if the Help content doesn’t meet their expectations or needs.

However, if you must use an icon to indicate the availability of contextual Help, it is best to stick with the established convention of a question mark. Styling your Help icon to match your branding or theme might be cute, as in Figure 15, but it doesn’t provide much information scent.

Another approach to the presentation of contextual Help is having it appear only when users select an insertion point in a field, as shown in Figure 16. The animation this approach uses is good for drawing the attention of sighted users’ to Help they might otherwise have missed, because humans are very sensitive to movement within our visual field.

However, this kind of animation could well become annoying on a long form. But whatever a form’s length, there are some other disadvantages to this Help display technique that are also worth considering:

• Users don’t know Help even exists until they navigate to a field, by which time they may have already gone through the process of formulating their answer and, thus, may need to do some mental rework.
• When a field is something other than a text box—like radio buttons—users may not get the Help they need until after answering.
• You need to be very careful about where the Help appears to avoid covering up the related field, the following question, or other key components of the screen.
• The Help may not be accessible to assistive technologies.

One reason you might want to hide contextual Help is if only a small minority of users would need it. Everyone would need the password tip I mentioned earlier, but clarification about why a form is asking a certain question might be of interest to only a small number of users—for example, those who are particularly concerned about data privacy.

In such cases, I’ve found that it is good to give users at least a clue to what the Help is about. You can do this by highlighting the parts of a label or question to which the help relates. Figure 17 shows an example of this, where a dashed underline and blue font indicate the availability of Help on hover.

In Summary

If a certain form-design technique is well established, there’s a good chance it has been thoroughly tried and tested. For instance, we usually place labels above or to the left of text boxes because that placement facilitates the fastest, easiest interaction with a form for users. And trust me, users much prefer to get form filling done quickly and effortlessly rather than to have a painful experience using a form that’s pretty.

Use this knowledge to your advantage. The key to designing highly usable forms is to make sure whatever widgets or methods we adopt, old or new, they are fit for their purpose. As for any task, choosing the right tools for the job—in this case, form filling—makes the job much easier.

So, if you’re thinking about a novel approach to form design, make sure you keep the overarching goal of the form in mind: collecting error-free data, while placing as little burden on users as possible. If you align your choice of form widgets with this goal, you’ll design successful Web forms.