Hacker News Reader

Comment by cantlin | Hacker News Reader

It can be done right.

  * Use label tags in the initial render, JavaScript them into placeholders.
  * Do not remove the placeholder until the user has both focused and started typing.
  * Try and animate the placeholder to a safe location rather than removing it.
  * Restore the placeholder if the user pauses after removing their input.

Personally, I favour example input in my inputs (as the author suggests) rather than embedded placeholders. Still, I can understand the assault on clutter from many designers, and I don't think the technique is so much bad as open to crappy implementations.

View on HN

open to crappy implementations

I think that is the key point. A conventional label is simple and doesn't need all this extra support to be helpful to the user. I've never really liked the "label in the field" trend except in really simple forms where there's almost no chance for ambiguity anyway.

As one of the commenters on the linked article points out: this still breaks if you try to drag and drop text into the textbox unless you've been very diligent with the events to move the label out of the way.

I never really thought why they were called 'placeholder' before but it makes sense; they are not labels, they are examples.

I've seen placeholders implemented as a separate element, positioned over the input with CSS, which neatly sidesteps most of the issues caused by having the placeholder text actually as the input value. It has its own problems, no doubt, but seems to work a lot better overall.

I still wouldn't. Usability studies have shown that forms which have the labels right above the input field get filled out the most and filled out correctly the most.

Everything else (like putting the labels to the left of the field or in the field) and you start seeing errors increase in form submissions. So it is to be avoided.

That depends. I worked at a company where we revamped the entire checkout process including putting labels inside the input field and we had a significantly higher conversion rate than using the standard checkout forms one would find on a typical checkout process we had before.

Part of that was simplifying the look of the checkout, which includes putting the labels inside of the inputs.

Not to mention some very notable websites use this design choice, including Square, Twitter, and Apple.

Comparing conversion rates of a complete before and after revamp won't tell you anything about the effectiveness of individual components of the revamp. You'd need several A/B tests or a gradual series of changes to tell you whether labels inside or out actually made a difference overall.

I know it's a silly argument but: do you think Facebook have made some A/B testing for their registration form ?

Because they seems to think that the placeholder as label works well [0].

[0] https://www.facebook.com/

Interesting - do you have any links to the studies you mentioned (not doubting, just curious)?

I remember 1 or 2 were from UXMovement.com and others from all over the place, usually developers who run A/B tests and report their results on the site's blog.

There is another point:

    * Don't make your label use the same style as user-entered text.

I remember encountering a website that failed to do this, while satisfying all the other points. It was super confusing to learn that the texts were just labels and not pre-filled values, since they had the exact same color as the text I entered (unlike HTML5 placeholders that are dimmed).

I wouldn't call that right.

Plus it will hurt your SEO. All the search engine sees is some form fields and little else.

I created a jQuery plugin for just this: https://github.com/remybach/jQuery.superLabels. It takes things like the placeholder into account (which is way too often abused).

> Try and animate the placeholder to a safe location rather than removing it.

There is no try.

If you cannot move it to a reasonable location, do not use this method.

Also, on other note: username is Not an email address. Do not ask me for my username when you really mean email address.

Oh, and one more thing. Let me know (or make it easy to find out) what special rules you require for passwords on your login page. Your site is annoying because you probably require some special combinate of letters and numbers and possibly something else, which means I have to figure out which password pattern I should be trying.

> Also, on other note: username is Not an email address. Do not ask me for my username when you really mean email address.

Are you saying that sites should allow users to use email addresses to log in, rather than usernames? As I understand it, the former is a more recent thing.

I think they're saying that if a website requires an email address to login, they should label it as email address instead of username.

I can't stand it when I try and log in to a website and fail 4 times. Then finally click "Forgot Username" and all that pops up is a box saying my username is my email address.

Exactly this.

To add to the mix my personal pet peeve is to not qualify that my password and password confirmation aren't equal before you submit the form and I then have to retype both and possibly lose other information that I have typed in like creditcard details. And don't get me started on sites that don't allow special characters in their passwords...

So instead of a very simple and straightforward html tag you propose a full js module and animations and so on?

And all this just to remove an important cue from the sight of your users?

Reply on news.ycombinator.com