Fashionable Web Forms: Traps and Tips
Published: November 1, 2010
I know as well as anyone that we humans are very visual creatures. My area of specialty is the design of forms and, as you can imagine, a significant part of my work focuses on visual design and layout. Recently, I published a series of six articles about human perception, or how people see, and the impact this has on the way we should design Web forms. We can use what we know about human perception to help people move through forms quickly, easily, and successfully. Form design is not about aesthetics just for aesthetics’ sake.
Don’t get me wrong. I do think the attractiveness of a user interface is important. My concern is that people sometimes pay disproportionate attention to how sexy, pretty, or aesthetically pleasing a form is, in comparison to how well a person can actually use it. If users can’t successfully fill out and submit a form, it’s a waste of pixels—not to mention everybody’s time.
So let’s put some novel form-design approaches under the microscope and see how they fare. In this article, I’m going to examine the following Web form fashions:
- unconventional label placement
- creative required-field indicators
- hidden contextual Help
Unconventional Label Placement
A field label tells people what sort of information needs to go into a text box or other form widget. This means they need to read the label before they get to the field.
For Web forms in languages that are read from top to bottom and left to right, designers usually place field labels above or to the immediate left of fields, leveraging this principle of reading order. However, I have seen a couple of Web forms that had the labels below their fields, as shown in Figure 1.
Figure 1—A Web form with labels beneath the fields
Assuming a form is in a language that people read from the top of a page down, positioning a label beneath a text box results in people’s receiving form elements in the reverse order from what they need—that is, text box, then label rather than label, then text box. Because users first see a field, then must look underneath it for its label, then look back up to fill out the field, their experience of filling out the form would be to take two steps forward, then one step backward; jump forward three steps to the next label, take one step backward; jump down to the next label, and so on.
This continuous forward and backward movement is likely to get very tiresome, very quickly. Obviously, it is much more work for users than if labels were always above or to the left of text boxes.
Another modification of the traditional placement of labels that is starting to garner interest around the Web is inserting them inside the text boxes, as shown in Figure 2.
Figure 2—A Web form with labels inside fields
There are many reasons why this is a bad idea:
- Once a user starts typing in a field, its label disappears. So the only way users can check what they are supposed to be doing—if they are interrupted, for instance—is to remove their answers and hope the labels reappear.
- If a label doesn’t disappear as soon as a user selects an insertion point in a field, either the label accidentally gets submitted along with the intended text or the user must delete the label manually.
- Fields with text in them appear to be complete, so you’re likely to end up with much higher error rates.
- Once a form is complete, there is no way for users to review what they’ve typed and confirm that they’ve provided the right information.
- There is no way to keep a usable visual record of the information a user has typed, because a printed or saved form a user has filled out has no labels.
- This approach is feasible only if a field label is very short. So once you get beyond a really simple sign-up form or the like, it means inconsistent formatting between questions on your form.
I could go on, but Caroline Jarrett has already written on this topic in depth in her UXmatters column “Don’t Put Hints Inside Text Boxes in Web Forms.” I strongly suggest your reading that piece for some great background and empirical evidence that putting labels inside fields is really not a good idea.
So why do it? Some people argue that it makes the form neater. I think this subjective claim is debatable. It’s also a bit like getting rid of the food in your fridge so it’s cleaner. While the slightly obsessive neat-freak in me appreciates this desire, we need to resist such impulses if we’re going to create good user experiences.
Another argument for putting labels inside fields is that doing this saves space. This is certainly true, but there are only a very few instances where space is at such a premium that there is no room for labels outside text boxes—for example, if you’re squeezing a couple of sign-in fields into a small site header. But you need to be very careful with the implementation of this approach—so labels disappear on a user’s selecting an insertion point in a text box, for instance—to maintain usability.
Last, but not least, the most unconventional label placement I’ve seen uses animation. A label is initially inside a field, then, as a user starts typing data, slides out to the left of the field, as in the CSSKarma sliding form labels demo. While this approach is certainly novel, I can’t see any benefit to it. It doesn’t save space, because you need to reserve space for the labels once they slide out of the text boxes. The animation is distracting, and you are still left with many of the problems I mentioned earlier, like users mistakenly thinking they’ve already filled the fields out.
Creative Required-Field Indicators
If you ’re going to use some sort of indicator on your form to point out which questions users must answer, why not stick with the de facto standard—a red asterisk (*)? This may not be the best indicator we could ever have designed, but through its use across a large number of Web sites, it has become a well-known convention. And as Luke Wroblewski says, the red asterisk works well because it has “double visual emphasis.” Both the color and the shape are visual cues, so this indicator is accessible to people with color-deficient vision.
While there are still some people who don’t yet know what this indicator means, there are definitely more people who don’t understand what a red bullet (Figure 3) or a yellow bar (Figure 4) means.
Figure 3—Red bullet as a required-field indicator
Figure 4—Yellow bar as a required-field indicator
While there is an explanation of what a yellow bar means at the top of the form shown in Figure 4, experience and research show that most users don’t read instructions. Thus, there is a good chance they’ll miss this explanation. Better to just use the convention and know that most users will have no trouble understanding it.
What’s the most troublesome alternative required-field indicator I’ve encountered? Figure 5 shows an example in which the labels of required fields are underlined. Not only is this an unfamiliar approach, we all know underlined text has another well-established meaning on the Web: indicating a hyperlink. This is definitely not a good choice for indicating required fields.
Figure 5—Underlining as a required-field indicator
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.
Figure 6—A slider with only eight discrete options where a list box would be preferable
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.
Figure 7—SEEK home page at the time of the test
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.
Figure 8—Salary-range selection with a slider on SEEK
Figure 9—Salary-range selection using two list boxes on SEEK
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.
Figure 10—SEEK salary slider on the Refine your results panel
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.”)
Figure 11—A slider presenting more detail than is necessary
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.
Figure 12—A slider gives users options for how they want to interact
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.
Figure 13—Question mark Help icon
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.
Figure 14—Contextual Help that is always visible
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.
especially, but not only, users who are using a keyboard or assistive technologies.”
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.
Figure 15—A Help icon that is cute, but unusable
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.
Figure 16—Help that appears only when users are typing a value in a field
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.
Figure 17—Hinting at the availability of contextual Help on hover
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.