Recently, I received the good news that one of my columns is in the UXmatters All-Time Top 25: “Don’t Put Hints Inside Text Boxes in Web Forms.” That was an unusual article for me because I came straight out and said, “Don’t.” Not “it depends”—just “don’t.” And it generated a lot of discussion—none of which changed my views.
So, I’m going to do it again and say, “Don’t put labels inside text boxes.” Well, okay, what I’m actually going to say is, “Don’t put labels inside text boxes—unless you’re Luke Wroblewski.”
And now, I think I’d better explain what I mean.
Champion Advertisement
Continue Reading…
Why Do Some Forms Have Labels Inside Text Boxes?
If you’re designing for a cramped mobile screen, space is at a premium. It almost seems wasteful to leave text boxes empty just because people need to type into them. Why not compress the space that they require by moving the labels into the empty boxes?
Text box labels are an extra design element on the page. They vary in size and can look messy. If you move them from the whitespace into the boxes, the form immediately looks tidier.
What’s Wrong with Labels Inside Text Boxes?
So, what’s wrong with putting labels inside text boxes?
I’m a forms geek: I browse the Web looking for forms—just so I can fill them in and capture screenshots for my collection. I know that’s very strange behavior.
What’s normal behavior? People encounter forms when they’re trying to do something other than fill in a form. They have a goal. Their particular goal means they have to interact with an organization. The combination of a person’s goals and the organization’s goals creates a relationship. Interacting with the form creates a conversation that happens within the context of the relationship. And that conversation goes something like this:
“Okay, I’ve got to fill in this form.”
“In which boxes do I need to type something?”
“What have I got to put into those boxes?”
When people are trying to accomplish a goal, their focus is not on the form an organization requires them to use. It’s on achieving their goal.
The Space Inside the Box Is for the User
The space inside the text box is for the user; the space outside the box, for the organization to explain what goes into the box. That is what Google has trained us to expect on the Web, as Figure 1 shows.
Figure 1—Google started training us to look for the box to type into in 1999
Hints in Boxes Seem Like Default Answers
People frequently misinterpret a hint inside a box, like that in Figure 2, as a default answer. That text is in their side of the conversation. Don’t believe me? Have a look at your logs.
Plus, if your implementation doesn’t always succeed in removing hint text from a box, I’ll guarantee that a depressingly large proportion of initial submissions of form data will include that hint text.
Even if your implementation always does remove the hint text properly, I’ll guarantee that a depressingly large proportion of initial submissions of form data will include blank entries for fields that previously contained hint text.
Figure 2—A hint inside a text box
Labels in Boxes Mess Up the Conversational Turns
Question: What happens to the conversation if you place a label inside a text box rather than hint text?
Answer: The conversational turns get messed up. This is the conversational equivalent of those long-distance calls people used to have, where turn-taking broke down because of delays on the line and both parties ended up speaking at the same time. The same thing happens when mobile phone connections cut out temporarily. When conversational turns break down, a conversation becomes fragmented and awkward. And this is exactly what putting labels into text boxes does with a form conversation: The organization is speaking at the place in the conversation that ought to be for the users. Highly confusing.
People Can Find Ways to Survive Messed-up Conversations
Of course, people are used to surviving strange conversational encounters.
Survival Strategy 1: Ignoring the Labels
If you’re presenting a form that people will use a lot or a form that follows a very familiar pattern—such as user name and password—users can sometimes learn what goes where and ignore the labels. This is somewhat similar to the way that people have learned to ignore another Web annoyance, the intrusive banner.
At this point in my writing, I thought, I must show an example of a label that gets ignored. So off I went to my browser to hunt around a bit for something suitable. The page I looked at happened to be on Twitter.com, where I was genuinely surprised to discover a label inside the Compose new Tweet box, shown in Figure 3. That’s a label I’ve learned to ignore, so I saw it only because I was looking at the page with a different goal in mind.
Figure 3—A label inside the Compose new Tweet box on Twitter.com
Survival Strategy 2: Interacting with Caution
Another survival strategy is for users to become very cautious about interacting with a form. Similarly, during a broken mobile conversation, people have to interrupt their normal speaking rhythm, wait cautiously, then use explicit cues like “You go ahead” rather than just relying on the usual natural pauses to indicate turn-taking.
On a form with labels inside text boxes, users become cautious. They take extra time to look ahead and read the labels. They think twice before clicking. This caution is a problem because it’s distracting. It adds extra cognitive load, consuming people’s valuable brain power to figure out an interaction when they should instead be able to devote it to thinking about the questions and answers on the form.
Survival Strategy 3: Struggling Through
Another survival strategy is to just struggle through. For example, a user might pogostick into and out of the form, to get the labels to refresh. Laura Kalbag describes some fun examples of the struggle-through survival strategy in her article “Labels in Input Fields Aren’t Such a Good Idea.”
Survival Strategy 4: Giving Up
And the final survival strategy is giving up. Do I have any evidence of lost conversions that were the result of labels being inside the fields? Sadly, no. I’m pleased to say that my clients all agree that labels inside boxes are a mad idea; they don’t want to expose their users to them just for the sake of my desire for an A/B test. I’ve delayed writing about this because I wanted the evidence, but I eventually realized that, if I published without it, that might persuade people who have the data to share their findings. So if you’re tried it, please comment.
The nearest example that I have been able to find is one from the Web site Which Test Won. It compared a search box with the label Search inside the text box to one whose label was outside the box. You might consider that to be a test of either a hint inside a text box or a label inside a text box. Given the theme of this column, you can probably guess the result rather easily. But go try it for yourself over at “Search Box A/B Test—Which Increased Revenue Per Visitor?”
Why Does Luke W Get a Free Pass?
My practice is mostly in designing and testing complex forms and long surveys. I don’t get much opportunity to work on short forms or cutting-edge mobile applications. So, naturally, I wanted to check what Luke Wroblewski has been saying recently about all of this, because he’s the thought leader when it comes to exactly these topics. Truthfully, I was taken aback when I read this:
“Though top-aligned labels work well within the tight constraints of mobile screens, labels inside input fields can work even better.”—Luke Wroblewski, Mobile First, 2011
Oh, no. “Can work even better?” For whom? Then I read on and found that Luke doesn’t actually say for whom. Instead, he points out:
“As proof, just about every native mobile application platform supports labels within input fields and uses them in their default applications.”
Ah, so it’s not that actually it’s a good idea; it’s more that manufacturers have decided to do it and others have followed their lead. And of course, we’ll all get used to whatever the key providers force us to get used to—in exactly the same way that Google has trained us that a single empty box on a screen means search. Similarly, countless applications and Web sites have trained us that two empty boxes that are stacked one on top of the other mean sign in using your user name and password.
Maybe we’ll all just get used to disappearing labels—or labels that don’t disappear when they should, so get muddled up with our answers. Or maybe not. Luke goes on to say:
“On the Web, however, implementing labels within fields requires some work.
“Though labels within input fields seem great on the surface, there are some challenges to overcome. A label within an input field:
Should never become part of someone’s answer. This seems simple enough, but still happens quite frequently when things haven’t been loaded or aren’t coded correctly. Ever try searching only to find the word search has become part of your query?
Should not be confused with an actual answer in an input field. If labels and inputs look too similar, people might (rightly) assume an answer has already been provided for them. I’ve seen this happen too often in usability testing.
Is usually absent when someone starts answering a question and when they finish answering a set of questions. This can make it harder to know which question is being answered or to go back and check answers after the labels are gone.”
Phew, that’s a relief. Luke and I agree on the key points. And given Luke’s many triumphs in creating wonderful stuff, I have complete confidence that, if he decides a design would be better with labels inside the fields, he’ll make sure that whatever gets delivered will indeed be better with the labels like that.
Should You Put Labels in Text Boxes?
Now, be honest with me: are you Luke? If not, can you answer yes to all of these questions?
Are you in control of the design and delivery process? Will it happen in the way you decide it should happen?
Are you in control of the maintenance and update process? Will things continue to happen in the way you decide they should happen in the future?
Are you willing to stay in control? Do you want to make it your mission to police all of the different individual forms, queries, parts of applications, surveys, and other places where input happens to make sure that those labels inside text boxes always work the way they should?
If you’ve answered no to any of these questions, are you really, truly sure that you’ll be able to achieve an implementation of labels inside fields that is sustainable? Well then, why not just put the labels outside the text boxes and make life easier for yourself and the people who’ll use your forms?
Conclusion
In summary, don’t put labels inside text boxes in forms. You’ll interrupt the conversation and put barriers between people and their goals that don’t have to be there.
There could also be instances where people require help or assistance with formatted input. In the instances of formatted date entries where keying-in data would prove to be faster than picking from a calendar, people look for the dd or mm or yyyy cues next to, or outside of, input fields. Also, labels within input fields are not suited for situations when the user’s task gets interrupted, which is always a possibility. In such cases, people would have to remove a partial entry to bring the label back again, which is in direct conflict with their mental model.
Managing real-estate challenges shouldn’t be done at the cost of compromising usability.
I find this article a little puzzling, largely on the grounds that, while it’s perfectly logical what you’re saying here, I don’t see any empirical evidence to back this up. In particular, with Luke’s comments, all three of the quotations you’ve listed don’t suggest that placing labels inside text boxes is bad, but that it has the potential to be bad if used incorrectly.
“Ever try searching only to find the word search has become part of your query?”—Well, that’s just bad programming, not indicative of a bad methodology.
“Should not be confused with an actual answer in an input field.”—If it is, then it’s bad design … not bad methodology.
“This can make it harder to know which question is being answered or to go back and check answers after the labels are gone.”—Again, this is a design issue. If the labels are implemented correctly, they should be visually distinct from the content entered in by the user. Faded grey and italics for the label, but solid black and non-italics for entered data can make all the difference.
I think UX, by its very nature, should be based on empirical data about usability. So if inline labels like that should “never be used,” then I think there shouldn’t be any kind of blanket statement that says never, without narrowing down the context. (Clearly mobile is a different element, but tablets and phablets are blurring that line already.) And I would expect to see some kind of usability study comparing the user responsiveness of forms designed using multiple techniques, testing various factors such as the speed and accuracy of data entry, response time, ability to fill in required fields accurately, and so on, for users that have a classic designed form as compared to the same form designed with labels inside the text boxes.
I’d find it hard to accept a “never do this” philosophy without some kind of hard data to back up the claim that it’s either right or wrong to do.
Thanks for bringing this up. The simplest reason I know for why this is a bad idea is: once there is data entered in the field, users can’t tell what they were supposed to enter, and if it’s correct or not. Relying on people’s memory of a UI state in the past is a well-understood usability mistake, placing a huge burden on the user’s memory. Labels are meaningful and mandatory whether the field is blank or already has data.
Also, if the form was presented prefilled—that is, if you’re editing existing data—then the user’s memory isn’t going to help; the only way a poor user can learn what is supposed to be typed into what box is to delete the prefilled data. This is the worst type of arrogance and poor usability: forcing users to learn and accommodate the designer’s or programmer’s design—including learning the program code’s logic and adapting to it—rather than the designer or programmer accommodating the user’s needs and tasks. We all know that the former is bad, and the latter is our goal.
Well, I seriously just emailed your article to our team, so we can test our text within our input boxes.
I also enjoyed how you pointed out how mobile developers put text in the fields, because this seems to be what everyone is told to do. I like challenging convention. :)
Your last point about the fragility of implementation, especially over time, is an excellent one. A lot depends on the context and the platform.
Twitter can make sure their tweet field always works, it’s a core function and they have plenty of resources to devote to it. The rest of us might be better off with a simpler system that won’t break down over time.
While it does help to differentiate system text from user-entered text, the problem with making in-field labels gray and italicized is that makes the labels inherently less readable than non-italic black text. It’s also more problematic to code and doesn’t solve some of the other points raised, such as the loss of reference to the label or help once the user has entered text.
I agree that good, well-executed design plays a role, but I agree more with the author that there just is not a strong enough argument in favor of putting labels in-field to overcome the problems associated with it.
Exactly what Jaime said; if the labels are in the field and disappear, users can’t refer to what was supposed to be in the field or how the data should be formatted. This happened to me the other day as I tabbed through a form faster than my eyes were able to read the next label within the field, which of course disappeared on focus.
To a slightly different argument, but on the same topic, I was helping my dad fill out Microsoft’s account setup form, which uses a mix of labels inside and outside fields, and he got stuck on the phone number field because the label inside the field shows (xxx) xxx-xxxx. He started trying to enter his number in that format and became very frustrated when the field wouldn’t accept parentheses. He was also confused about why it wouldn’t accept 11 numbers, including the 1 for the country code, as this was a separate field—a drop-down select menu with United States (+1) pre-selected. That form is a good example of something that should have gone through some usability testing!
I agree about the lack of testing, so Caroline Temple: thanks so much for emailing your team about this. If you can get some results and share, that would be wonderful.
And then maybe I’ll have to publish a retraction and apologize to everyone.
Steve Pye: I agree with you. I think that a properly designed implementation that has been tested appropriately, definitely works for your target audience, and will be maintained appropriately, using similar techniques, is of course better. So there’s an it depends. But I’m seeing these labels inside boxes everywhere, unnecessarily, with rather poor implementations, and in circumstances where I very much doubt that the design has ever been tested with users. Hence this article.
“’Ever try searching only to find the word search has become part of your query?’—Well, that’s just bad programming, not indicative of a bad methodology.”
My response, based on 20+ years of hands-on experience as a software tester:
A method that is error prone—that is, one that creates an avoidable opportunity for certain instances of bad programming—is a bad method. Good methods make the programming activities more fail-safe, just as good programming makes the user’s activities more fail-safe.
The author made a relatively valid point, while her arguments were poorly supported, either because of a lack of concrete, solid statements or a lack of convincing data.
The example of a JOB TITLE form field with the default hint My Sequence is extremely poorly supported. The problem for that field is not the use of default hint text inside the field; instead, it’s the badly designed hint text content. The UX designer should have put a commonly used, topic-related job title in the hint text instead of putting a non-topic-related, unusual term there.
The drawback I can see for labels inside fields is: users may lose the reference once they type in. However, this problem can be resolved technically by setting the condition that, when the user’s mouse is onfocus, the text inside field is gone; while, when it loses mouse focus—for example, clicks outside the field—the text shows up again for the user’s reference.
As another comment already addressed, we can always use lighter color, italicized text to differentiate the hint text and actual text.
In my opinion, between these two ways of displaying the input field, there is no advantage for one over another. If we use them well, with the right technical functionality supporting them, they both can work well. However, in the mobile world, the label inside the input field can save a lot of precious real estate on the small screen, which may be a good way to go.
For Web applications on the desktop, we may want to combine the two options to reach the optimal result. Use labels outside the form field for simplified action-item names—for example Search; at the same time, use hint text inside the field to give users more instructions on what they need to enter. A good example is: weather.com. The Search label outside the input field gives users the quick action-item name, and the hint text inside the input field Search for ZIP, city, or place (Disney World) gives users clear, straightforward direction without any confusion. A lot of companies also use ToolTips for hint text instead of hint text inside a form’s input field—for example Amazon.com and ebay.com. When a user places the insertion point inside the Search input field, it shows the ToolTip Search for or Enter your search keyword. Either inside the form’s input field or in a ToolTip, they both serve the same purpose, are more user friendly, and provide a better user experience.
In summary, the UX designer can use both ways of input-field label display, and there is no advantage of one over another. However, if we combine both, we can reach better results. In mobile apps, we may want to use label inside input fields to save real estate.
You don’t need to publish a retraction. I have plenty of evidence to share. Let’s tear down one of the problems here:
Affordance is a biggie and not often discussed. Visitors will hunt and scan for entry boxes, as part of filling out Web forms, controls, and other data-driven calls to action.
The problem is, when you put crud in the field, people stop seeing the field or even the structure of the page. This reaction can be very bad for you.
A site I tested with this added a search hint that took up slightly less than half of the search box field. I looked at the ClickTale videos and saw that loads of people were not spotting search. But that was merely an inference from looking at the videos and was a hunch that needed data.
So, I looked at the test results, which showed a decrease in search activity versus controls of over 20%. Hmmmm…
Basically, both the recordings and the numbers said: people are not seeing the search box. Since the site sells complex parts products, it really would have harmed them, because over 80% of their revenue comes from visits where a search and winnow is performed.
In this case, making that change permanent would have resulted in approximately 16% of sales revenue being lost.
I’m also going to cover:
state handling (the problems)
field hints (what works and what doesn’t)
where I have seen it working (very few places)
my summary
I’ll come back with updates on these later—I’m juggling a few projects right now!
@Steve—You make some good points but I think that this is so hard to get right that most people will do it badly. (99% of examples I’ve seen have issues.) The problem with doing any empirical testing is that results will vary depending on the context, copy, design, and many other factors. I know that, if I use light text on light background, people will struggle to read it. This falls into the same ‘the unwary should avoid this’ category.
It’s simply not worth testing something this exhaustively when you know it’s dog poo to begin with. Much of my job is to avoid lab or site testing of stuff that’s just a waste of time—and inline labels fall into that category. I’m not saying that there isn’t an optimal solution—just that I don’t have time to expose people to a sub-par form-filling experience, when I have far better techniques I know work. And the evidence is triangulated for this: ClickTale recordings, analytics data, test results, and much time spent in the lab—all show that putting labels in boxes is fraught with difficulties.
I’d recommend that, like me, you run a test to see how this impacts form fillout, revenue, and other metrics that you track. It’s really easy to design a pig’s ear here—without much thinking. Incredibly hard to get this right.
And if anyone is up for this, I’d be happy to run a controlled test. Good luck with agreeing what to test!
The key reason that convinces me not to use labels inside text boxes is that: People tend to forget or confuse what the text box is for after clicking inside the box, so they have to check again by taking the focus outside the text box.
Emily Zhang: Sorry, but I completely disagree with you. Please read the companion article “Don’t Put Hints Inside Text Boxes,” which is supported by evidence. And also, please read Craig Sullivan’s example in the comments.
Marlon: Thanks for the simple.com example. I couldn’t try it myself, but luckily Whitney Quesenbery was able to send me some screenshots and comments on the experience. Simple.com uses a variation in which they draw an extra line around a label and an invisible box. They seem to be working hard on the test / improve / test cycle for a series of short, well-controlled forms—so they fall into my LukeW exception. I’d love to have the opportunity to test this style of implementation myself. I’d like to see whether users have any hesitation about interacting with this new style of box, which offers no advantage in terms of screen real estate.
Craig Sullivan: thanks so much for providing this example. Glad that I won’t have to publish the retraction yet awhile.
Everyone: Thanks again. Please feel welcome to discuss this with me here, on Twitter, or offline.
I’m in agreement with everyone who has pointed out that users will often forget and be unable to refer to the field label once text has been entered. Another point that needs to be brought up is that of accessibility to users with disabilities.
First, without a reference label outside of the field, users with certain cognitive disabilities will have an even harder time interacting with the form. This is due to the same cognitive load issues already raised.
Second, users with low vision may, in fact, be unable to read the in-field label. Many of you have proposed the solution of differently styled text to differentiate between a label and user input. Depending on color / foreground / background contrast, this may actually prevent certain users from being able to distinguish the letters making up the label.
Finally, there is a huge impact on users of speech output software—that is, software that converts the visual interface into a spoken output one. More often than not, the moment a user enters a field by use of the Tab key, the label text is immediately deleted. This prevents a screen reader from reading the contents of the field, because it disappears before focus is gained. Therefore, a blind user—or a dyslexic user who is aided by the use of spoken output—will have no idea what to put in your forms. There are methods around this, but you might as well have just gone ahead and put the label outside of the form fields in the first place.
I’m blind, and personally, disappearing labels when I start filling out form fields drive me nuts. I have to work a page sequentially and don’t have the benefit of an instant, 2D overview. This got a little better with the introduction of the placeholder attribute on inputs, which keeps the label present for screen reader users at least. But I can come up with several groups of people with disabilities who will most likely have big problems with disappearing labels:
People with low vision often need sharp contrast to be able to read text. So a light-gray label inside an input box on a light background poses an even bigger challenge to them than to ordinarily sighted people.
Many people with dyslexia will also have difficulties in figuring out what went into what field once labels disappear.
So, putting labels inside form fields is an accessibility and usability problem for various groups of people, whose numbers should not be underestimated as potential users, or customers.
Emily said: “However, this problem can be resolved technically by setting the condition that, when the user’s mouse is onfocus, the text inside the field is gone; while, when it loses mouse focus—for example, clicks outside the field—the text shows up again for the user’s reference.”
Besides the fact that the mouse has nothing to do with the focus, this does not solve the problem. It causes a problem: users must play hip-hop pogo to get label feedback. In fact, regarding your idea, most implementations of label or placeholder text in an input box do put the text back in. However, they cannot do this when the user has added their own text. So users have to first delete the text they’ve added, then remove the focus to see a label, so they can then re-add back in their data. This is a lovely example of “ridonkulus,” and it’s not fun, unless your users are 7.
This means users who scan their filled-in form before hitting Submit cannot easily correlate their data with what the input expects.
The way around that would be moving the label outside the text box once the user’s typed something in. But now you’re back at the problem of a fugly interface and clutter, and so why weren’t the labels just there in the first place?
Also, the new-ish HTML5 placeholder attribute lets the browser, or user agent, decide when to remove the hint text. This is somewhat unfortunate: most of the major browsers remove it as soon as there’s focus on the input, but Webkit browsers such as Chrome, Safari, and a heap of mobile browsers wait until there are actual characters in the input—probably because of the problem mentioned by Rachel DiTullio: a user tabs automatically to the next input and then goes to read the label. To fix this, if you’re using placeholder attributes, you need to hijack browser behaviour with JavaScript.
Emily wrote: “A good example is: weather.com. The Search label outside the input field gives users the quick action-item name, and the hint text inside the input field Search for ZIP, city, or place (Disney World) gives users clear, straightforward direction without any confusion.”
This is called “moving the directions from the top of the form to moving it inside the input.” While it’s good to have the added explanation or instructions, and having them in the input rather than above the form probably ensures more people actually read it, it does still come with the usual issues of placeholders listed in the article.
Only for people using mice! Limiting the access of important information to a single type of input device is not a good practice, in my opinion. It also requires the same behaviour as Mystery Meat Navigation: you don’t know what something does by looking at it—you first must interact with it to get the necessary information. Sometimes this is precisely what you want, but likely not in the examples you list.
However, the issue of ToolTips (title attributes) is really a problem the browser vendors need to fix rather than developers. If the developer is creating these ToolTips using JavaScript from scratch, then they can easily make sure all input devices—including fat fingered touchscreens—show the information.
Last year, I had people using screen-reading software test a form and got a strong negative reaction to labels inside text boxes. It didn’t matter whether they were using VoiceOver on the Mac or JAWs with Windows.
I would never put a label in an input field; it’s wrong on so many levels. Trying to justify it because you’re writing specifically for a mobile device, or phone, is pretty lame. Accept the space limitations of mobile devices and program accordingly.
You should always consider ARIA-related issues without being told to do so.
I’m pretty sure that the Luke Wroblewski book, WFD, says that ghost text in a form field is something to consider if things are not clear to users. I don’t think that was a blanket statement.
There are all sorts of good examples I’ve seen of this visual device being helpful. But it’s not an all-the-time kind of thing.
Hi everybody—Anybody got more data from testing on real projects, comparing in-box versus out-box labels? I agree that in-box labels have far more challenges than benefits. Yet, I am just wondering why a digital giant like Facebook has a sign-up process with all in-box labels.
Also Bank of America’s form for opening a checking account has only in-box labels—even though BofA sort of solved one of the major issue by actually keeping the in-box label visible, just less highlighted, during the user’s entering a value. Well, one can argue about the usability of that anyway. But such companies must have tested everything from top to bottom and back, so I struggle to understand that.
I agree with your usability points for the most part. I’ve actually had a lot of good test results with in-field hints, so maybe I favor a hybrid of your position and Luke W’s.
The thing that tripped me up was the fear of hint text or in-field labels being sent back to the server. This was written in 2013? I haven’t encountered such poor engineering and testing practices since the 2000s. For all future readers, if that is a concern on your team, you either need a lot of training for your developers or a new team altogether.
Not ADA Compliant. Several screen-reading devices cannot read labels placed inside text boxes, causing user confusion when trying to complete forms. I work for my state government and have to constantly check usability for everyone.
From a quick browse around their site, simple.com use the label within field for very simple input requirements—for example, a single input for search this site, input email address to get simple, user name and password to log in to the site. They also make the content understandable by the use of labels or a command button suitably labelled.
I have a related question: does anyone have thoughts on showing static, uneditable content within in a field such as a masked user account when all that is needed is for the user is to enter the password to that account? Thanks.
The article is spot on. I recently ran into a usability barrier on a form where the field title was floated over the corresponding field box. When the field was in focus, the title disappeared. I had to click outside the field to understand what data was needed. It interrupted my flow on a desktop browser when tabbing through fields. One could place field labels above each field. Alternatively, follow the Float Label Pattern that Brad Frost has written about to keep the field label visible when field is focused.
Has your stance on this changed since the post three years ago? I can’t find any of the most popular apps with forms that dpn’t put labels in text boxes. Even Google does it now on their Web form!
People are now very much trained to look to the box for direction on what they need to enter. Most forms keep the label text in the box until the user has typed a character, which allows the cursor to be in the box and the label still displayed, which solves most of the memory issues.
Google definitely follows this above-mentioned policy, inserting labels into boxes. Speaking about interruption of one’s work when one must click, the number of boxes has also a very formidable influence for this question. We use it, however.
I have a concept that I would love your feedback on. I wish I could send over a photo but can’t, so I’ll explain. Imagine a text box with a border. It has two lines of space, so it’s a bit tall. The label is grey on the first line and the line below is blank. When you click the text box, the border turns blue and now you can type in that blank line. Does this mess up the conversation? I’m super curious! Anyone else can jump on and give me their thoughts.
When Google launched their Material Design concept, they chose to have hint text inside fields. But once users click or tab into a field, the hint text disappears and becomes label text that animates to the top of the field.
I like this concept because it seems to solve all the issues. What I don’t know is if this is ADA compliant. I’m assuming it is. Google addresses accessibility, but it isn’t specific to hint or label text.
This is kind of an old article, and I was wondering if the writer still believes putting labels or hints inside a text box on a form is a bad idea.
And another question that I have is: if one puts a label inside a text box, what effect does it have on conversions? (Whatever you see as a conversion.) Because in a business, most of the time, you change something only if it has a real impact on profitability!
Just read this in 2017, and it makes me cringe. Why would the text inside the text boxes disappear when the user taps into them? What a strange assumption on your part. The field titles would float up above the field. How is more closely relating the question with where the user needs to type the answer to the question a bad thing?
Your example is a really ugly version of Google from the past. Now, ironically, Google puts no text on the screen—just a flashing cursor in the field, ready to be typed into. It’s time for this article to come down.
Articles on UXmatters are forever. There’s still much useful advice in Caroline’s article.
Your assumption shows a lack of historical perspective. You said: “Why would the text inside the text boxes disappear when the user taps into them? What a strange assumption on your part. The field titles would float up above the field.”
At the time Caroline wrote this article, it was common to see labels merely disappear when a user selected an insertion point in a text box. I’m glad you agree that is bad design. The solution you offer came later, but has it’s own usability issues and isn’t suitable for all contexts. I still see occurrences of the issue Caroline described, as well as text boxes containing labels that remain in a text box after a user selects them, but the latter is probably a result of sloppy coding.
It’s 2022 and everyone has followed suit with Google’s Material guidelines, including major platforms like Shopify.
As Shawn Covely wrote in 2016: “Once users click or tab into a field, the hint text disappears and becomes label text that animates to the top of the field. I like this concept because it seems to solve all the issues.”
The thing is, this only solves an issue that didn’t exist before people started misusing placeholders as labels. There was no issue with labels being located above the input in the first place, besides wanting to cram more information onto a cell phone.
Also, this does not address the issue that users intuitively perceive an empty box as being an input. Text in a square is harder to recognize as an input.
It may be that we’ve forced the issue by doing it anyway, and maybe users have been forced to learn that boxes with gray text are probably inputs. But I don’t agree that this was solving an issue to begin with. Once you focus the input, you have two lines of text anyway—the same as before.
If this was just about saving space, a better alternative might be to just create a gap in the border for the label, like an old fashioned fieldset. This is actually more space efficient than two lines of text inside the input and avoids the confusion created by putting the label inside the box, where it might appear to be prefilled.
In my honest opinion, there was no excuse to start putting labels inside inputs in the 2010s—and there still isn’t in 2022.
Caroline became interested in forms when delivering OCR (Optical Character Recognition) systems to the UK Inland Revenue. The systems didn’t work very well, and it turned out that problems arose because people made mistakes when filling in forms. Since then, she’s developed a fascination with the challenge of making forms easy to fill in—a fascination that shows no signs of wearing off over 15 years later. These days, forms are usually part of information-rich Web sites, so Caroline now spends much of her time helping clients with content strategy on huge Web sites. Caroline is coauthor, with Gerry Gaffney, of Forms that Work: Designing Web Forms for Usability, the companion volume to Ginny Redish’s hugely popular book Letting Go of the Words: Writing Web Content That Works. Read More
