Forms. Can’t live with them. Can’t live without them.
What language does your local store clerk speak? Your own language you say. What language do the web forms you build speak? Do they speak the same language as your site's visitors? Your clerk greets you with a smile. Do your forms smile to your clients?
It is fascinating how bad web forms look and work on most sites that are out there. The problem is that they are usually on the last place on the to-do or check-up list, which is totally wrong. Let me explain why this approach is wrong. A web form is practically the clerk of a site, whether it is a simple site or a huge e-commerce website. As you have the clerk in the supermarket to handle check out, you have web forms on the web to handle all sorts of things, from contacts, to payment processing, to newsletters signups and so on. All these features inside your site are powerful tools for your business.
Not caring for your web forms is not caring for your clients! Not caring for your clients is not caring for your business!
Put yourself into your customer's shoes. From now on, you will have to build web forms accordingly, because better web forms will attract more prospects, which will end up in more sales, and better business. This sounds great given the financial crysis that has got many businesses bankrupt.
This article will cover all you will need in order to create useful, beautiful forms. The first part will handle the theoretical part, describing different scenarios and structures web forms could have. The second part will cover the XHTML / CSS implementation of all forms, and the last part will cover the validation and processing of the forms.
If you got here, you know that web forms suck. I don't like them, you don't like them, our customers don't like them. Nobody likes web forms. That usually happens because we don't design them the right way. Most of us make forms to get information about everything, then do something with it when our goal should be getting everybody through the form as quickly and easily as possible. We want a lot of information from our customers, but they are facing a stranger. They are facing a stranger who wants their information. Why should they give it to us.
When someone comes to a form, they want to get passed it and do whatever they were promised to be able to do before completing the form. That's why the number one priority when building a form should be keeping it simple. And now comes the hard part. Forms can be designed in many ways, but which one is the simplest? Well, to tell you the truth, I haven't found the answer yet. But hey, at least I tested some options.
First thing's first. Make sure you strip out content that you don't really need! Don't think about sending an email to your client? Don't ask them their email. Don't want to fax them? Don't ask for fax numbers. Once you have the few questions you really need to ask, you can outline them in different ways inside an online form.
The 4-ways of forms
If you look around all forms on the internet, they all share something. A bunch of them have right-aligned labels, some other have left-aligned labels, some have top-aligned labels, and lately, there's some forms out there that have labels inside the input fields. But which one is best? That depends on the purpose of each form. So lets check out each and every one of them.
Inline labels are great, because they can reduce the amount of space your form spans across. However, these forms are usually handled with a relatively big amount of coding. We have two scenarios for these kind of forms.
Static text within input fields
What happens here when a user clicks inside a label is, well, nothing. Given the "username" field, clicking it means that the user has to first delete the text, and then input his actual username. This is ok for small forms, but doing this on a huge form will definitely scare you off.
Dynamic text within input fields
These input fields work like magic, because when the user clicks the input field, the "username" label text just disappears, and they can input their username quickly. Great.
The downside of both solutions is that we practically cannot use this kind of design on long forms. Short forms like searching or logging could really use this design technique, but long forms no. That is simply because when you're finished and want to check the form before submitting, there's a big chance you don't remember what the questions were.
Pros for inline labels
- Reduce the space required by the form
Cons for inline labels
- Not knowing what you answered for
- Label text doesn't go away, and distracts the user while typing
- Label text goes away on click, and doesn't come back if the user didn't type anything
These forms are best if you request god knows what information, and the users need to check out personal documents in order to know how to answer your questions. Left aligned labels help because all questions are one below each other, and input fields do not interfere. This way, users can scan to see what they are asked for, and get prepared before setting on the quest of completing your form.
The next thing these forms are good at is reducing vertical space. However, if you have long questions, this may be an issue as the width of the form will extend, and sometimes the overall layout of a form could be completely messed up. Nowadays however, browser screen resolution is pretty big, so this issue probably isn't a big problem. But make sure that the percent of mobile visitors is low if you're willing to adopt such a form.
Pros for left-aligned labels
- Reduce vertical span of the form
- Easy scan the questions before doing anything else
Cons for left-aligned labels
- Harder to connect the labels with their adjacent input field
- Increased horizontal space the forms spans on
Right-aligned labels have the same disadvantage as left-forms do, so if the horizontal space is not generous, they are not an option. On the other side, if the left-aligned forms are bad in terms of connecting each label with its corresponding input field, right aligned labels don't suffer from that, as they are inches away from the input fields. However, these forms cannot be easily scanned. Basically, these one are the exact opposite of left-aligned labels. Well, not exactly, but you'll see why further along.
Pros for right-aligned labels
- Reduce vertical span of the form
- Easy to connect the labels with their adjacent input field
Cons for right-aligned labels
- Hard to scan the questions before doing anything else
- Increased horizontal space the forms spans on
Left/Right or Right/Left
Now, in the western world, we read text from left to right. Therefore, we can scan left-aligned labels very fast. However, have in mind that Arabic and Hebrew are read from right to left, so right-aligned labels are scanned easier in such a case. Make sure you make the right choice based on what language your visitors speak.
Top aligned labels are great. They are somewhat easy to scan through. They can have long questions, without worries of destroying the overall layout. Some questions, like city and zip code or phone and ext. could be grouped together on the same line. Having the labels on top of input fields means faster and easier processing. So, you should probably use these kind of forms whenever you want to get the thing done fast, and vertical space is not an issue, because yes, they do take up quite some vertical space.
Pros for top-aligned labels
- Can have long questions.
- Can group together similar information
- Fast processing
- They need a lot of vertical space
- They can't be long just for the above reason
November 10th, 2009 at 11:08 pm
Your point about browser screen resolution being “pretty big” doesn’t sound right to me. Sure, larger monitors are available than in the early days of computers. But don’t forget about mobile devices, such as the iPhone.
The cons for left-aligned labels can also be addressed. If it uses the “label” tag, clicking a form label should position the cursor in the relevant field. Unfortunately, few sites seem to implement this correctly, instead relying on plain text as a form guide. Again, this is inaccessible. As for increased horizontal space, this is down to the design of the form – even a very long label can be forced onto multiple lines. I prefer to put all form labels in a fairly narrow column on the left, and give the form fields plenty of breathing space. From your examples, I’d say that right-aligned labels seem like a fairly good option if you keep the labels within a certain width.
As for top-aligned labels, once again a major problem here is accessibly. A screen reader reads from left to right, so in your example it will say “First name, Last name” and then tell the user that there are two fields afterwards. It won’t say “First name, field, Last name, field”.
PS Implementing “subscribe to comments by email” would be a useful addition to your blog
PPS IMO, your comment box is far too small.
November 10th, 2009 at 11:26 pm
Hi Ben. Thanks for the comment and thanks for being the coolest reader I have seen here since I launched! Your comment is really comprehensive and I appreciate your effort!
Now to address your comments.
“Assuming you use dynamic text, cons #2 and #3 can be easily addressed with a bit of coding.”
“Your point about browser screen resolution being “pretty big” doesn’t sound right to me.”
This depends. For example, stats for this site show that 98% of resolutions are larger than 1024*768 which is awesome. However, I run different sites for different clients and I have sites that have resolutions up to this as large as 60%, which is not that awesome anymore.
“The cons for left-aligned labels can also be addressed. If it uses the “label” tag, clicking a form label should position the cursor in the relevant field.”
Hmmm. This cons is not about going through the form and using it (with mouse or keyboard) but as to how many eye fixations are required for the human brain to connect the label with its input field. Any implementation will not fix this eye fixations issue.
“As for top-aligned labels, once again a major problem here is accessibly. A screen reader reads from left to right, so in your example it will say “First name, Last name” and then tell the user that there are two fields afterwards. It won’t say >>First name, field, Last name, field< <."
This is interesting, and I must say that I haven’t thought about that at all. Thanks for pointing it out.
“Implementing >>subscribe to comments by email< < would be a useful addition to your blog"
Well, now that you said you want it, I have to do it. I’ll let you know when it will be up and running (hopefully soon). I planned it for some time, but never got the time to do it.
“IMO, your comment box is far too small.”
And once again a mistake from my part. The truth is I never expected such a through comment. I think I’ll add a modal window for a larger textarea.
Once again, thanks for sharing your thoughts Ben!
9 months stats says:
December 12th, 2009 at 10:10 am
[…] 2. Forms. Can’t live with them. Can’t live without them […]
Impressive web forms. From coding to validation! says:
March 23rd, 2010 at 7:38 pm
[…] Today I'll tackle coding a good webform, styling it, client-side and server-side validating. The first part of the tutorial was extremely popular, and that's why I chose to merge parts two and three, which […]
Caroline Jarrett says:
March 26th, 2010 at 8:20 pm
It’s great to see an article about label placement in forms that encourages people to think about the questions themselves, whether they need long or short labels, and the overall balance of the form. Great stuff!
As well as Mario’s piece, which is looking solely at time to read the label, you might be interested in my article that also looks at what the label says.
Overall: remember that people are much more likely to bail out of forms or give inaccurate answers because of what the questions are asking than because of where the labels are placed.
Bogdan Pop says:
March 26th, 2010 at 9:48 pm
Many many thanks for your comment! It’s a great honor for me to see such great authors stumble on the articles I write and take the time to comment them.
I can’t wait to get some spare time to read your book (Forms that Work). Bought it a couple of weeks back but didn’t get to reading it.
Iza Bartosiewicz says:
March 21st, 2011 at 6:24 am
Your post has been up for a while, but there are a couple of points I would like to follow-up on. The first one concerns the ‘inline labels’. You’ve identified the usability issues, and Ben picked on the potential accessibility problems with this approach. I just wanted to add that anyone wishing to use this technique should check out Terrill Thompson’s page first: http://terrillthompson.blogspot.com/2011/01/testing-accessibility-of-pre-populated.html
The second point is about the accessibility of top-aligned labels raised by Ben. He is right, this form would create problems for the screen reader users IF a table was used for layout, the labels and the corresponding fields were sitting in separate rows, and the label markup was missing. However, we can’t be certain of this, because we don’t know anything about the markup of that form.
You’re absolutely right about the importance of making web forms user-friendly. Since some users are likely to have disabilities, it is also important to make them accessible. There is plenty of information about accessible forms out there, but here are a couple of trusty recommendations: Accessible forms by Roger Hudson at http://www.usability.com.au/resources/forms.cfm, and WebAIM’s article on creating accessible forms at http://webaim.org/techniques/forms/
Bogdan Pop says:
March 21st, 2011 at 10:59 am
Hi Iza and thanks for the great comment. Nice links too. Please note that I’ve coded the forms in the second part of the tutorial: coding and validating web forms.
Impressive web forms. From coding to validation! | cenawz says:
August 8th, 2013 at 6:42 am
[…] I’ll tackle coding a good webform, styling it, client-side and server-side validating. The first part of the tutorial was extremely popular, and that’s why I chose to merge parts two and three, […]
Completion times of all 4 types
Left aligned labels could have quite some span between them and their adjacent input field, so users are forced to take more time when interacting with the form. The right aligned labels reduce the eye fixations imposed by the left aligned labels to almost a half, and reduce the cognitive load users need to complete the form. Top aligned labels allow users to capture the label and input field at once, with only one eye movement. Inline fields are a better than top aligned labels, but remember when you must not use them. For further info on completion times, you can check out Matteo Penzo's article Label Placement in Forms.
I totally recommend you read Luke Wrobleski's book Web Form Design: Filling in the Blanks. The amount of valuable information it contains is priceless.
We are now done with the theoretical part of web forms design. Well, we know the basics of web forms design. In the next part of this tutorial we will discuss how to implement using XHTML and CSS all the 4 types of forms described above. Stay toned.
PART II and PART III
Part two and part three of this series will contain the XHTML & CSS for the forms and form validation. If you liked this article you can stay updated and get new content via our RSS feed.
Now if you reached this far, I really recommend reading forward the comments section two, because there's plenty of useful information shared there as well.