

Labels in input fields aren’t such a good idea - talmand
http://laurakalbag.com/labels-in-input-fields-arent-such-a-good-idea/

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

<http://jsfiddle.net/UMfAy/1/>

    
    
        <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;
        }

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

~~~
untog
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/...](http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT4061/HT4061_01-iphone-
settings-003-en.png)

I think the iPhone counts as "proven UX".

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

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

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

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

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

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

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

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

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

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

~~~
byroot
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/>

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

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

~~~
randomdata
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?

~~~
mjhoy
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/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/common-input-element-attributes.html#the-placeholder-attribute)

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

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

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

~~~
gedrap
But hovering to see the label is not intuitive at all

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

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

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

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

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

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

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

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

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

------
bherms
See my demo: <http://jsfiddle.net/VtAAs/7/>

~~~
talmand
That's an interesting concept.

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

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

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

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

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

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

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

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

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

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

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

------
orangethirty
Correctly used labels improve conversions.

