Labels in input fields aren’t such a good idea | Hacker News Reader

Labels in input fields aren’t such a good idea

laurakalbag.com

194 pointstalmand93 comments

You can have the best of both worlds (quick and dirty):

    <body>
    <form>
        <div class="cool-label">
            <label for="name">name</label>
            <input id="name" type="text" placeholder="John Doe" />
        </div>
        <div class="cool-label">
            <label for="email">email</label>
            <input id="email" type="text" placeholder="john@doe.com" />
        </div>
    </form>
    </body>

    body {
        background: #eee;
    }
    
    form {
        width: 250px;
        margin: auto;
        margin-top: 50px;
    }
    
    .cool-label {
        border: 1px dotted rgba(0,0,0,.3);
        background: #fff;
        margin-bottom: 10px;
        width: 100%;
    }
    
    .cool-label label {
        width: 60px;
        display: inline-block;
        text-align: right;
        float: left;
        height: 100%;
        margin-top: 5px;
    }
    
    .cool-label input {
        border: none;
        background: transparent;
        width: 175px; /* 250-70-5 padding */
        padding: 5px;
        padding-left: 70px;
        margin-left: -60px;
    }
    .cool-label input:focus {
        background: rgba(0,130,255,.1);
        outline: none;
    }

Nice. But...

You can use the labels themselves as the container for the inputs which leads to simpler markup by removing the divs. Not that it makes much difference in your example though.

http://jsfiddle.net/UMfAy/3/

Sorry but no. We are used to boxes surrounding actionable fields where we can type in content. Here your pseudo-fields is half editable, half not editable, which is weird. The "delimiting an active field" purpose of the visible box is broken.

Maybe if you are Amazon or Google, you can try to implement such a thing, if you have strong reasons to believe it will help users. But if you are not Amazon or Google, you should avoid surprising your users with some weirdness, and just stick to proven UX.

Pretty sure that UI concept is widely used. In fact, if your second paragraph had started "Maybe if you are Amazon, Google, or Apple"...

http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/...

I think the iPhone counts as "proven UX".

The fields you present in the picture aren't editable?

In that particular screen, no; but putting a row label inside the row is the standard method of building editable fields like that.

D'oh, you're right. I was looking for an image quickly. However, editable fields look exactly like that.

Another reason not to do this: browser autofill. Now and again, the browser will guess wrong on what value to insert, and now the user won't know what's supposed to go there. Even if they clear the value, no user will assume that de-focusing the input will reveal the label.

I don't know for others but both Chrome and Firefox hide the placeholder only when the input value is non empty.

So it do not disappear when to give focus to the field.

Yes. But, it doesn't reappear as soon as you remove all text. The placeholder reappears after you remove the text, and change the focus.

It does reappear as soon as I remove all text under firefox 16 and Chrome 24 at least.

Exactly. Off late, I have been running into this issue a lot.

I use Lastpass to manage my authentication information, and I always let it auto-fill new signup forms. It's an incredibly smart piece of software, and gets things right most of the time. However, on occasions when it doesn't fill up a everything correctly, not having a label is a big disadvantage. I have to first clear out the text, de-focus the form-field (Tab or Shift+Tab), then read the field name and come back and fill up that field.

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.

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.

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

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.

I wouldn't call that right.

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

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

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?

The video learning site "lynda" has a really good set of videos on this: "Web Accessibility Principles" and "Improving SEO Using Accessibility Techniques."

Essentially they teach you to build web-sites for disabled users and at the same time for search engines. The gist is that search engines really ARE disabled themselves, they're somewhat blind and dumb.

So you really start to think about how information is presented on your site for more than just the fully-able users and when you look at "tricks" like putting labels within the placeholder element you immediately/instinctively know it is going to cause problems (for SEO and disabled users alike).

Worth checking out if you're interested in this topic and have a "lynda" account.

Yes, really bad trend. In addition to the usability issues the article mentions for sighted users, using placeholder without labels leaves screen reader users without any clue what the input is for.

Good point about the screen reader. I've never considered it before. Thanks.

Personally i dont like using labels and instead use placeholders with tooltips in my forms. But now i might have to reconsider that approach.

It's all fun and games until the National Federation of the Blind sues you...

Does the ADA apply to websites hosted within the US?

Some quick Wikipedia research suggests to me that it depends on the exact circumstances, but in general it seems that any prominent company is vulnerable to lawsuits over website accessibility.

http://en.wikipedia.org/wiki/National_Federation_of_the_Blin... http://en.wikipedia.org/wiki/Access_Now_v._Southwest_Airline... http://en.wikipedia.org/wiki/Ouellette_v._Viacom_Internation... http://www.dralegal.org/impact/cases/smith-et-al-v-hotelscom http://www.w3.org/WAI/EO/EO-Policy-USDOJ

The courts seem to think so

http://www.dba-oracle.com/oracle_news/news_web_sites_ada_com...

http://www.law.com/jsp/article.jsp?id=1202424114568&Sett...

http://www.webstandards.org/2006/02/14/nfb-vs-target-in-pers...

Aside from the other problems, placeholder is a standard attribute. If it is problematic for a screen reader to read that attribute, wouldn't that be a problem with the screen reader, not the HTML page?

Except that placeholder != label, semantically.

The spec says:

    The placeholder attribute should not be used as an alternative to a label. For a longer hint or other advisory text, the title attribute is more appropriate.

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

What about this solution: http://stackoverflow.com/a/1755802

Have labels, but hide them with css.

http://davidwalsh.name/html5-placeholder

Placeholder attribute in HTML5 handles this right - if you don't have anything in the field, it reverts to the placeholder text.

That's only half of the argument. The other half being that, after having text in there (say, in the edit form of a CRUD app), your user no longer remembers what that field was supposed to represent to begin with.

Probably browser-specific, but some browsers will show the placeholder or label with a hover, as well.

But hovering to see the label is not intuitive at all

It's not? The world of computers is filled with hovering for descriptions and details.

It is but an input field is not really an element you would hover for more info. If additional info for the user is required, some question mark icon next to field does the job well because it yells 'hey! something might be confusing or not so obvious'.

I might be an exception but can't recall a case when I would hover input field.

Yeah but that doesn't make it a good idea.

Requiring users to hover to determine the context is a horrible UX. Tooltips/popup descriptions should only be used to provide additional information that isn't required.

You can set the title attribute to the same as the placeholder.

You can't really hover with your finger on an iPhone.

I once ran into this problem of disappearing labels in the input fields leading to incorrect submissions.

The design didn't allow for proper labels, being a standard first name and email address form in a small space, and the client wouldn't budge on it. Often we would see people putting their email address in the first input field. Eventually I used the email address verification Javascript from the second field on the first field. If an email address was found, it alerted to point that out and asked for first name in the first input while moving the email address to the second, correct input.

I wrote an iPhone app with placeholder text, but users kept leaving fields blank, thinking that the app was autofilling them.

Ended up ripping all the placeholder stuff out.

Congrats for realizing and fixing it.

A related problem: Chrome starts with "about:blank". When I start typing, it doesn't go away, so I have to manually select the text before.

Before we let the pendulum swing from one cargo cult to another, let's simply recognize that there are often more cues involved in conveying an interface's intention.

A login form will be accompanied by a Login button, for example. In this case, the intention of the two preceeding input fields should be obvious. (A well-designed site would permit any unique user key, including email and username.) Placeholders, in this case, are generally acceptable.

At the other extreme, a customer information form would have to rely more heavily on explicit, rather than inferred/implicit cues. This includes labels, and their heavyweight siblings, descriptive tool-tips and sidebars. Very complex forms may require extensive documentation.

Most problems have a whole spectrum of possible solutions, supported by a wide variety of tools. Don't let a single aggressive voice narrow your understanding of that.

I'd accept placeholders as labels the day I see a reason to remove labels. And, no, fashion is not a reason.

Well your response implies the reason is stubbornness, and definitely not, as you say, fashion. The parent makes a great point and there are so many times when we're exposed to articles like this that promote a certain view as being the one true way. The original article makes some great points but so does your parent. If there's any wrong take on the labels vs. no labels debate its taking any one side at all. The right thing lies somewhere in the middle.

So everybody is right, everything is relative, and so on?

Sorry but no. In some cases, maybe in most cases, the right thing in not in the middle. For example: having or not ads on Wikipedia, using or not useless animations in websites, allowing or not third-party to access private data, etc.

So, removing a useful cue for user without strong reasons to do so is not "somewhat right", it is just wrong. It is a sin, and will send you to designers' hell (which is a room with thousands of 30' screens on the walls displaying random websites from 5 years ago).

> Well your response implies the reason is stubbornness

I don't think so. I think he was trying to imply that there were objective reasons why labels are a good UI feature and that getting rid of them is unwise, even if it IS fashionable lately.

That is true of a lot of things in UI design. UI design is human enough that it IS affected by things such as fashions. But sometimes people forget that there are real, meaningful differences in usability, and often the "traditional" way of doing things is traditional for a good reason.

My own pet peeve in this regard? Menus. Microsoft office has made "ribbon" style interfaces quite popular instead of using menus. But menus had some important features: you could search through them exhaustively (at least the menus that aren't context-sensitive), and you can use the menus to incrementally learn the keyboard shortcuts for the features you use most often. Ribbons look nice, but they can't teach you to be faster.

A well-designed site is not distinguished from an not-so-well-designed easily. There have been times where, during on of my haphazard working days, I come back to the (already focused) login form and forget whether the form asked for username or email (despite the fact that the form would have accepted both).

> A login form will be accompanied by a Login button

Forgive me for this tangent, but please please please follow the above advice. I've had it with login and search forms that replace their submit button with javascript.

See my demo: http://jsfiddle.net/VtAAs/7/

That's an interesting concept.

Thanks... It was an idea I had a while back and hacked together quickly as a proof of concept. Didn't know if anyone would find it interesting.

Speaking of this, what's the simplest way to add in-field labels to an existing form?

(Assuming in not worried about the issues in this article)

Just set the placeholder attribute. You'll need some js if you want to support browsers which do not process the attribute.

I use Jason Garber's jquery plugin to imitate placeholder for browsers which do not support the attribute.

Are you asking about adding in these labels to an existing form with HTML that you cannot change? Meaning, running Javascript across the form to inject placeholders into the existing fields?

If you're using jQuery, check out my plugin: https://github.com/remybach/jQuery.superLabels.

We had the same problem and our frontender came up with a nice solution. The label is inside the textfield but when focused, the label moves to the right of the textfield. An example can be viewed here: http://www.rainpharma.com (the form in the center of the page)

It causes a bug on the iPad browser: when tapping the field, my cursor goes to the right side, within the label.

Which brings me to my opinion: often it is better to just not mess with things like this. Keep it simple.

Only good for simple login form of two fields. Most everyone knows that is login name and password.

Ah, but was the first form username or email? You have to unfocus the input to check.

Also do I have to add the @domain.com in my web email login or does it know because it's a hosted service? As a user I'm confused.

If it's a single-domain hosted email provider, a well-designed system would accept either the local part or the full email address, but using the full email address would avoid problems in the future in case the service expands to a second domain.

The local part of an email address is not an email address. If it asks for an email address during login, assume it means an email address.

You can always prepend the form input with an appropriate icon (or even text).

http://fortawesome.github.com/Font-Awesome/#examples

Umm it starts with a placeholder so you know if it's user name or email. If you get it wrong an error is displayed. Kind of hard to mess up a login form.

A trend that I just adore is letting people log in with either username or email on the same form, so it doesn't matter.

This claim is useless without any data backing it up. Where's the proof that this is even an issue? If you're targeting screen-readers, then that's a progressive enhancement issue. If you just want to guide the user, then work on giving the user more information sooner.

edit: I'm not saying you should use placeholders as replacements for labels, this will probably invalidate your HTML.(guess). I'm saying this is not a very good point until it's proven to actually get in the way of the user experience. I don't think we should treat our users like idiots, because they're not, so any time that gets included in a design decision, (the assumption that our users are dumb), I already know it's a bad one.

Plus, if you have too many fields in your form, that you need to start adding labels for clarity, you should probably split that up and multi-page it.

It adversely affects screen readers, so on the outset it is an issue. But the post is about the qualitative nature of the problem. I suppose this manifested as a quantitative problem with the time-to-complete task increasing.

I agree it would be nice to see an actual user study comparing task completion time. I'd imagine there's already something in SIGCHI on the efficacy of disappearing prompts.

It does affect screen readers, but that's a progressive enhancement issue. You shouldn't be degrading the experience for someone who does not need one.

Supporting screen reader users is not "progressive enhancement", rather, it is basic and essential.

"Progressive enhancement is a strategy for web design that emphasizes accessibility, semantic HTML markup, and external stylesheet and scripting technologies. Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth."

http://en.wikipedia.org/wiki/Progressive_enhancement

@steveax, you're misunderstanding the concept. The idea is that users with screen readers will see labels, but those who don't can omit them. Progressive enhancement means building for screen readers first, for example, and progressively enhancing the experience for those who can support it.

You forgot to include this part, bro. "... while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth.""

The key phrase there being: "allows everyone to access the basic content and functionality". By not using labels you are excluding screen reader users.

The technique in question here is omitting labels and relying upon the placeholder attribute only.

If you're suggesting that a JavaScript technique could hide the labels for non-screen reader users, how exactly do you intend to determine that? (hint: it's not possible)

window.navigator, but this example works with chrome.

http://jsfiddle.net/LQ8Af/1/

window.navigator is useless as screen readers run on top of the browser. If you know that little about screen readers you probably shouldn't be opining on a11y issues.

Screen reader will still read the label element because it's in the dom, right? It was about whether having labels lead to more user errors, not about omitting then from the DOM?

If that's true, then yeah, that's a terrible idea. You should never omit it from the DOM. I like to use icons to substitute for label text and just pack all the information I can into the legend. Text as a label is what I'm debating.

Your image failed to load (for whatever reason; don't count on a refresh to fix it--the failure may have generated a 404 that's neatly cached by my ISP). My browser doesn't display ALT text for dimensioned images (or the ALT text won't fit in the image placeholder area). I don't use a screen reader, and I'm not an HTML-savvy user. Now what?

Accessibility first — it affects a lot more tan disabled users. Usability second. Pretty if you have time, and only insofar as it doesn't interfere with the first two.

This claim is useless without any data backing it up.

It should be OK for a person to express an opinion or preference without being immediately dismissed as being useless because there's no data backing it up.

You can't dismiss my opinion because your feathers got ruffled either. I still think this is more looking at notable examples rather than the typical example.

I fail to see the claim, well, maybe the title. The article comes across as an opinion to me. You can have your own opinion as well, but I'm not as quick to label your opinion useless as you are to label her's.

I didn't track and keep statistics on the matter, but I have encountered the very thing that author describes. Inputs that used placeholder tended to have more errors than ones that did not. Take the statement for what you want but in my experience I would avoid such things in my future projects.

Using placeholders as labels will not invalidate the HTML, it is a valid thing to do. This is not a debate over the validity of doing such a thing, but whether it's a good idea.

It's not saying that your users are idiots, but sometimes you do have to design/develop for the lowest denominator in the group. But then you always have a level of "can't make everyone happy".

Most cases of UX I've seen suggests that reducing the number of pages in submitting form data increases submission by reducing fatigue, confusion, and frustration. Think disappearing labels might be an issue for someone then find out what happens when the visitor can't remember something they filled in the page before; or worse, three pages ago. If there are too many fields on the page then you're better off trying to reduce the number of fields involved. Maybe get the bare minimum now and ask for more later after the form has been submitted.

Correctly used labels improve conversions.

Reply on news.ycombinator.com