Discuss: Sensible Forms: A Form Usability Checklist
by Brian Crescimanno
- Editorial Comments
52 Buttons on forms
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??
posted at 05:53 pm on January 10, 2006 by kristie wagner
53 Contraining Users
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.
posted at 08:13 pm on January 10, 2006 by Andrew Hallock
54
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.
posted at 12:51 pm on January 12, 2006 by Brian Crescimanno
55 Why does usability take a backseat?
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.
posted at 07:52 am on January 16, 2006 by Harshit Sekhon
56 Untitled
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
posted at 12:21 pm on January 16, 2006 by Cheyne Winterton
57 Reaction to Charles Belov's noscript suggestion
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)
posted at 06:16 am on January 17, 2006 by Alex D
58 Untitled
“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.
posted at 09:52 pm on January 19, 2006 by Michael Newton
59 Brilliant!
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!
posted at 09:52 am on January 25, 2006 by Andrew Peace
60 Untitled
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
posted at 06:03 pm on January 26, 2006 by Johan Van Den Rym
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)






51 Avoid altering default behavior
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.
posted at 11:46 pm on January 9, 2006 by Michael McLoughlin