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.
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.
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.
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.
* 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.
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 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.
* 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).
> 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.
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...
> 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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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).
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.
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?
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)
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.
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.
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.
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.
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.
"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."
@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 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 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.
The key phrase there being: "allows everyone to access the basic content and functionality". By not using labels you are excluding screen reader users.
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.
http://jsfiddle.net/UMfAy/1/