Don’t Put Hints Inside Text Boxes in Web Forms

How about making the text gray?

How about putting an ellipsis (…) after the text in the box—like in Email…?

How about validating for My sequence in the example above?

It’d be great to look at some data on how properly designed text in a text box works.

I agree that one should try to avoid text inside the boxes, but if you follow these simple rules for designing it, it might save you some space and provide an extra bit of help for users.

It’s also a shame there’re so few bug-free implementations of the grey text out there.

It’s an important question, but I think there may be other factors at play in your examples.

The National Rail form failed because it did not correctly remove the hint from the field when it gained focus, not because the hint looked like a default value. (There isn’t a station called Station Name / Code.)

In the EMBL-EBI example, there was no confusion: My Sequence was the default value, not a hint. If it was not an acceptable value, it was up to the form validation to alert the user to the fact. There is no way of knowing how many of the 99% simply preferred to keep the default rather expend the effort of coming up with a new name for the job.

It seems to me that the hint was either badly worded—perhaps Enter a memorable name for your job would have been better—or maybe just unnecessary. The label is descriptive enough.

In both cases, it would have been better for the hint to be a separate element that was styled—using some unobtrusive JavaScript—to appear over the input field and disappear when the field gains focus. Then there’s no chance of it’s getting submitted with the rest of the form, but it still provides valuable guidance to the user about the expected value for the field.

I agree with this article about the improper use of hint text in Web forms.

However, I think some of the issues discussed here—such as the National Rail site—sound like defects of improper hint text usage. Hint text should always disappear once the specified control gains focus—that is, the user can enter text into it—regardless of where the user clicks it.

Secondly, there are other design patterns that make good use of hint text—such as search text boxes especially in areas of confined real estate. For example the Quick Search box in Firefox displays hint text showing the current search provider—for example, Google or Yahoo.co.uk—and this always disappears on gaining focus.

Karim Toubajie

I can understand hint text’s confusing users into thinking it’s default text, if the hint text looks exactly like regular text within the field—for example, in your Figure 2. I would be curious to know what the numbers show when the hint text is restyled.

As far as the hint text’s being submitted as a default, that sounds like a poor technical implementation. Tell your developers to stop doing that.

I agree and disagree. What about having hints with a different color—for instance, a light gray that clearly shows it’s not a default value, but informative text—that is, hint text? I would be very curious if the report wouldn’t switch to a 50–50 or even completely switch to 99–1 in favor of hints.

I know that, from my Web experience, I have always typed in the fields that had a light gray hint or no gray at all. But I am a Web developer, so that might be one issue. :)

Anyway, perhaps if the color is an issue, you should rename the article to something like “Don’t put hints inside text boxes without styling them accordingly in Web forms”?

Thanks for the article and for the statistics and information!

Andrei Gabreanu

I find it ironic that the title banner for the Good Questions column looks like a form field containing hint text.

Great article. Like some others have said, I think people are just trying to save space and prompt people to enter the right content. Personally, I think it is more elegant than having ToolTips at the end of a design, but as you say, it’s still not an ideal solution.

I think the problem is often a lack of usability testing as well—people often don’t realize which parts of their sites are logical or illogical and hence don’t quite know how to design it properly. We’ve recently designed our own usability tool at IntuitionHQ, which we find quite helpful in this regard, and there are plenty more out there on the Internet as well.

The key is just putting everything together in order to make a great design.

Oh, and I love hansenlys comment.

Hello Caroline, thank you for your article.

I think that one has to start from a correctly implemented UI widget—that is:If these aren’t met, hint text may be rather counterproductive.

Using hint texts can often help in making the UI clearer, because you can eliminate some instructions between or next to your fields.

Thanks all for your discussion. I’ll aim to respond to your comments one at a time:

hansenly: You spotted it! The logo is deliberately a bit ambiguous: is the text a question or an answer? My hope is that it’s intriguing.

useuseuse: I’ve seen hint text being misinterpreted in various designs. Do you have some data that you could share that shows that your participants interpret your suggested designs correctly?

dan: It’s interesting that you interpreted My sequence as a default value, just as the users are doing. That wasn’t the designers’ intention. As I mentioned in the article, the text didn’t actually inconvenience the users or cause them any problems. It just didn’t work the way the designers thought it would.

Karim Toubajie: I’d like to see some comparisons between Search boxes without any hint text in them, and those that do have some hint text—even if it is faded and then disappears. My impressions from oberving users is that they take a little longer to identify the Search box as such if it has hint text in it.

Andrei Gabreanu: Your point about Web developers’ understanding these subtleties is spot on.

I did consider giving more equivocal advice about styling, but rejected it, because I don’t find that styling really helps enough to overcome the basic problem.

Best, Caroline Jarrett

Interesting post!

I agree with the comments above—National Rail didn’t do an adequate job of getting the embedded Help to remove when the field has input focus. And, different design and wording could have likely better communicated that the Job Title in the Job form was not intended as a default.

Given your comments that users will skip over a field if it looks filled in, it would be really interesting to see if that still holds true with some subtle design changes—for example, light gray text. In your testing of the accountancy package form to create a new customer, how did the embedded text look?

I do feel that the embedded hint text is no substitute for a descriptive label. In your accountancy package example, if users were filling in a New Customer form, seems having a label of Customer name alone would be plenty obvious.

@hansenly—good catch!

I think these are just poor examples of using in-field labels. The images shown clearly make it look like it’s a default value. A little bit of design would go a long way for these forms.

Several other things, if you choose to do labels this way:

1. Validate, server side, that the value isn’t the default value.
2. Make the text grayed out so as to make it look like helper text, not like the other inputs with a darker shade.
3. Make the text disappear.

Better yet, test this interface with a much cleaner implementation—and that is using CSS, JavaScript, and labels, and progressively enhance the forms. me.com is an example of this. You are using the field label, positioning it over the text, giving it a lighter shade, then using JavaScript to hide / show when people click the text field. It also has the advantage that the text doesn’t immediately disappear—it simply fades to a lighter color, so the user can still see the Help text before they type.

1. You don’t have to validate anything, because it’s not actually the value of the field itself.
2. It works even with password fields, which would normally only show asterisks.

I just don’t think you can say ‘Dont do it!’ when the examples presented are blatantly poor examples of in-field hints.

I’m with hansenly on the irony of the header image for this column.

This is just to point out that you’re going to hate HTML5:

• The placeholder attribute
• Placeholder Text

Hints inside text boxes is soon going to be part of the HTML standard:

The placeholder attribute

This should at least avoid the problem with buggy JavaScript not removing the placeholder text.

In practice, hints in text fields can have utility, but you’re right that when improperly implemented they do more harm than good.

The typical practice of prefilling the form field and then using JavaScript to remove the text when gaining focus is flawed. It fails to provide progressive enhancement, does not degrade gracefully, and as you note, is prone to bugs. Not validating input against the hint text further compounds the issue.

My preference is to use CSS to provide a custom background with distinctive hint text rendered as an image, provide a blank background for the focused meta-class, and use JavaScript to clear the background once text has been entered. It doesn’t provide any benefit for accessibility, but it does prevent the hint from doing damage, and it degrades gracefully.

So, what’s your take on the placeholder attribute under consideration in the spec for HTML 5? References here:

• the spec on w3c.org
• an interesting article about current support for the placeholder attribute

I think the issue at hand is more of implementation than of the use of hint text.

First up, help text should always be implemented as a progressive enhancement, allowing for behavioral control over the visibility. My recommendation would be to use your JavaScript of choice—framework or otherwise—to populate, on document ready state, the assisting text.

Second, the text itself should not have the same shade as entered text—browser location and search bars are good examples of where they have been used well, as Andrei has mentioned, where it is a light shade of grey. Possible other means of identifying help text is through the use of italicizing the contents.

Third, the help text, only, shall be removed on focus and only reappear on blur if there was nothing entered into the input / textarea.

Fourth, feedback to the user—preferably a modal window—triggered by a behavior-based check of the form, should be made available. Where the help text is still present, the user should be notified.

Finally, any and all help text shall be removed prior to the form being sent—to ensure non-required fields are not incorrectly populated.

This is a really interesting article. I wonder, Caroline, do you not think the examples above could have been helped by having the E.g. prefix?

When I have included hint text in the past, I’ve always found you need to have the E.g. or a secondary label as hint text Please enter a numerical value…. Otherwise, the hint text definitely does look like it’s just an answer.

Really great article as always!

Hi all,

So many interesting comments that I’ll try to reply to all of them in one go. Thanks for making this a great discussion.

I know that the placeholder attribute is appearing in HTML. But having an attribute in HTML isn’t the same as making it a helpful feature for users. Example: Reset. Can be used; shouldn’t be used in most cases. I wrote an article about that a few years ago: “Reset: the piece of HTML created just for me.”

My contention is that the main problem with hints inside text boxes is that users don’t realize that they need to fill in a box, so they don’t click the box.

• Having the text disappear when a user clicks the box doesn’t solve that problem.
• Removing the text on submission then either creates a blank field in the database or gives the user a validation error that is unexpected. Neither is desirable.

And being a little mischievous: the implementation subtleties that are being suggested to make the hint appear less obvious, move away, and so on seem like a lot of work to me compared to just not putting a hint in the box in the first place.

Best, Caroline Jarrett

“And being a little mischievous: the implementation subtleties that are being suggested to make the hint appear less obvious, move away, and so on seem like a lot of work to me compared to just not putting a hint in the box in the first place.”

Being a little mischievous: UX—as design in general—is always also very much about implementation subtleties. Every idiot could get the ergonomic basics right nowadays—it’s detail that counts and sets a great experience apart from the great mass of bad to mediocre ones. Hence, implying that care for detail involves more work than doing an, at best, mediocre job seems pretty pointless to me.

Hi Sascha

Definitely agree with you that implementation subtleties are important in UX.

Only, I’d take the view that one of those subtleties, and perhaps one of the most important, is to simplify—and sometimes that means not implementing something.

Which also has the advantage of saving a bit of development time to be devoted to something else—perhaps more testing with users.

Best, Caroline Jarrett

I’d just like to point out that the example you used, the National Rail site, is simply a matter of poorly coded JavaScript.

The event handlers that are supposed to deal with the hint text are assigned only after the whole of the page has finished loading. The problem with the National Rail site is that it has so many slow-loading resources like Flash that the text boxes are visible on the page a long time before the event handlers are assigned. If you wait for the page to load, then everything does indeed work fine.

The examples you show have both hint text and labels. I’ve developed forms with no labels and have treated the hint text as noted by others—grayed out, disappearing when appropriate, and so on. The benefit is a cleaner, simpler layout, less eyetracking from label to field, and less ambiguity about what the user is to input.

That said, if I saw hard evidence that forms designed as I suggest actually have a higher failure rate, so I’d ditch hints and revert to labels in a second.

James: Thanks for taking the time to explain why the National Rail site works the way it does. I chose it because it’s an easy-to-understand example that is available publicly. As I mentioned, it illustrates a problem that I’ve seen across many forms—on and off the Web, coded well and badly.

Best, Caroline Jarrett

A note on the implementation of hint text that is based on the examples you gave and some of the comments made …

Hint text should never be set as the value of a text field.

The optimal implementation for hint text has the actual text as part of the label. This text is then positioned over the field in question and event listeners (focus, click) set so that it disappears when the field gains focus or has a value. This avoids the problem of the hint being submitted as a default value.

Of course, this doesn’t address the issue as to how usable hint text is. I leave that to UX people. (I’m a front-end developer.)

Hi All,

I think an on-focus ToolTip is one of the best options for this matter.

That means when a user puts the pointer on a particular field—the on-focus stage—the ToolTip text will appear beside the field.

It must have been a slow news day or something, because the fact that this article was posted in the first place seems a little silly to me. The blanket decree, “Don’t Put Hints Inside Text Boxes in Web Forms” contradicts research data and common sense.

There’s a time and place for this approach, and as others have eloquently pointed out, the implementation was the problem in Caroline’s example. A solid implementation of in-context Help or hints will always contribute to a more productive, persuasive, and delightful user experience.

Maybe I’m just feeling cranky this morning, but I think this article actually reduces UXmatters’ credibility in my mind.

Michael:

Your point about not having labels at all is really another whole topic—in my mind, anyway. Perhaps you could mention some examples of forms that use this technique that you consider to be well designed?

Patrick:

The problem is of having anything in the field—that’s what makes it look filled in and means that some users will skip right over the field—so anything that relies on them clicking the field to make the hint go away won’t work for them.

Hiran:

Your point raises another whole topic for discussion—that is, if you can’t put the hint into the field, where should it go? Another one I’ll leave aside for the moment.

Best, Caroline Jarrett

Thanks, Caroline, for a thought-provoking post with some really fascinating statistics!

I’d be happy to be convinced otherwise, but it seems to me that an approach that will work for everyone is to provide the question in the label and any hints, tips, or examples immediately below the field, like Twitter does.

This doesn’t require any Javascript or other such trickery, means all the information is available at all times to the user, and I think is the most accessible approach, for those with and without a disability.

@Hiran

Alas, I think a ToolTip is not very accessible.

You need to be using a mouse to trigger it—bad luck if you’re zipping through the form with your keyboard—and I’m not sure whether it would be read out by a screen reader. More generally, using a ToolTip means the information is hidden with no cue to the user that it is there.

@Michael McWatters

I would strongly argue against using hint text inside the field in lieu of a label, as this is also not very accessible.

For those people using a screen reader, the label is how they know what the question is. For those people not using a screen reader, you have the problem that as soon as they start typing in the field, the “label” is gone. If they want to see it again, they have to take out anything they’ve entered. And when you’re looking at the completed form, you’ve got no way of knowing whether the information you’ve entered is right.

Given all that we know about how people move through forms, including the eyetracking research published here on UXmatters, I don’t see that there is a problem here to be solved by getting rid of labels. This approach might give the form a “cleaner, simpler layout,” but to me that’s at the sake of usability, like getting rid of the side- and rear-view mirrors in a car to make it look more streamlined. The saccades between the label and the field can be very minor if these items are aligned well, and I would argue that, in providing less information, you’re actually making the form more ambiguous, not less.

Thanks for the opportunity to comment,

Jessica

A lot depends on the context of the form, the data being collected, the purpose of the data collection, and the layout and design of the form itself and the surrounding content.

As an example in a recent WhichTestWon test, the required conversion was the completion of a form.

One was a typical form with labels on the left of the fields and the other a multicolumn form with field hints and a minimum of labels—the latter of a layout and style generally believed to reduce conversions.

One of the forms increased form completions by 16%. Guess which?

It’s far too simplistic and proscriptive to just say never!

Robwillox:

Thanks for the link—but it showed only the winning version.

Here’s the page with both versions.

As you point out in your post, the winning form was completely redesigned in many ways. As the comments on that winner point out, the changes included

• making the form look a lot shorter
• putting the Continue button above the fold
• and a whole bunch of other changes

I’m not disputing that in a head-to-head between those particular forms in that context with those users, the form with the labels inside the boxes won.

I would strongly dispute that this necessarily makes putting labels inside the boxes a good idea.

But either way, as I said in a previous comment, this column was about putting hints inside the boxes. Putting labels inside the boxes is a whole other story—and one I’ll think about writing about.

Best, Caroline Jarrett

www.formsthatwork.com

Thanks for signing in to comment, .  |   Sign Out

Note—The site administrator must approve your comment before it will appear on this page. Thank you for your patience.