12 Answers
12

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?

+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.
–
tajmoMay 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

6

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?
–
DisgruntledGoatMay 15 '12 at 8:19

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:

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

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.

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.
–
DA01May 14 '12 at 17:00

1

Right, but it's not any less useable this way, right?
–
magzalezMay 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 AttrillMay 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)
–
DA01May 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

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.

User scenario:

The user sees the placeholders each time before filling the field
and understands what needs to be filled

User clicks on the field and the focus makes the placeholder
disappear.

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.

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.

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. :-)

+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?
–
webvitalyDec 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 KastnerDec 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 :)
–
webvitalyDec 19 '12 at 22:03

3

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 KastnerJan 3 '13 at 9:48

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-McKyeMay 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.
–
DA01May 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... :(

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.

+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.
–
webvitalySep 5 '12 at 13:19

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.