Is it good idea to put form labels inside input boxes? In this case, the labels slide out of the way when the user clicks on the box.
The sliding labels are completely gratuitous. Instead of sliding out of the way, why don't they simply stay out of the way all the time?
If there's not enough room for them to stay outside the field, they could stay in the field but disappear when you focus in the field.
Your sliding labels example suffers from the same problem as every other clever label-moving/fading hack: It doesn't work if you drag text into the field. Try it - what a mess.
In terms of evidence arguing one over the other? I don't know of any.
In terms of opinion/what I've seen...if data being entered is readily identifiable (ie, email addresses look like email addresses) then I'd say it's OK.
I've used it on very long forms to help visually shorten the appearance of the form but even then only in fields or groups of fields where the data becomes rather self-identifiable such as an address block. Apple uses this format in their checkout forms.
At the time I wrote the answer, I wasn't aware of any data, but we recently had some user testing done and we came back with some surprising data. We found that there was an overwhelming majority that were indifferent to whether the labels were in the fields vs. above the field and that neither was significantly better/worse than the other.
Again, we're using it in very specific scenarios (namely blocks of data that can readily be identified via their contents) and we're not doing the sliding thing that was originally propose in this thread (which I agree is rather pointless). But we were surprised that it really didn't matter, at least in our test group.
Based on nathan's question, I should probably clarify the method we're using.
By default, we're rendering standard markup. That means a proper LABEL tag and input tag:
Then, via CSS we position the label on top of the input (which gives an appearance of the label inside the form field).
If they delete the data, we return the the label.
In otherwords, we're not pre-populating a value in the input itself to act as a label...which is something I would recommend not doing.
1) My concern would be the label tags that aren't being shown. They technically could be styled way off screen so that screen readers use them but sighted users don't see them. They must be there linked to the ID, else they fail accessibility.
2) Glen's concern, that they have to be scripted to not show the value on focus, else for me, it fails
It looks clean, but you'd need to take the extra coding steps to make it usable and accessible. I'm OK with submit because most users have seen it over and over, but I prefer other terms.
I don't like the button labeled "Submit" personally. Unless it's a bondage S&M site.
Overall, I think it doesn't matter that much. Graphic designers should have it in their palette of choices.
|show 6 more comments|
The idea and many of the responses to it miss the point.
Users don't like forms. They only fill them out to get to something else: a product or a service. So our aim, as designers and developers should be to get them through the form as quickly, easily and painlessly as possible.
Research shows that people's behaviour when filling out forms is very different to other web-based interactions. Form-fillers are field focused (SlideShare presentation). They only look at surrounding text as much as they believe they have to, in order to be able to provide a good-enough answer.
This "sliding label" approach — as well as the placement of labels inside fields — hampers this user behaviour:
Moreover, there is plenty of evidence — for example, "Don’t Put Hints Inside Text Boxes in Web Forms" on UX Matters — that people will often mistake the label for completed field, leading to loads of validation errors.
None of this even touches on all the implementation and accessibility issues.
In short, you might think it looks slick, sexy or cool, but it creates a worse experience for the user than current convention. So, unless you're designing or developing something just for yourself, you shouldn't consider it.
I don't think it's a good idea. The problem I see is that when the user finishes filling up the form and scans it for eventual errors, he won't be able to know which field meant what.
It is of course obvious for most of the fields, and would probably work without problems on simple forms, but on the more complicated ones it could be a potential issue.
Also, bear in mind that if you have anything else in the form besides text input fields, you will have to put labels on them. This will result in a loss of consistency. (If you have labels on left then there will be blank spaces and the user will have to shift the gaze from left to right to actually know what he is filling in. If you have labels on top then you will end up in a weird spacing between fields.)
Fad its not worth worrying about - put two identical form structures up, one with and one without and multi variant test for evidence in the specific site you want it to work in. If you see a higher completion rate with one you could claim, although its tentative at best, that’s the one you should go with.
Evidence is king here, I think it looks and feels a bit naff but that’s just subjective. If your users are lots of people like me you’re on to a looser. What would be really interesting is if you push the engagement beyond needing the form in the first place. But hay we must ask questions and a form seems like a simple way to do it.
I have seen an interesting approach here:
Here's an insightful article that talks about what you should do if you want to pull off putting labels inside textboxes successfully. Well-worth reading.
Quicken was the first application to use this technique. They used it for a fill-able check form.
I remember building a Delphi custom control to mimic this behavior back in 2002.
Personally, for the web, I don't like it, for the desktop, I don't see a problem with it.
I understand this question is more about theory and is probably looking for data supporting a answer, but I just wanted to add that if you do go for the ghosted, suggestive label, JLabel, a jquery plugin, will get you the functionality based on good standards with some nice added options (like a nice fade) so you can at least test it on your future/current users (which is probably the best way to answer your question anyway, right?)
Good luck :)
I like the clean aesthetic and visual mapping of putting a field's label right in the field itself.
I think this is great for reducing clutter and visual noise.
However, I have found that if the label is not always visible, somewhere, that some more inexperienced users/visitors will often get frustrated because there is nothing to visually remind them of what type of input is expected in the field that currently has focus.
So, since the label is critical only before the user clicks (or tabs) inside the form field, I solved my issue by simply moving the label, permanently to the right side of the form field. UNless they empty the field, in which case I simply move the label back to the left.
The text is lighter in color than the user's entered value and so it does not collide with the user input. This works only if you do not have form fields that are really narrow. Although, I have found that form fields using this technique are at least no longer than their traditional label-on-the-outside bretheren, so it does work in most cases.
As always, there is no one single solution for all cases... but I love the fact that my forms can now be much more visually organized and less cluttered.
Here is a link to a short form that shows what I am talking about.
It works for long forms as well, but then it will not work for ALL long forms.