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 ArticleMichael 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