Computers are supposed to make our lives easier, not more difficult. As usability-conscious designers, we can make our users’ lives easier by thinking about the way people interact with our websites, providing clear direction, and then putting the burden of sorting out the details in the hands of the computers—not the users.
It’s that last part that we’re going to focus on here. We’ve all heard and read about big usability mistakes time and time again: “Don’t use images or Flash for navigation,” “Don’t use JavaScript for links,” and I certainly hope we’re all applying those lessons in our work. It’s often the smallest usability quirks, however, that create the biggest annoyances for users, especially when it comes to HTML forms. Follow these guidelines, and you’ll be off to a good start.
Use the right field for the task#section2
With so many form elements to choose from, each with distinct advantages and disadvantages, it can be difficult to decide which elements to use in a given situation. Use radio buttons, checkboxes, and select boxes appropriately: for radio buttons or checkboxes, use the fieldset and legend tags to group the elements logically under an obvious heading. This grouping keeps the form manageable to users, as it can be broken down into smaller pieces in their minds.
Jakob Nielsen provides these guidelines for use of checkboxes versus radio buttons:
- Radio buttons are used when there is a list of two or more options that are mutually exclusive and the user must select exactly one choice. In other words, clicking a non-selected radio button will deselect whatever other button was previously selected in the list.
- Checkboxes are used when there are lists of options and the user may select any number of choices, including zero, one, or several. In other words, each checkbox is independent of all other checkboxes in the list, so checking one box doesn’t uncheck the others.
- A stand-alone checkbox is used for a single option that the user can turn on or off.
Source: “Checkboxes vs. Radio Buttons.”
For fields in which a single selection is required and there are a large number of possible options, consider using a drop-down select box to conserve screen real estate. The barrier between what makes sense as radio buttons and select boxes is somewhat of a gray area and will depend on context. If you wind up with five or more radio buttons, it may be time to move up to a select box.
If the field allows for multiple selections, try your best to avoid using the so-called “multi-select” box. This form element is at best confusing to users and at worst, it makes the form useless to those who do not immediately understand its functionality. If the number of options is so great that it becomes a giant blur represented as checkboxes, consider consolidating some of your options or categorizing them hierarchically to make them easier to understand.
Give them room to type#section3
Equally important to making the right decision on the field type is specifying the right field length. Just because your name is Joe Tod doesn’t mean other users won’t need more space to enter their names. Provide at least 20 characters for each of the first and last name fields. Additionally, don’t make the physical size of the input box cover less area than the expected entry. For text areas, make sure to give the user sufficient room to enter and read their text. Very tall, very thin columns are as difficult to read as a very wide, very short horizontal text area. The exact values will vary depending on their use but we can establish some minimums of 50 characters wide by 10 lines tall to ensure readability.
Shorten your forms and question “mandatory” fields#section4
To make your form as concise as possible, I recommend a two-step evaluation of every element of the form. To begin, ask yourself the following questions about each form element:
- Is this a piece of information that is valuable to us?
- Is this a piece of information that is so valuable that it’s worth denying users access to (whatever lies beyond the form) if they do not choose to provide it?
One of the most obvious examples of a form element that fails the first test is the salutation. It usually provides us no real benefit to collect this information, so why are we making a user give it to us? Don’t waste users’ time by asking them to provide useless information.
The second test (“should we require this field?”) is a bit more subjective. One example is the telephone number. There are many instances in which a telephone number would be nice to have. However, it’s usually not required to continue the transaction. Put the choice back into the users’ hands.
Mark mandatory fields clearly#section5
Some fields must be filled in to complete the transaction: if you’re selling a physical good, you’ll obviously need a shipping address. As with error messaging, give users visual cues as to which fields are required. Many times, form authors use bold or italic text to signify which fields are required and expect the user to make this association. There are several more explicit options which you can use to draw attention to required form elements. You can use an asterisk, “required” in parentheses following the field, or we can divide the form into two sections: required and optional information. In any case, if you are using any type of symbol or highlighting to denote fields which are required, you need to provide an easily findable legend which notifies the user of the symbol’s meaning.
I advise against using the color red to denote required fields, because red most often indicates an error or warning. As I’ll soon discuss, you should provide strong visual cues to indicate errors, so pick a color that will not be confused with error messages.
Provide descriptive labels for all of your fields#section6
What good is a form field without knowing what you are supposed to enter into the field? Employ the label tag to ensure accessibility is maintained for all users. Also, make sure your labels are descriptive enough that users do not question what is expected in that field. Field names should be clear and concise. If additional information would be helpful, XHTML 1.1 provides the caption tag to add a descriptive caption and provide proper accessibility. For the less adventurous, you can always create small caption text using traditional XHTML 1.0 markup and CSS.
Let the computer, not the user, handle information formatting#section7
Few things confuse users as often as requiring that users provide information in a specific format. Format requirements for information like telephone number fields are particularly common. There are many ways these numbers can be represented:
- (800) 555-1212
- 800-555-1212
- 800.555.1212
- 800 555 1212
Ultimately, the format we likely need is the one that only contains numbers:
- 8005551212
There are three ways to handle this. The first method tells the user that a specific format of input is required and returns them to the form with an error message if they fail to heed this instruction.
The second method is to split the telephone number input into three fields. This method presents the user with two possible striking usability hurdles to overcome. First, the user might try to type the numbers in all at once and get stuck because they’ve just typed their entire telephone number into a box which only accepts three digits. The “ingenious” solution to this problem was to use JavaScript to automatically shift the focus to the next field when the digit limit is achieved. Has anyone else here made a typo in one of these types of forms and gone through the ridiculous process of trying to return focus to what Javascript sees as a completed field? Raise your hands; don’t be shy! Yes, I see all of you.
Be reasonable; are we so afraid of regular expressions that we can’t strip extraneous characters from a single input field? Let the users type their telephone numbers in whatever they please. We can use a little quick programming to filter out what we don’t need.
Use informative error messages#section8
When I began work on this article, I spoke with my mother, a reasonably “average” home user, about the topic. The issue of form errors was the first thing she spoke, or rather, ranted about. When she tried to order a Christmas present from a website recently, she filled out the form and clicked the “order” button. She was then returned to the form with the words “Credit Card Error” in bold, red text across the top of her screen. Confused, she searched through the form to find any indication of where the problem had occurred. Finding none, she searched again to find the credit card input field. She checked the numbers and the expiration date. She even checked the spelling of her name, but each time she submitted the form, the same error message was displayed.
As it turned out, the problem was that the merchant’s credit card processing system was down. Nothing she could have done with the form would have made any difference. Returning a user to this situation just makes them feel ignorant, and I suspect we can all agree that insulting users is not in our best interests.
There are several steps we can take to better handle errors in HTML forms. First, and most importantly, we can provide more informative messages. Replace cryptic messages such as “Credit Card Error,” with context-sensitive messages:
- “There was an error in our credit-card processing system. Your card has not been charged. Please try again later or contact us directly at…”
- “There was an error processing your credit card; we were unable to verify your card number. Please check your name, credit card number, and card expiration date for correctness. Remember, these must match the card exactly.”
These error messages are complete and tell the user what has happened. These messages also direct users towards possible resolutions rather than just telling them what went wrong and expecting them to devise their own solution.
The next step we can take to avoid confusing errors is to provide some visual cues as to where the problem lies; don’t leave your users to hunt down the problem areas themselves. With a little CSS, you can modify the original form in a variety of ways so that the user can easily identify the elements which need to be corrected. You can also use CSS to hide the fields that are already filled in correctly and only display those which need to be corrected. We can do this for groups of fields (such as the information required for credit-card validation) by using the fieldset tag.
Don’t return users to an altered form#section9
How many times have you entered your information into a form and clicked the submit button only to find that you left a required element unfilled? If you’re anything like me, I’m guessing it happens more than once in a while. While it might just be the price I pay for skimming the form and trying to get through it as quickly as possible, I shouldn’t be returned to an altered form if I make a mistake.
When I submitted my data, I had checked the box which said I agreed to the terms of service. I had also filled in my password. And, if I recall correctly, I definitely unchecked those boxes that said “Sign my e-mail address up for as many mailing lists as possible.” So why is it that so many times I get a half-completed form back?
This example is really a combination of developer laziness and overzealous marketing techniques. (Though the password un-fill may be a legitimate security precaution.) To the marketing departments out there: remember that marketing is about satisfying customer needs. If a user’s need is to not receive your solicitations, you should respect that need instead of trying to trick people into something they’ve already told you they don’t want. And to developers, make sure you’re populating every form element that the user has already submitted. There’s no reason they should have to re-accept the terms of your agreement or enter their information a second time because of a small typo.
Remember, the more control users have over their experience, the happier they will be using your website.
Don’t force a format for phone numbers. Autofills get confused. Put a checker in to see if it’s all there it is important.
Don’t make people scroll down a list of all 50 states to find the abbreviation. We know it already. I can type FL or NY or whatever. And autofill will get it right.
I agree particularly about returning the form when errors are made as I filled it out.
I actually think it was the web form that got me interested in web design, and later programming. I guess I saw that there was a true art to making a visually pleasing and easy-to-use form online. (Now though, designing a form is about my least favorite thing to do.)
I think we (I know I do for sure) sometimes over-estimate Average Jane’s capabilities and understanding of the web. I try to pay close attention to my friends comments and actions when they use my computer. They probably think it’s freaky the way I study their actions, but it’s useful to me. A lot of times it’s funny — the things they do or say. (Then I realize how dorky I am for giggling at them).
I was checking my email and made a comment about a few spam emails I had received. My friend quipped, sounding as smart as he could, “That’s why I don’t use Outlook Express. It causes too much spam.”
So maybe my tip is to remind yourself, when you’re designing your web forms, that the user possibly thinks Outlook Express causes spam.
Or, perhaps my friend knows something about Outlook Express that I don’t.
As mentioned in the article, password fields are usually blanked out after posting a form to the server and returning with errors. Although annoying, this is indeed done for your protection. When the form is posted to the server and then redisplayed, the password fields have to be repopulated just like any other field — this means writing the password in clear text to the html source. Password fields are _displayed_ as asterisks, but the source data is written as plain text from the server. In fact, in signing up to ALA to post this remark, I tested the form and found this very issue! (Fill in a password field but leave another required field blank, submit the form, then view source.)
Now, what are the odds that I’ll submit the form, then leave my computer unlocked with the partially-submitted form visible so that someone could or would actually find my password? Probably slim. However, don’t forget that now that it’s been written in clear text to my browser, it’s also sitting *in clear text in my browser cache* as well (indeed, to verify this, I simply browsed to my browser cache folder, did a quick ‘search in files’ for the term ‘password,’ and voila – there’s my cached ALA form entry with my password as clear as day). Probably not a good thing if someone with this basic knowledge ever compromised my machine, especially since most people use the same password for many sites. For this reason, websites should generally never write passwords back to forms _from the server_ (client-side validation does not have this issue, of course, since no data is ever written back to the form until the form contents leave the client).
Another thing to remember abut phone numbers: Some of us are from outside the US. And it’s not very obvious how to fit an 8-digit phone number + a 2-digit country code, preferably prefixed with a ‘+’, into a standard US phone number format…
Same kind of thing with a state choice: it’s always nice when there is an option for leaving it blank. We don’t have ’em here 😉
And if the form is supposed to absolutely only cater for USAians, please make that clear from the very, very beginning. I probably can’t count how many times I’ve filled one out only to find three screenfuls later that sorry, this is only valid for citizens of the US. The ‘net is global – so plan for it.
(good advice for full error messages and avoiding re-typing!)
Amen for “opt-ins” over “opt-outs” on email newsletters, but I don’t think that message will be heard soon. In my opinion, email newsletters should be on their way out thanks to RSS, but sadly I know they’ll stick around for quite awhile.
Overall a solid article. I can’t stress enough how important it is to have small forms. Whenever I hit a site with a massive 15+ registration form, I often skip it. I have a friend who won’t register on just about any site. Not due to security concerns, but due to laziness. He’s been using digg.com, slashdot, ESPN for months now and hasn’t bothered to get an account on any. Whenever a form comes up he hits the back button. So the most important question when thinking about a form is “is it really necessary?”
Brian,
Thanks for your insightful comment about the issue of password security. I’d thought about this very thing when writing the article and it occurred to me shortly after submitting for publication that perhaps I’d left that a bit to open-ended. Perhaps this security issue is a problem with the architecture of forms themselves and not really a flaw caused by designers.
Password security is important; but I believe there is a way to make it work without sacrificing clean interfaces. -BC
I think that there should only be one phone box, and let the user enter however it should. Not only is this recommended for US users, but even more important for international users, since not everyone has a 10 digit phone number. Also, since the US is not the only country in the world, it shouldn’t limit or require the state box. Or if it requires it, only for US residents. There have been numerous times when I had planned my trips to the US, but felt crippled as to what I could do INSIDE the US because I have to call a 800 number in the States, or the online tickets were good only for residents. I can understand some services (like grocery delivery) being limited, but it shouldn’t be that way for concert tickets or other entertainment sources.
–A disgruntled expat who is frustrated at the lack of internationalization sometimes.
The article advises against using these, but they are an important web application interface widget in my opinion (we aren’t all using forms for simple marketing and contact purposes!) How else would one go about allowing the user to select several options from a large list (too large to think about checkboxes)?
Even though it makes absolutely sense to use a checkbox for a Yes/No question there are reasons to use two radiobuttons in stead.
I work for a insurance company where we need the user to actively give an answer, leaving a checkbox unanswered is not an action.
Also on top of that almost all our questions are mandatory, a telephone number is one of the very few exceptions to that rule.
Most of the stuff to look out for is well documented in the article (good job on putting together such an easy to understand piece). It’s good to see it written down (rather than sloshing around in my head).
Instead of supplying those massive long lists of countries to choose from, why not let the user type it in as well as choosing from a select dropdown? What about grouping the “most common” countries into a select dropdown and providing a regular text input for others? That’s certainly more usable for a wider audience.
What really gets me is the decision to require users to fill out a ZIP code. If the user selects USA then by all means provide a ZIP code as mandatory… but we don’t have ZIP codes here… and whilst they are often called Postcodes outside of the USA, they are by no means well known (in all countries) and certainly not used outside of business correspondence (in many countries).
The use of labels, legends, fieldsets and non-mandatory fields are what makes me bother to come back to a site (ok… and great content – thanks ALA).
Be careful what you wish for, I run into a lot of websites that want me to fill in a phone number or email address. Without those I can’t submit the form. It happens to be that my grandfather ordering that particular set of classical CD’s does not have an email address. And in my personal case: I don’t have a phone number. I use Skype.
In fact I’ve noticed the very company I work for lose a lot of subscriptions by asking people what state or province they live in, and making that a mandatory field. Some countries don’t have states or provinces.
As for wanting a certain input for a phone number, don’t spread it over multiple fields but keep it simple (that principle alone saves hundreds of Euro’s every day). As noted by someone else: autofillers don’t particularly like a phone-number field that is actually 3 fields.
If you really want to receive a format you like to read or one that your database works best with then format the number server-side.
I’m regretting leaving out mention of international issues when using forms. To all of the international users who have responded here, thanks for your input and I hope you realize that many of the principles I’m putting out there (such as allowing *any* format of input for a telephone number) are extremely beneficial for International users as well.
As far as multi-select boxes go; you’re not going to convince me that it is not a confusing and haphazard field for most users to work with and my take on it remains the same. If you’ve got a list that big to choose multiple items from; maybe you need to take a look at your information architecture and break it down into more manageable sections. That said, I do believe there are exceptions to every rule and the multi-select box *can* have its place. But, as you said, that place is in web applications, not websites.
Further to the comments about checkboxes, note that unlike the US, in the UK forms having sign-ups to newsletters etc are required to be opt-in. Opt-out is illegal here.
So in my opinion default to opt-in always. At least that way you’re covered even if the marketing droids get a little annoyed.
bq. Be reasonable; are we so afraid of regular expressions that we can’t strip extraneous characters from a single input field? Let the users type their telephone numbers in whatever they please. We can use a little quick programming to filter out what we don’t need.
Amen to that, brother. Even more annoying is credit card forms where the developer requires a 16-digit number with no spaces or other separators (despite that being the way it’s printed on the user’s card and being easier for the user to confirm the number). What’s so hard about stripping out those non-number items on the validation end?
I recently did a form for an insurer in the PNW(Pacific North West), so NANP(North American Numbering Plan) phone numbers only, where I wrote regular expressions to strip out any user formatting (spaces, dashes, dot’s, etc. ) and to change mnemonic numbers to numerals (CALL-ME = 225563). While I was at it, I even checked the formatting of the number itself:
* does the number begin with “0” or “11”? (reject as non-direct-dialed NANP number)
* does the number begin with a 1 and then a 2-9? (drop the unnecessary ‘1’ from the Db entry)
* is it exactly 7 digits long? (alert and ask for the area code)
* is it longer or shorter than 10 digits (after dropping the leading 1)?
* does it follow the numbering pattern of the “NANP”:http://www.nanpa.com/number_resource_info/ ?
I was even able to ultimately check for bogus, Hollywood-style fake numbers (of the “˜555′ ilk) using the info at NANP. It really wasn’t too hard to write the regular expression to do all of this—it took more space to describe it than it did to write the regExp. The benefits are that a user can enter the number in any format style with which they’re comfortable, while giving the insurer the best chance possible of collecting valid user phone numbers (used for customer i.d. verification in this instance, not marketing purposes).
I’m sure with a little research, the same could be done to handle international numbers as well. There’s some excellent links off of the NANP site to some of the international numbering standards sites.
Good read. Too bad those who need it most will most likely not read it.
I agree that a little more info than “Credit card didn’t work” or whatever should be in order for the user. However, hackers love descriptive error handling. The hacker looks for anything the developer will give him/her to find vulnerability. When a developer is too descriptive it can result in tipping a hacker off into how close they are to adding some cross-site scripting or sql injection or whatever else. Maybe a good option would be to provide a link to the administrator’s email upon finding an error dealing with transactions or errors that are bigger than the simple form validation.
One problem that afflicts larger forms, is when drop-down menus have no default option. If you are in a hurry, or lazy, or haven’t read the form (me, me, and me) it is easy to progress to the next step without remembering to select your appropriate option.
This has caught me out in two very important areas. First, my online banking system has a drop-down menu for payees. If you are paying several invoices to the same people, it is easy to forget to select the payee each time. I’ve also booked flights online FOR THE WRONG MONTH because the ‘default’ was set to a month hence, not the current month. In both cases, a default null value would have ensured that, if I forget to make a selection, I don’t waste my money.
I completely agree that forms should accept phone numbers and credit card numbers however the user chooses to enter them but I don’t think it hurts to indicate what the preferred format is.
We’re used to forms being picky, both on and off of the web. Forms are usually associated with something complicated and exact like tax returns or job applications. If it’s not filled out as intended, we _expect_ something to go horribly wrong. Normal text input boxes don’t offer a lot of guidance as to what should be in them and that can be scary.
As a web-saavy user I’m never sure if the phone input is one long text box because the form designer is considerate and will accept whatever I throw at it or because the form designer just got lazy and forgot to specify that I need to include a space after each number and a semicolon at the end or it will blow up. I spend valuable seconds trying to guess what the form _wants_ me to do.
Maybe even if you don’t have a preference on format you could somehow indicate that all permutations of 10 digit phone number are accepted and offer examples.
I ran across this link earlier this morning. While it ignores the issue of being able to select multiple consecutive items using the Shift key in Windows, this behavior could be duplicated with a little extra JavaScript.
“Scrollable checklists”:http://c82.net/samples/checklist-samples.html
I think it makes this functionality more usable… especially since all web users aren’t savvy designer and developers.
A great article for sure, but a few examples would go a long way. I’d like to know what is considered good form (ha) for label, caption, fieldset and legend elements.
Also, is there a framework or good piece of source code that someone could share for reusable forms that validate input? Something PHP driven would be great. A good regex example for telephone validation would go a long way here as well.
In regards to the comment about descriptive error messages. To an extent ‘hackers’ like them. However the name of the game is to make your scripts secure. The first step is to make your forms as strategic as possible – This is the best way to have a sure footed direction for your form validation as well.
Example:
A phone number consists of three separate entities – which can simplify the data entry by providing three fields, 2 with a max of 3 characters and 1 with a max of four characters. The form validator only has to validate whether the fields are numeric or not – As opposed to stripping and separating dashes, parenthesis and other odd delimiters; (By saying odd delimiters this goes for ‘dark’ methods of input as well.)
Justin, a North American phone number is not simply 3 numbers followed by 3 more followed by 4. There’s more to check there if you want to get a valid NANP number. Area codes always start with numerals 2-9; so do prefixes. It’s also possible to spell out a phone number with letters; and while the average phone number is just numbers in most peoples address books, why force the end user to figure out that ‘d’=’3’ on the dial pad? That’s just lazy.
Allowing one field for entry (and allowing the user to enter it as they prefer) is just plain user friendly. The more separate fields you force a user to tab through, the less likely they are to complete the form. Sure, to answer someone else’s comment, you might provide an example of the suggested format, but not all users will even heed that as they fill in the form.
Good article. It didn’t mention much about when the programmer changes what the form fields are supposed to do. Many times I have clicked on a radio button that let me to another page, and it made me scared of the whole website.
This is about the proud programmer, who believed that pulling off some cool trick, people are going to think that what he did is awesome. Other programmers would probably think so, but normal people will be scared off by his gimmick. Just because you can do it, it doesn’t mean that you should!
Another proud programmer is the one who thinks because he can program a form, then he’s the elite person who shouldn’t listen what other people, like the author of this article, is saying, so he just goes off and does it his own way. People should be thanking him that he programmed a working form in the first place! he thinks. And that’s also bad.
I actually do read a lot of these articles on usability, and I live on Jakob’s website, and there is still much I need to learn.
Very nice roundup. You mentioned the importance of the label tag for accessibility. I would like to add that the indication of mandatory fields should also be included inside the same label element. If it’s not, screenreader readers are forced to leave the ‘forms mode’ to find out which fields are required to fill out (which can be quite time consuming). By putting the asterisk (or whatever you’re using to indicate mandatory fields) inside a span (that’s nested inside the label element), you can style it differently and even float it to the right of a text field if you’d like.
You should be glad you don’t have to use select boxes to choose your street type and house type. When creating/modifying an address on our website you must manually select from a list of hundreds of different types of streets and units, with no way to simply type them in.
One of the choices for unit type is “Igloo”, and perhaps your Igloo can be found inside a room, yes a room (as in street type). Why we have to do this I do not know, nor do I know why I’m not allowed to use checkboxes and radio buttons anywhere on the website, or why you have to “select” your birthday from drop downs.
At least one doesn’t have to select their name.
So even though I completely agree with this article, I just wanted to remind everyone that designers rarely have the input they deserve (at least for me).
Good article but I am surprised nobody has mentioned unnecessary JavaScript in forms. I have seen many forms with no submit button but instead a link with “javascript:submit()” as the target. There is no conceivable reason for doing this and it breaks just about every usability rule including preventing users from submitting with the enter key.
Most programming languages have a dedicated function to validate whether it’s numeric and/or alphabetical.
It’s the delimiters -,.,(space), etc. we let our users enter that devours our time for validation – this is all I’m saying.
Remember, if a person wants to give a false phone number, they’ll do it. Even if it means going out of their way to enter the phone number of their local pizza place.
bq. It’s the delimiters -,.,(space), etc. we let our users enter that devours our time for validation — this is all I’m saying.
So your time is more important than all the end users’ time put together is all you’re really saying.
Just out of curiosity, caption is mentioned in the context of forms and labels. I’ve only seen it used to label tables, which is consistant with what I’ve seen in the w3’s docs. I saw no mention of a change in the caption element for xhtml 1.1, am I missing something?
.adam
bq. As far as multi-select boxes go; you’re not going to convince me that it is not a confusing and haphazard field for most users to work with and my take on it remains the same.
Absolutely agreed. I have to support a couple of web-based services at work, and both of these use multi-select boxes with potentially 50 or more entries – fortunately they are optional ‘enhancement’ features rather than essential to the use of the site. Even though it says clearly by the side “Press Ctrl+Click to select more than one option, *and* it explains this in the instruction manuals I wrote, *and* I point this out whenever I am showing someone how to use the system, it still seems that the majority of people are unaware they can select more than one entry.
I think a key problem is that it looks too much like a normal drop-down select menu, and a lot of people don’t twig that it is different.
One website that I use quite a lot is for looking up train times & fares (UK) – “Qjump”:http://www.qjump.co.uk/ – and there are three aspects of the enquiry form that irritate me.
One trivial one is that when you mouseover a field, it highlights the entry by turning it lime green. This means that if you click in a field and type, without moving the mouse, you can barely read what you’re typing.
A second is that if it doesn’t recognise the station name you type in, it gives you a huge long list to choose from without making an attempt at a “best guess”. Far better for it to suggest the most likely option, and list the others below in case it was wrong.
But the third, and most pertinent to this article, is this. If you select “one-way journey”, but then enter a date a/o time in the section marked “return”, instead of ignoring that data, it spits it back at you and rudely tells you that you are *not allowed* to give a return date when you’re making a one-way journey.
In comment #20 Justin wrote:
bq. […] by providing three fields, 2 with a max of 3 characters and 1 with a max of four characters. The form validator only has to validate whether the fields are numeric or not […]
_Never_ rely on the fact that you are only receiving _n_ characters because your forms have such an attribute set. You could end up inserting a little more than you wanted. 😉
Ah yes – I got a little too literal in my description of what I wanted to achieve. I wanted to paint a verbal picture on how one could lay out a phone-number entry without making users enter their own delimiters.
However, the validation methodology still stands – is it alpha/numeric?
Nice article 🙂
I just have one question about the description of the <caption> tag. You write:
“Employ the <label> tag to ensure accessibility is maintained for all users. Also, make sure your labels are descriptive enough that users do not question what is expected in that field. Field names should be clear and concise. If additional information would be helpful, XHTML 1.1 provides the <caption> tag to add a descriptive caption and provide proper accessibility. For the less adventurous, you can always create small caption text using traditional XHTML 1.0 markup and CSS.”
I thought the <caption> tag was added around HTML 3.2? Second I thought it was only meant for use in tables (see “W3Schools”:http://www.w3schools.com/tags/tag_caption.asp ) – or am I missing something here?
After reading the article it got me thinking and I wrote a few thoughts on the subject of form usability. Feel free to visit “my post on justaddwater.dk”:http://justaddwater.dk/2005/12/23/sensible-forms-a-form-usability-checklist/
/thomas
Thanks to everyone who has taken the time to read and comment on this article (especially the person who mentioned the javascript:submit() issue; I KNEW I’d forget to put something in there!).
I do not have time to reply to all of these comments right now as I am out of town for the Holidays. Please keep the thoughts coming and I will try to respond as soon as possible. -BC
Excellent article, Brian. Another benefit to the single-field phone number is the accessibility aspect of only needing to label one field. If you have to label three, what would you call them? area code, prefix, and last 4? Suffix? Who would understand that in context? Thanks again!
Great article, and easy to read and understand. I also heartily agree with Poster 4. My biggest beef with forms, is having to take the trouble to fill it all out… for example, for a free DVD describing the shop’s wares… and only after it is all filled out, finding they do not ship outside the U.S.
Sometimes, to satisfy my curiosity, I search the site for where I may have missed this info… and it is buried on some page in a small font, but is definitely not anywhere near the form page or within the form. I think such info needs to be made explicit. My suggestion is to put this type of info directly under the Title of the Form, something like “We do NOT ship outside the U.S.” It doesn’t hurt, especially if the form is a tad long and requires scrolling, to reiterate this message again, on top of another form section.
Although I am giving a specific example, I think the basic idea is a more general one: Let your audience know whether or not the Form even applies to them. The cardinal rule I would like to add goes something like: “Your users’ time is precious. Never waste it, or make them go through filling out a form unnecessarily. ALWAYS let them know whether or not a form applies to them, by stating these things clearly and upfront. Let them know if only people filling a certain criteria can apply.
Off the top of my head, another example might be if only VISA is accepted… shouldn’t you let people who may only have other Credit Cards, or none at all, know that ‘at this time, only VISA cardholders can complete the transaction’?
Brian, how do you feel about the use of Form Legends? Specifically with them being nigh on impossible to style them the same across browsers.
Always use a https:// address for any form that contains any sensitive data (and pull all elements on the page from the https:// domain so the users don’t get a message about secure and non-secure items!).
A properly set up browser won’t cache data from a secured web site so your credit card details won’t be cached unless you overrode the default browser settings and enabled caching of secure web sites.
I’m like the others who despise forms that make information I don’t think the company needs for any valid purpose as mandatory and as much as possible when I hit such a site I ensure they get unusable garbage ( bitbucket@edgeoftheinternet.drop is my favorite email address 🙂 ).
Cookies
If your form requires cookies, please say so, if only as an error message (this means you AListApart; I just spent several minutes trying to log in before I realized what was going on).
JavaScript
If your form requires JavaScript, rethink, but if you must, use a
Autofocus
Don’t autofocus on the first field on page load. I can’t count the number of times I’ve typed the first field and started typing the second (usually a password) when the page finishes loading and I wind up typing all or part of my password into the first, visible field. I also suspect this might be an accessibility issue for folks using screen readers, but I can’t say for sure since I don’t use one.
If it’s not an accessibility issue, then be intelligent about it and don’t autofocus if I’ve already started doing stuff with the page (typing, scrolling, tabbing through links, etc.). (And if the form isn’t the page’s sole purpose in life, then how do you know I want to fill in the form at all?)
Hope this helps.
I’d say if a field is required, use the word “required”. Using an asterisk means the visitor has to look for the footnote, which might not be on the visitor’s screen at the moment depending on how big their browser window is. And even if it is onscrenn, they still have to find it.
One thing that wasn’t strongly forced in the article is that your form design matters depending on your target audience. On my current project, our audience (insurance agents) are used to entering data in short question/answer forms with multiple steps and/or pages. They generally do not like large forms. On my previous project, our audience was mortgage brokers. Brokers are very familiar with very picky and long forms — no multiple pages for them.
Regarding e-mail validation: don’t bother trying to validate an e-mail address using a package that tries to send a test e-mail. Many large ISPs and companies use virtual mailboxes. The server universally accepts mail to @domain.com and THEN sorts out if user@domain.com actually exists. If you are trying to write a regular expression, anything less than the regular expression in Perl’s Email::Valid module (http://search.cpan.org/src/MAURICE/Email-Valid-0.15/Valid.pm) is not enough.
Also, don’t make your own widgets! I see too many sites now that use their own radio button image to match their style and hack it in with JavaScript. That completely destroys any familiarity a user has with form elements. Elements match the operating system for a reason. This falls under “too much CSS!”, too. One of the biggest blunders I’ve seen in form dsign are websites that switch the scrollbar location on textboxes from right to left.
With regards to the poster asking about the legend tag: sometimes usability and accessibility need to take a front seat and having your form look “pixel perfect” on all browsers becomes the second banana. That said, you might also consider less sophisticated styling. My experience with the legend tag is that as long as I keep it simple, it will generally work.
Designing for your audience is just good design principle in general and should apply to your entire site design; not just your html forms. My thinking when writing this article was to address issues in “general forms for the general public.” Obviously, as your audience changes, so do aspects of your design.
bq. I’d say if a field is required, use the word “required”?. Using an asterisk means the visitor has to look for the footnote, which might not be on the visitor’s screen at the moment depending on how big their browser window is.
As an alternative, use * if writing “required” in full would make it look too cramped or untidy.
I can’t stand forms where all the fields are the same width. Someone somewhere is trying to make a form “pretty.”
Why on earth would address2 be the same width as address1? Make it smaller. If “state” is supposed to be a 2-letter code, why make it the same width as email address? People don’t think, so they need the form fields to look about as wide as the data they’ll type in.
This is not the high quality article that I’ve come to expect from ALA. Where are the examples?
What examples would you like to have seen? There were suggestions and recomendations for best practices scattered throughout the article. One of the few places I think an example might have been warranted is some example php (or any language really) to perform proper telephone number and credit card validation; but these can be found quite easily. I don’t think we’re trying to reinvent the wheel here. Nothing in the article involved any type of advanced coding techniques that would merit technical walkthrough; but if there is some point I can help clarify for, I’d be more than happy to.
What happens after the user clicks the submit button?
One thing not mentioned in the article or comments is a preferred (in terms of Nielsen-esque “usablity”) form of telling the user that there were errors in the submission. Possibilities include JavaScript alerts, AJAX feedback (continually submitting the form), traditional server-side validation (refreshing the page), and probably more I haven’t considered. Any preferences there?
I’ve always tended toward JavaScript alert boxes so that I can know the data going into the database is what it’s supposed to be, but I know plenty of people don’t have JS enabled (which would rule out AJAX as well).
And while server-side validation is nice, you then have to do some database interaction with incomplete/incorrect data and then figure out how to re-populate the page with everything the user entered. Which is fine for text fields and textareas, but gets into not-so-fun DOM work to select the right item from a pull-down menu and which radio button to select, etc.
Not sure there’s a “right” answer here. Should fields with errors be highlighted? Brought into focus? Field labels changed?
Using an appropriate server side language (php, jsp, asp, etc.) you do not necessarily have to hit the database at all. Simply validate the data with your server side application code and return the form that way.
Javascript (and thus, AJAX) can be a usable solution, but only when used in conjunction with true, server side validation. There is simply no reliable client-side validation that can be done; but those who do have javascript enabled might appreciate its use anyway in this case.
I’m a bit confused by the Brian’s mention of the
not within a form or fieldset (or as a child of any other element for that matter). In the article, it sounds like one could use caption anywhere.
As a general point, I would suggest that form elements should behave as they do ‘out of the box.’ All browsers make form elements look and behave in the same default way – if web developers stick to this, then users don’t have to deal with small changes and quirks specific to individual sites. In particular,
1. Avoid javascript unless absolutely necessary. You may think you’re helping the user with some javascript ‘trick’ but it probably just confuses them.
2. Avoid using css the style a form – forms can be made to look neat without changing the elements themselves.
Your article was great… thanks! I was wondering what your opinions are regarding when to hide versus when to disable buttons on a web form? I am having quite a bit of trouble identifying any standards or conventions regarding this and am now just curious what people think. Any thoughts??
Well-written article! The consensus here seems to be: let the users enter data free-form, with whatever formatting is natural to them. I don’t agree that all form fields should be designed this way.
Let’s take a list of states, for example.
Experienced users will tab to the list, press the key corresponding to the state’s first letter, and either leave it at the state selected or press down till the correct state is selected.
Not many more (or none at all in some cases) key presses than entering the state abbreviation manually.
Inexperienced users do not mind the list at all. In fact, they feel more in control, having to choose from a finite list instead of an open text field.
Finite choices ensure data integrity; open fields leave room for error in the server-side validation, as your surface area is larger.
Thanks to everyone, as always, for their comments.
As far as disabling versus hiding buttons on forms; I consider it to be pretty situational. In my own opinion, it is almost always better to completely hide options rather than disabling them. Few things can frustrate users (including experienced users on this one, as I’ve definitely been in these shoes) like seeing an option that they would like to choose but are not allowed to for reasons seemingly out of their control.
As to the commment about constraining user input for data integrity:
The issue of whether or not state abbreviation should be a list of choices or a 2-character input text box is likely just going to generate a lot of debate from both sides of the argument. In my own opinion, in this case, there is not a significant advantage or disadvantage in terms of general usability and I believe that even users will debate over which whey they prefer. That said, the cleaner validation on the server side does make an argument for the select box.
Brian, great article, covers just about everything one can think of while working with forms. Now coming to my opinion on why form usability is still a prerogative of the “big” or the “hifi” websites. Usability, by itself, if followed to the word, takes more effort, more specialized knowledge and maybe even more manpower. Maybe if developers used better evolved frameworks which address atleast form usablility we may be able to overcome this problem.
This is a fantastic article. In th past I have created forms without thinking about what I myself dislike and take into consideration when filling them out on other websites.
I blogged about this article on “www.thewebdesignblog.com”:http://www.thewebdesignblog.com
Charles Belov says:
_If your form requires JavaScript, rethink, but if you must, use a _
I believe that using the noscript tag is a good idea. However, the brevity of the message can cause more harm than good. There are a lot of web users, some having websites of their own, who know little or nothing about Javascript. The message, “This form requires JavaScript.”, would only frustrate or confuse them, as they wouldn’t know what to do to satisfy the requirement. However, the noscript tag is a vital complement to the script tag, so what’s to be done?
One possible solution is to do it the way we do. We give the user brief “information about Javascript(what Javascript is and why it is required) “:http://www.xqst.com/faq.cfm#technical_faq1
“There are a lot of web users, some having websites of their own, who know little or nothing about Javascript.”
Those people are unlikely to have disabled Javascript in their browsers.
Oh, and I’ve got a sock puppet on my hand with a “Brian Crescimanno” name tag. Now I’m making it say “Hey Mike, those 7 people who made comments are right; the
Great article! I especially loved what was said about formatting input. As you said in your opening, computers are supposed to do work _for_ people, not make it more complicated. Some simple regex is the way to go.
Kudos!
In fact, I felt directly to comment on this one. Stu Nicholls, the owner of http://cssplay.co.uk offered people to submit a a well-styled form that validates and looks stylish.
Here is what I came up with, it is called shades of red. Maybe only for IE, some pseudo classes like :focus did not work. But other browers have their flaws too.
But what do you think:
http://www.cssplay.co.uk/menu/form.html
Design is important too
Good article — too many websites have lengthy forms that require way too much information. I think people forget it’s an inverse relationship between the number of form fields and the successful completion rate of a form.
Any good suggestion out there for address inputs?
What is a good UI design to capture user’s address
information in a order form for example? I’ve tried using two or more normal input textfields and also single textarea. Both with different feedbacks from users.
Regarding address fields: in my opinion, the textarea leaves users a bit *too* free to choose their own formatting. Take for example the following two representations of one address:
6314 Baker St. Suite 300
Atlanta, GA 30333
USA
6314 Baker St.
Suite 300
Atlanta, GA 30333
USA
Now, while you *can* differentiate between them in code, it become increasingly difficult as the number of different ways of representing an address increases. I like to use the following:
Street Address:
Suite / Apt Number:
City
State (let users type, don’t give them a select box to look through)
Zip
All separate fields which have a clear purpose.
Obviously, the rules change if you’re dealing internationally. I like to add a “country” selection before “city, state, zip” so the appropriate boxes can be disabled as necessary.
Hope I’ve been of some help.
BC
ALA seems to have gummed up my formatting on those two addresses.
6314 Baker St.
Suite 300
Atlanta, GA
30333
USA
6314 Baker St. Suite 300
Atlanta, GA 30333 USA
Ok, here goes, please be gentle. I understand that one is encouraged to use a checkbox for yes or no; but I can’t understand why! If a radio button is either one or the other, and a checkbox can be for many, why the preference?
Thank you,
B.
I’ve found a few recommendations to show the asterick after the label or field. And I disagree. I’d like to see the asterick appear before a label so that a user’s not forced to read the labels and fields before noticing the asterick. What do you think?
Yes, placing the asterisk after the field is sometimes inconvenient to users. Not to mention, it sometimes means they won’t see it, defeating the purpose.
I like to stay flexible, and do whatever works best for the particular form. Just be consistent, and use similar placement for all mandatory items within the form.
Splendid article in many ways.
What continues to astound me is that, whether it be a multi-million dollar company or your local muffler salesman, websites are riddled with elementary usability problems. As an experienced writer, I am always more acutely aware of content and am often over zealous with my criticisms. As a usability analyst, however, such harsh criticism is inspired by the apparent lack of thought that is apparent on so many sites. Simple, effective, changes deliver a much better user experience but, apparently, such components are just not important to the company and thus, neither are the customers’ experience. Incredible.
As far as I can tell, captions must have a table as parent element. And it seems like it’s one caption per table. http://www.w3schools.com/tags/tag_caption.asp
They might work for you now, but I doubt their accessibility. And their future behavior is anyone’s guess.
I would think that the division of a medium/long form into multiple columns (possibly two) would have the advantage of appearing short (or not overwhelming eg. https://account.atlanticrecords.com/wallet/NewAccount.asp). Does this have significant disadvantages compared to a single-colum forum in which the user can move vertically without interruption? thanks.
“You can also use CSS to hide the fields that are already filled in correctly and only display those which need to be corrected.”
Why use CSS? CSS is for design. This is not a design element, this is a behaviour. For define behaviours of our document, we have to use JavaScript. Imagine if the user clears away the stylesheet, or defines his/her own.
First the (x)html, then write JS, and CSS should be the last component.
But is there are any css hack to make select input looks a bit less ugly
Cheers