Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
  • Chrome and Safari remove placeholder text after pressing first key in the text input.
  • Firefox and Opera remove placeholder text immediately after focusing the text input.

Which approach is better for users and why?

Test placeholder in your browser on jsfiddle.

Update: Placeholders in Form Fields Are Harmful

share|improve this question
3  
Here is one of many workarounds to make all browsers behave like Chrome on this regard: github.com/ripper234/input-placeholder. –  ripper234 May 15 '12 at 11:19
1  
Sure is a lot of speculation in this thread. Can someone post an answer with user research applied? –  Kevin Peno May 15 '12 at 21:10
    
Curious if there is an implication for screen readers. –  codingoutloud May 28 at 1:23

12 Answers 12

up vote 91 down vote accepted

Interestingly the w3 Spec for placeholder allows for either behavior:

User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string and/or the control is not focused (e.g. by displaying it inside a blank unfocused control and hiding it otherwise).

But, functionally speaking, there's little reason to clear it before the user starts typing. Users tabbing through your form might never see it because they'll tab into the field before seeing the placeholder text. Mouse users might not have finished reading the placeholder text before they click.

If your field is complex enough to require a placeholder, it probably requires some thought; what better time to think "what should I input?" than when you're focused on the field? Why take away that hint from users focused in the field but confused as to what to type?

share|improve this answer
14  
+1 I would go so far as to say it IS better to remove the text after they start typing, for the reasons you stated. –  tajmo May 14 '12 at 20:20
1  
@webvitaly interesting touch, though I'd want to make it apparent that the placeholder isn't a default/value, which is why I think they stray on the faded-out side instead of looking like normal text. I've also seen italics used to indicate this text isn't real –  Ben Brocka May 14 '12 at 21:31
5  
My concern with placeholder text is that users may get confused that they cannot select and delete the text that is in the field. Are there any studies regarding placeholder text? –  DisgruntledGoat May 15 '12 at 8:19
7  
firefox is moving toward keeping the placeholder while empty and focused : bugzilla.mozilla.org/show_bug.cgi?id=673873 –  Mathieu May 15 '12 at 15:30
3  
Firefox 15 now removes placeholder on typing. 14 and before used to remove on focus. –  Adnan Aug 29 '12 at 13:59

I would side with having the placeholder text show as long as possible without getting in the way.

The way it is done in Chrome is better, in my opinion.

I've found ways to get around this on all browsers, however.

What I've done in the past is remove the placeholder text on focus, but also re-displayed that text by making the label--which is almost always a duplicate of the placeholder and, if not, at least as or more descriptive--show up as a tab.

For example, here is part of my form with no fields in focus:

enter image description here

And here is part of my form with a field in focus:

enter image description here

This way, a user is never confused as to what exactly they've typed into a field. They can check back by re-focusing on the field.

share|improve this answer
8  
Though in an example like this, why not just have labels above the fields? I understand that sometimes moving labels inside the fields is needed for space, but I also find that it's done a lot of the time even when space is plentiful. –  DA01 May 14 '12 at 17:00
1  
Right, but it's not any less useable this way, right? –  magzalez May 14 '12 at 18:08
2  
@JimmyBreck-McKye I'm not advocating the replacement of labels by placeholders, and this mechanism isn't quite perfect, but maybe you're thinking of this one at CSS Plus –  Roger Attrill May 14 '12 at 18:29
1  
@magzalez moving the labels above on focus is perhaps not less usable. So that's OK. That said, it seems like an unnecessarily complex interaction that pretty much achieves the same end-result: a label above the field. You also lose the label after blurring, so that could be construed as a bit of a usability hit (especially on a large form) –  DA01 May 14 '12 at 19:32
1  
I'm not sure I like the placeholder text being so high contrast; seems easy to confuse with normal text like a default value for that input, no? I do really like the "label" it forms when you're typing though. –  Ben Brocka May 14 '12 at 21:32

Removing it when you start typing is better

Depending on how the focus was moved to the input field, the user may not necessarily see the placeholder text before it quickly disappears.

Yes you might read it before you manually click in the field but perhaps not if you happened to tab into the field from the previous input.

There's also the possibility that the first input field gets focus by default when a page is displayed, in which case the placeholder would still be good to see.

share|improve this answer
6  
Yes people actually tab through web forms. I do, and have seen others do the same. –  DA01 May 14 '12 at 16:56
1  
It shouldn't look fixed if visually designed properly (most browsers, by default, gray out the placeholder text)> –  DA01 May 14 '12 at 17:08
    
Generally the backgound colour of inactive fields becomes grey. Grey placeholder text on a white (or otherwise "active colour") field should not indicate it's disabled. –  Andrew Leach May 14 '12 at 17:47

The change to preserve placeholder text on focus in the recent Firefox 15 release confused me the first time I saw it. I actually thought the field was disabled. In Firefox, the default styling (text color) of placeholder vs. disabled is very similar, and unlike Chrome, there isn't a default focus highlight, so the main indication that the field is editable is the cursor which can be easy to miss. When you can't highlight or delete the text that's in your way, your first instinct if you're unfamiliar with the UI convention is not necessarily to start typing anyway.

Although there are some good practical arguments for preserving the text on focus, there's also a lot of precedent (at least in Windows) for the opposite behavior. One commenter pointed out that the search box in the Windows start menu works this way, and Firefox itself has several UI fields that clear on focus. The Windows start menu is actually an example of a hybrid approach. Its search box is initially focused and displays the text by default, but when the user manually focuses it, the text is cleared. I prefer this sort of compromise from a usability standpoint.

In an HTML environment, however, clean mapping to CSS (if only for override hacks) is also important, and there isn't a selector for auto-focus vs. user-focus. And at this point, all the browser vendors seem to be in rare agreement, so it's a bit late to be complaining. Perhaps a simpler compromise in Firefox would have been to add a default focus style for placeholder text that faded the placeholder text more on focus so the user had stronger feedback that the field could accept their typing even though there was still placeholder text in the way.

Setting aside implementation concerns in a particular browser, my preference in general remains to hide on focus. Although a large part of it is that it's simply what I'm accustomed to, I think there's also a fundamental aversion to trying to write in a space that's not already blank. Experience with handwriting, typing (with a typewriter!) and computing has taught me that if there's already text there, I need to do something about it first. I instinctively prefer a blank canvas before I start. I can adapt to the preserve on focus pattern, but I think it's going to be difficult to feel entirely comfortable with it unless there's more of a sense of the placeholder text getting out of the way when I focus the field for editing.

share|improve this answer

User scenario:

  1. User starts to fill a form of 6 fields (all filled with placeholders)
  2. The user sees the placeholders each time before filling the field and understands what needs to be filled
  3. User clicks on the field and the focus makes the placeholder disappear.
  4. Before the user might start filling the field, the user gets a message or mail and gets distracted for few seconds.

Now when the user comes back to fill that field which is in focus and with out placeholder. There is very high chances that the user has forgotten what he saw in the placeholder and might enter something on their assumptions.

Users might not get distracted while they are typing a field as they would like to finish that field and then see whats happening around.

Hence, Removing it when you start typing is better

share|improve this answer

Having seen someone trying to highlight some placeholder text for several minutes so that she could delete it and begin typing, I would say the delete on focus would be the most user friendly for all ranges of users.

I think the colour of the placeholder text makes a difference here as it was the same colour as the input text, maybe a light grey or something similar wouldn't have confused this particular user.

share|improve this answer

We checked this recently in a user test and it showed clearly that the field has to be empty once a user clicked it. If the text stays in there they thought they were not able to change this field and did not even try typing.

Another thing: I remember an UX consultant from Nielsen Norman reporting that if users see an empty field they tend to write something in it. So not having placeholders might increase conversion. :-)

share|improve this answer
    
+1, I agree, that in most cases placeholder not needed at all, label is enough and input should be blank (without placeholder text). But there are situations when you are limited in space (like login forms) and placeholder solve this limitation. By the way, what was the average age of tested users? –  webvitaly Dec 18 '12 at 8:53
2  
We run a test every fortnight with 5 users from 18 to no age limit, which matches our target audience. So an overall average age would not mean much. We take care to set up each test with persons between 18 and 25, 25 and 30, 40 and 50 and beyond 50. We use an external partner for recruiting them, because we can't be bothered running the entire recruitment process ourselves every 14 days. Luckily, the agency seems not to have difficulties to provide people that more or less match our age requirements. –  Steffen Kastner Dec 19 '12 at 5:58
    
+1, thank you for description of the user testing. Could you tell (if it is not a secret) what else confused users except placeholders? Or what other improvements you made after user testing? It is very interesting because users surprise me a lot sometimes :) –  webvitaly Dec 19 '12 at 22:03
2  
Another interesting finding was that you should NOT put mandatory check boxes just above the Submit button. Users will think this is for non-mandatory newsletter subscriptions and will neither read nor check it. –  Steffen Kastner Jan 3 '13 at 9:48

Which approach is better for users and why?

The better approach is the default approach. The user has chosen a browser and is used to how that browser does what it does. Don't mess with the defaults.

share|improve this answer
8  
Whilst this is sound advice, I don't think the OP wants to override browser behaviour - just ask which is the better design. But it's certainly true that browser defaults should never be hijacked. –  Jimmy Breck-McKye May 14 '12 at 17:08
    
@JimmyBreck-McKye hmmm depends. A great deal of proper web design is replacing browser "default" stylings. This isn't something like changing checkboxes to look like radio buttons where I would expect a "WTF" moment if suddenly placeholders behaved slightly differently. –  Ben Brocka May 15 '12 at 20:04
1  
@Ben valid argument, though note that this isn't styling. This is user interaction/behavior with a form. Forms have always had browser and OS-centric interactions...and especially true on mobile where the interaction differences can be quite drastic. sometimes it does make sense to reinvent the native interactions and build one's own. It's doable (and not uncommon) but I usually recommend it not be the default approach if for no other reason that it leads down a path of extra code production, testing and maintenance. –  DA01 May 15 '12 at 20:35

Reading GP89 answer having seen users try to highlight or even delete placeholder text does seem to strongly suggest removing placeholder on focus and not on start typing be better.

Also as placeholder SHOULD be used as a minor help anyway I personally don't mind really.

Problem seems to be though people are using it as a replacement for labels which clearly placeholder is not. Any form which may be re/prepopulated with actual content which then of course replaces the placeholder is unusable without labels. Even a simple login form (user + password) may be prepopulated if e.g a validation message is shown after submit (maybe unknown password, and yes I know, not the recommened way to do this but best example I could think of just now). The example forms above seem to use exactly this false usage... :(

share|improve this answer

The best approach is to avoid using placeholder text at all. There's plenty of evidence that many, many users won't understand that it is a placeholder (see the answer above for an example) and will become confused. It's a bad pattern and is completely unnecessary.

share|improve this answer
    
+1 I completely agree that using placeholder in most cases is the bad practice. But there are some cases when using placeholder is good solution. Example: login form in the topbar of the site. There are no extra space for labels and it is better to use placeholders in this case. –  webvitaly Sep 5 '12 at 13:19

Most of the answers here deal with forms with multiple inputs. There are certainly some scenarios (using an input for a search field) where there will only be one input on the page.

In this eventuality I find it would be better to remove the placeholder on focus. The user knows what was just in there, and leaving it in place can confuse them.

share|improve this answer

Chrome way is better, generally. It also depends on the context, however. Ther are times when a placeholder text might be so important that it is advisable to have the user manually delete the text themselves (edge-case).

Proper use of labels should help the user and prevent dependence on default values within fields.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.