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.
Copy & paste the code below to embed this comment.
Edmundo Ruiz
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.
Copy & paste the code below to embed this comment.
Roel Van Gils
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 “[removed]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.
Copy & paste the code below to embed this comment.
Adam Sanderson
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?
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?
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/
Thanks to everyone who has taken the time to read and comment on this article (especially the person who mentioned the [removed]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!
Copy & paste the code below to embed this comment.
Sandy Rubinfeld
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’?
Copy & paste the code below to embed this comment.
Roy Sinclair
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 :) ).
Copy & paste the code below to embed this comment.
Charles Belov
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 <noscript>This form requires JavaScript.</noscript>
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?)
Copy & paste the code below to embed this comment.
Charles Belov
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.
Copy & paste the code below to embed this comment.
Eric Brown
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 userdomain.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.
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 <abbr title=“Required field: you must not leave this blank”>*</abbr> 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.
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.
Copy & paste the code below to embed this comment.
Kevin Bolduan
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.
Copy & paste the code below to embed this comment.
Marcos Caceres
I’m a bit confused by the Brian’s mention of the <caption> element within a form context. By looking at the XHTMl 1.1 spec, caption is only allowed as a direct child of a table element (see http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_tablemodule)
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.
Copy & paste the code below to embed this comment.
Michael McLoughlin
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.
Copy & paste the code below to embed this comment.
kristie wagner
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??
Copy & paste the code below to embed this comment.
Andrew Hallock
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 <noscript>This form requires JavaScript.</noscript>
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 <caption> element is only for tables. I was absolutely mistaken.” It’s okay, sock puppet Brian. We all make mistakes.
Copy & paste the code below to embed this comment.
Andrew Peace
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.
Copy & paste the code below to embed this comment.
Johan Van Den Rym
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.
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.
Copy & paste the code below to embed this comment.
Edwin Tong
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.
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.
Copy & paste the code below to embed this comment.
Karen Johnson
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.
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.
Copy & paste the code below to embed this comment.
sarahana shrestha
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.
Copy & paste the code below to embed this comment.
Joó �dám
“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.
72 Reader Comments
Back to the ArticleJohn Lascurettes
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.
Edmundo Ruiz
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.
Roel Van Gils
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.
Rowan Wigginton
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).
Tamlyn Rhodes
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 “[removed]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.
Justin Rovang
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.
John Lascurettes
So your time is more important than all the end users’ time put together is all you’re really saying.
Adam Sanderson
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
Stephen Down
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.
Stephen Down
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.
Philipp Bunge
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. ;-)
Justin Rovang
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?Thomas Watson Steen
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?
Thomas Watson Steen
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
Brian Crescimanno
Thanks to everyone who has taken the time to read and comment on this article (especially the person who mentioned the [removed]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
James Craig
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!
Sandy Rubinfeld
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’?
Matt Sephton
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.
Roy Sinclair
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 :) ).
Charles Belov
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 <noscript>This form requires JavaScript.</noscript>
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.
Charles Belov
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.
Eric Brown
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 userdomain.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.
Brian Crescimanno
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.
Stephen Down
As an alternative, use <abbr title=“Required field: you must not leave this blank”>*</abbr> if writing “required” in full would make it look too cramped or untidy.
Ben Chestnut
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.
h b
This is not the high quality article that I’ve come to expect from ALA. Where are the examples?
Brian Crescimanno
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.
Kevin Bolduan
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?
Brian Crescimanno
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.
Marcos Caceres
I’m a bit confused by the Brian’s mention of the <caption> element within a form context. By looking at the XHTMl 1.1 spec, caption is only allowed as a direct child of a table element (see http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_tablemodule)
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.
Michael McLoughlin
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.
kristie wagner
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??
Andrew Hallock
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.
Brian Crescimanno
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.
Harshit Sekhon
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.
Cheyne Winterton
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
Alex D
Charles Belov says:
If your form requires JavaScript, rethink, but if you must, use a <noscript>This form requires JavaScript.</noscript>
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
Michael Newton
“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 <caption> element is only for tables. I was absolutely mistaken.” It’s okay, sock puppet Brian. We all make mistakes.
Andrew Peace
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!
Johan Van Den Rym
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
Rob Bolton
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.
Edwin Tong
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.
Brian Crescimanno
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
Brian Crescimanno
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
Benjamin Westafer
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.
Karen Johnson
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?
Michael Straker
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.
Dr Tim Thomas
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.
matthew willse
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.
sarahana shrestha
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.
Joó �dám
“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.
Viz Abdelli
But is there are any css hack to make select input looks a bit less ugly
Cheers