Dynamic Help in Web Forms

Communication Design

Musings from the merger of medium and message

A column by Luke Wroblewski

May 21, 2007

Many Web application designers strive to reduce the amount of instructional text that appears in the user interfaces they create. A likely part of their motivation is the perception that, if explaining how to use something requires too much instruction, it probably isn’t that easy to use and, therefore, has room for improvement in its design. Another motivating factor might be the tendency for people not to read any on-screen instructions, just like they tend not to read product manuals.

This type of thinking also applies to Web forms. When possible, designers strive to utilize a minimal amount of text to explain how users should fill in the different input fields in a form. In cases where forms absolutely require additional explanations or examples, a bit of clear text adjacent to an input field tends to do the trick, as shown in Figure 1.

Champion Advertisement

Concise, adjacent Help text — Figure 1—On videoegg.com, clear, concise Help text adjacent to an input field

Concise Help text adjacent to input fields is most useful when

asking for unfamiliar data—What’s a PAC code?
people might question why you are asking for specific data—Why do you need to know my date of birth?
there are recommende ways of providing data—Separate your tags with commas.
certain data fields are optional

However, there are many types of forms that require lots of obscure data, use unique formats, or have input restrictions. In such cases, the amount of Help text necessary for each input field could quickly overwhelm a form, making it appear quite intimidating or complex. For forms like this, it might make sense to consider using dynamic contextual Help. As various Help systems have emerged online, I’ve started to catalogue the different types I’ve come across.

People’s behavior can automatically trigger access to Help systems. Automatic systems reveal applicable Help text when people engage with a form. Actions like moving between form fields or groups of fields result in the display of useful Help text. User-activated Help systems, on the other hand, require people to take deliberate actions specifically to reveal relevant Help text.

Automatic In-Line Exposure

Automatic in-line Help systems reveal themselves when and where the information they contain is most applicable. For example, when a user clicks or tabs to an input field, the relevant Help text appears beside or below the field. Figure 2 shows this behavior in action in a form on Wufoo.

Some sites automatically expose in-line Help text for a set of related fields rather than just an individual input field. For example, in Figure 3, the SnapTax Web application automatically highlights relevant information for each set of information: identity, spouse, address, and so on.

Help for related fields — Figure 3—SnapTax automatically reveals Help text for groups of related input fields

It is worthwhile to note that both of these examples make use of a strong visual element to communicate the relationship between input fields and their associated Help:

in the Wufoo example—two aligned rectangles
in the SnapTax example—a common background color

A potential drawback of this type of automatic Help system is that people are unlikely to know any Help text is available until they begin to fill out the form. There’s often very little in the presentation of these forms that indicates Help is available. As a result, users who feel they may need help completing a form could get discouraged and not even try.

User-Activated In-Line Exposure

An alternative in-line exposure technique is one that lets people access Help text when they need it. This method usually makes consistent use of an icon, button, image, or text link to let people know Help is available. A user can either click or point to these hot buttons to reveal the relevant Help text as needed.

User-activated, in-line Help — Figure 4—Juicy Studios’ user-activated, in-line Help system

Adding Help text to a form in this manner can cause content below the inserted Help text to jump further down on a page. Figure 4 shows how Help text pushed another input field lower on the page. Too much shifting of content on a page can leave users disoriented. Another potential drawback of this technique is that it might be necessary to display Help text differently, depending on the types of input fields—or set of input fields—to which it applies. A set of check boxes or multiple drop-down menus might require a different placement of Help text than a single input field.

Utilizing a rollover to expose Help text, as Figure 5 shows, does not require the insertion of content into a form and thereby avoids the jumping effects of in-line exposure. However, rollover interactions require users to keep their pointers continually positioned on a trigger’s hot spot. Extending the size of the rollover’s activation area makes it easier for users to trigger the content display.

Hot spot for Help — Figure 5—Help text that appears when a user points to a hot spot

A question mark is the most common symbol for an icon that displays Help content, but as Figure 6 shows, there are other symbols you could use. Regardless of whether you use an icon, button, text, or a combination thereof to indicate points at which users can access Help text, it’s generally a good idea to include some kind of visual cue that indicates such elements are actionable—for example, a 3D bevel or underlines beneath text.

Help symbols — Figure 6—Symbols for Help

User-Activated Help Section Exposure

Some sites display user-activated Help in a consistent location on a page instead of showing it adjacent to input fields. Making use of a consistent area where Help text appears can provide a larger display area for extensive Help content and meet users’ expectations for a permanent location where they can find Help text, as shown in Figure 7.

Consistent location for Help — Figure 7—On Vizu, Help text that is relevant to the active input field appears in a consistent location on a form page

On eBay®, the Sell Your Item form that Figure 8 illustrates makes use of a Help panel that a user can display or hide by clicking a global Help icon above the form. The content in the Help panel also updates with contextually relevant Help text when a user clicks one of the Help icons next to each input field. When open, the Help panel also automatically updates with relevant content as users move from field to field while completing the form.

In Conclusion

Each of these dynamic Help systems for Web forms has its distinct advantages and disadvantages. As with all design decisions, an understanding of user needs and business goals should inform which of these dynamic Help systems is right for your Web forms. If you’ve used other types of dynamic Help on Web forms, please let me know, so we can extend this list of options.

In User Assistance Design | Web Application Design | Web Form Design

21 Comments

Brian Donohue

May 22, 2007 2:38 PM

Very useful and practical article. I’d add another caveat to the drawback you note of the Wufoo-like automatic Help display.

I considered using that Wufoo functionality for a form, but then rejected it, because I realized the Help text I needed was of the “Why are you asking me this?” variety. So someone might not bother clicking the field if they don’t think they should have to provide that data, and then they’d miss the explanation.

I’d suggest that dynamic Help is best for the first and third types of Help text that you list—unfamiliar data and how you should enter the data—but is riskier for the 2nd and 4th types, even if you do give an indication that Help is available.

Mike Hughes

May 22, 2007 8:21 PM

This is a very useful cataloging of Help patterns. An innovative use of dynamic Help panels, such as in Figure 7, that I have seen is to let users select the Help language. Some B-2-C Web applications have used this as an inexpensive way to reach Spanish-speaking customers without having to localize the user interface itself.

Todd Sieling

May 22, 2007 11:08 PM

This is a great roundup of some nice techniques. Some, more than others, obviously need to be incorporated into early design, but the ones I like the best can be added to existing forms without too much trouble. Nice stuff.

Paul Rouke

May 23, 2007 8:49 AM

I have recently posted on form field best practice and the use of Help text to help assure wary users or simply provide additional information to support users as they are completing forms.

I didn’t break it down into each of the areas you have here, but I agree that each has its own advantages and disadvantages. Understanding your user base will allow a business to determine how savvy their users are, which in turn will influence which is the most suitable technique for displaying Help messages while users are completing forms.

Michael Zuschlag

May 23, 2007 1:23 PM

For me, it’s helpful if the taxonomy has separate dimensions for how Help is activated—automatic, on mouseover, by clicking an icon—and how it is displayed—dedicated pane, margin beside field, inserted between fields, hovering above. These can be crossed with each other to make 12 different ways of doing dynamic Help. Some trade-offs, in addition to the ones you mentioned: Hovering Help can cover content the user wants to see, but avoids the real-estate consumption of Help in a margin or dedicated pane—and the disorientation of inserted Help you mentioned.

Kate Walser

May 23, 2007 6:44 PM

Great article, Luke. Helpful ideas. Have you had a chance to check the accessibility of the different options? The use of spans and divs that are hidden/revealed present interesting challenges in ensuring that users with screen readers, for example, can activate them with the keyboard—a problem when span is used without —and that the assistive technology interprets them only when appropriate—for example, doesn’t read them when the area is hidden. I’ll take a look at the sites you suggested to see if they’ve tackled the issue.

Christian Watson

May 23, 2007 7:45 PM

One additional point that’s worth noting is how important it is for the Help content to be at the appropriate reading level of the user.

Although the Help in your examples appears to be well written, I’ve come across plenty of instances where the term Help is an oxymoron when you actually read the content contained therein.

Jeff Woelker

May 23, 2007 11:32 PM

I actually wrote a similar article a while ago. I really like the idea of inline Help/warnings for users when doing form input.

I have been struggling recently with which is better: whether to inform users that they have entered something incorrectly on field change or to wait for page submission.

On field change, it’s immediate, but jars the form up and down and may distract the user, but really that’s the point. On page submission, it’s after they have entered all of their information and, in the case of a long form, it may require that they scroll up to see where the error occurred. In the case of a page submission, it allows them to make changes before they submit their information and only warns them after they have done so.

Thoughts?

Francesco Rizzi

May 24, 2007 1:59 AM

Hi Luke. Thanks for the interesting and instructive post. I think your taxonomy of form Help is quite exhaustive.

However, I think there’s still a group of applications —yeah, I’m focusing on Web-based applications, rather than Web sites—that uses an external window to present their Help content. It might be a separate window—that, maybe, is opened with a smaller size than the main window—or a different page presented in the main window.

Either way, it’s an approach somehow similar to the ones you cite in “User-Activated Help Section Exposure.” The critical difference of displaying the Help content in its own window, instead of side-by-side with the form, might be enough to give this approach its own name.

Context-free Help, maybe ? Yes, the Help is activated with a context, but then lives on its own, whereas in the solutions you described above, the context is maintained.

Thanks, F.R.

Juan Ruiz

May 24, 2007 4:21 AM

I do agree with you that, when people think there are too many instructions on a Web application, there is room for improvement. This could be true and false at the same time. We often sacrifice extra lines of Help text in order to improve the design of our Web applications, but then, we are designing with the look-and-feel in mind rather than focusing on the user.

Documenting the different methodologies people are using to display Help text in online forms is great. Thanks for this great work.

I also agree with you that selecting the appropriate Help display method depends on user needs and business goals. I wonder if there have been some usability studies on each of these methods and/or other methods so we can understand how users react to each of them. Maybe, a simple line of text under the field label is enough rather than a Help display system.

Great work, Luke!

Rhonda Bracey

May 24, 2007 10:08 AM

User assistance for Web forms was one aspect of a presentation I gave at two conferences last year—handouts of the presentation and examples are available. See slides 15 and 16 in the Examples handout.

Jeff—You asked for our thoughts… I hate getting to the end of a form, clicking Submit, then finding that I’ve missed something or entered something incorrectly. I’d rather be told of the error up front, as I exit the field. In other words, do field validation at the point of data entry and exit, not at the Submit stage. Even worse is to be told that there’s an error, correct the error, click Submit, then find there’s another error! In such cases, someone has decided that only one error gets displayed at a time, instead of all errors at once. I understand your concern about the page jumping, but I think it’s a small price to pay—and as you said, it’s a visual indicator that something’s wrong. Of course, the absolute worst is the form that resets itself when you click Submit, get alerted to an error, and have no choice but to click Back, only to find all your carefully entered data is nowhere to be seen. That’ll send me running from that form forever!

Great article, Luke, and an excellent summary of the various forms of inline Help.

Nathan

May 24, 2007 12:32 PM

There may be a potentially unexplored angle here, regarding the effective presentation of declarative versus procedural Help.

On the face of it, Figure 5 is an effective example of the display of declarative Help, but how might you best augment the form with procedural Help cues?

Shekhar P Bagawde

May 24, 2007 3:30 PM

Hi Luke,

These articles on form design are really interesting and helpful. I have come across a few forms that display the Help text in some different ways.

For example:

1. On Wells Fargo Advantage Funds: Fund Screener, the form labels are displayed as hyperlinks and the Help is displayed on mouseover on the labels.

2. On Charles Schwab: Life Insurance, the form labels are links, and they display the Help text as alt+tags. Some links display the Help in a pop-up window, and these links are indicated with an icon for pop-up.

Thanks and regards, Shekhar

LukeW

May 25, 2007 12:47 AM

Brian, good insights. I think I agree that the 1st and 3rd options might be best suited for dynamic Help systems.

Mike, does that work at the form level or input level? I’ve seen forms that toggle language at each input, which seems like it gets annoying, versus forms that set the language once for the whole form.

Kate, I welcome any accessibility insights you have. From my experience, there’s usually a way to make dynamic systems more accessible, but it involves some tinkering.

Jeff, indicating errors inline depends on the type of input and the type of error. In the case of format-sensitive errors, it’s arguably a good idea to flag the problem up front. For items with interdependencies or those that can’t be validated in isolation, inline validation probably won’t be helpful. The practice I’ve been following is to utilize inline validation for input fields with a high potential for errors. Another consideration is, if you validate each field, you end up with a lot of verification chatter as success messaging shows up for each input and at various times.

F.R., thanks. That’s a good addition I had neglected and could be broken out into Web browser dialog windows and inline windows—both with move and close functionality.

Juan, as I stated in the article, concise and relevant Help text adjacent to the inputs where it applies is most often the best course of action. But when paragraphs are required to explain an input, that method quickly breaks down.

All, thanks for the comments.

Javier Julio

May 25, 2007 2:00 PM

A great article, Luke. I already use your familiar and unfamiliar label alignment setup in my XHTML forms through CSS with great success. While developing that though, I quickly ran into this very same topic. I needed a way to display Help text that was intuitive and made sense.

I tried the Wufoo approach, but then again, I never thought of the main concern you gave, though it’s a very good one. I was worried about the whole displaying and hiding of the Help text and also form fields jumping up and down. You see, I display the Help text underneath the form field, not on the side. So whether I have left-, right-, or top-aligned labels, the Help text always appears right below the form control.

This is what I currently use and seems to work well, at least for now. All of the examples you have put here I’ve come across while I’ve done my research on the Web, so it’s great to have this article point out the advantages and disadvantages, because I was never really thinking about those. I was just trying to find something that would work globally with my forms CSS. Again, great to have and well written, Luke. Already bookmarked!

Lindsay Ellerby

May 25, 2007 8:39 PM

This is a great article that’s sparked some awesome discussion.

Just to share my experience with in-line contextual Help… I was involved in the design of an online application that incorporated Help overlays that dynamically appear when a user clicks or tabs into a field. The application was designed with an empty right column, so that the overlays mostly wouldn’t cover up essential content. It tested well. Users who were looking for Help easily found it, and users who didn’t need Help often did not notice it was there. In hindsight, I would have provided two types of Help content—the dynamic overlays we ended up using plus “Why we need this” text links to explain larger issues like security and the use of personal information.

We also used in-line error messaging in the form, which tested very well. Error messages appearing upon field exit were not too jarring for users—in fact, they appreciated it.

Another feature we used was in-line editing on the form verification page. We allowed users to instantly edit their information without having to return to the application form page.

Check out the application.

LukeW

May 29, 2007 7:02 AM

Nathan, can you clarify what you mean by “declarative versus procedural Help”?

Shekhar, nice examples. I think the method you are highlighting is “User-Activated In-Line Exposure,” using rollovers (Figure 5)? Or is there a difference I’m not seeing?

Lindsay, thanks for sharing the example, but I get an error when following the link? Can you repost? Thanks!

Ruth

June 18, 2007 2:40 PM

Great content. Helped to choose what kind of Help text I exactly require with the pros and cons. Thanks.

Juma Vincent

June 28, 2007 7:24 AM

What search engine does the Help system use and how does it work?

Lisa Goldberg

April 24, 2008 9:26 PM

I just discovered this very useful article and can put it to use immediately—thanks for publishing it.

However, I would add a warning regarding the placement of Help text in the right column, as shown in Figures 7 and 8. In usability tests I have watched many users ignore the right column entirely.

I tested one form with a layout quite similar to the form in Figure 7. Almost no one read the Help text in the right column. However, there were two significant differences:

The help was not interactive; it was always present in the right column.

Users were not provided with any prompts to read the text in the right column.

So it may be that, if users are provided more active cues, they will look to the right. However, based on what I’ve observed, my inclination would be to place the Help text as close to the input field as possible.

Ashu Saini

September 2, 2015 3:47 AM

Hi—A very useful article with lots of examples. I want to know which language is used to develop such help. As technical writers, are we expected to know how to develop it?

Join the Discussion

Full name

Email address

Remember me (Optional)

Comment

Luke Wroblewski

Product Director at Google

Speaker and Author at LukeW Ideation & Design

Silicon Valley, California, USA

Before joining Google, Luke was CEO and cofounder of Polar and Chief Product Officer and cofounder of Bagcheck. He is the author of three popular Web-design books—Mobile First, Web Form Design, and Site-Seeing: A Visual Approach to Web Usability—in addition to many articles about digital-product design and strategy. He was also the founder of LukeW Ideation & Design, a product strategy and design consultancy. Luke is a top-rated speaker at conferences and companies around the world, and was a cofounder and former board member of the Interaction Design Association (IxDA). Read More