We’re filling out more forms than ever in our day to day activities. Whether it be sending an update to your favorite social network, a new social network you’re signing up for, or even sending a message to someone you haven’t spoken to in 10 years on a social network; forms are being used a lot. All kidding aside, the Web has evolved into a much more participatory environment, and with that come design considerations which may someday result in best practices.
Forms have been viewed as an area of Web design which has much room to improve. From the markup itself to general design guidelines, there are some trends which have evolved surrounding their implementation. Forms may be something you view as a smaller aspect of your overall design, but I’ve got to be honest when I say that seeing a well designed form is not something I often come across. When I do see a form which has been very well implemented, I try to take some notes to keep in mind for future projects. It’s difficult for me to express in words what it is that impresses me about well designed forms, but it’s quite a different story for me to jot down a few things which I find irritating.
Poor choices for field defaults
Providing a field default is, in my opinion, usually something that should be avoided. There are certain circumstances where it’s a necessity, such as using the input itself to reflect what would otherwise be represented by a label. Including a default input value is a significant annoyance if not implemented properly. Always keep in mind that if you are going to provide a field default, make sure you add it with progressive enhancement in mind. I say that because more important is making sure your default is cleared out upon input focus. I can’t count the times I’ve gone to enter data in a field with a default value and ended up typing within the default string itself. It’s a show-stopping event.
Field defaults are in no way limited to text inputs or textareas. A peeve of mine which has developed over the past few months is finding a default entry in a select. For example, stumbling across a form which has a select for the state in which I live. This particular select has a default value of “(Choose One)”. Why? The widget itself is designed visually to communicate that there are a number of values to choose from. A select is not an uncommon interaction with a form, why is it necessary? If nothing else, it requires you to apply otherwise unneeded validation on the element. I can possibly understand that it may be used as a method for ensuring the reader has taken the time to choose a value from the select, but to me that’s a stretch. What’s worse is seeing “(Choose One)” as the default entry with “Other” or “No answer” as the bottom choice. For selects without required data, why not make “No answer” the default?
At the end of the day, if the select is required data, you’re creating extra work for all parties involved by trying to hook an answer with “(Please Choose)”. From the start, you’re going to need to validate that field. Continuing, if a reader is maliciously trying to submit bunk data, when notified of the required field, an entry will simply be chosen at random, which now looks like a more legitimate answer than “Other”.
Another issue I’d like to bring up with form defaults is one that has to do with radio buttons. Interaction here is very similar to that of selects but in this case, my annoyance happens to be an absence of a default value. The purpose of a series of radio buttons is to have a reader choose one of the available choices. Why leave this section of your form without a default?
Validation issues
Form validation is an art form. There are some really fantastic ways to validate forms which not only benefits your server, but also the user experience as well. With the widespread arrival of unobtrusive JavaScript, form validation on the client side has been improved exponentially, but there are still some pitfalls which can result in a very frustrating process for your readers.
Most importantly is being upfront about what data is required when filling out your form. On top of that, you should provide relevant information regarding any syntax required for entering data. Information such as phone numbers, credit card numbers, and dates come to mind. Readers are likely to follow instructions on formatting, and be much happier doing so as opposed to seeing they entered a date wrong because you failed to provide syntax.
A huge peeve of mine when it comes to form validation can only stem from laziness on the part of the developer. It doesn’t take much to check whether each field was populated already on a page load, so be sure to include the submitted data as a ‘default’ value when exercising validation. There’s nothing worse than taking time to fill out a form only to have the page reload saying I forgot a digit in my phone number, but the rest of my data is missing.
Finally, on the side of form validation, make sure your error notice copy is up to snuff. Ensure the notice is contextual and you’re not taking the easy way out by dumping the errors at the top of the page, leaving the reader to hunt for information to correct. Make sure each error description is accurate and easy to interpret. If a credit card number was entered incorrectly, do more than classify the data as “invalid”. Explain, using syntax if applicable, why the entry does not validate.
Avoiding general frustrations
There are number of other issues to consider when designing forms. Something I continue to run into time after time is the classic case of recursive selects. I will despise this implementation until the end of time. I can understand that it may be a way to de-clutter the UI a bit, but at a serious cost to usability.
Another frustration that often surfaces is poor use of tabindex. Browsers are quite good at figuring out a logical order for tabindex if the developer hasn’t implemented one, but they’re not perfect. There are many (high profile) websites with terrible implementations of tabindex, dragging readers here & there in a very disorienting manner. Issues with form jumping can be easily avoided with a quick implementation of a logical tabindex.
I know I’m not alone when I say I’ve got a few annoyances when interacting with forms on a daily basis. What is it that truly bothers you about poor form design? What tricks do you have up your sleeve which have worked out really well in practice?
Comments
Thanks for a thought-provoking post — thought I’d share my own viewpoints.
I do disagree with you on the defaults of a select box. Imagine a list of countries from which a user should choose one. A default value of “Please select” is beneficial for the following reasons:
* From a developer/validation perspective, you know instantly whether the user has made a choice. There is a posibility that a user may simply have skipped the field accidentally.
* Unless you can reasonably guess the location of the user (e.g. by an IP geolocation, domain name etc.) then it would be wrong (in my opinion) to pre-select the first country in an alphabetical list. It would feel more “wrong” for me to land on a form preselected with Afghanistan than a “Please select” asking me to choose myself.
* When two values in a select box look similar and appear consecutively (for example “United States” and “United Kingdom”) then pre-selecting one could lead to confusion. If I know I am a UK user signing up to a US website, there’s double validation I need to do in my head a) I need to choose a country, does that already say US or UK? b) I don’t live in the US, I need to choose UK.
Country select boxes are problematic in other ways however. One annoyance of mine is putting the most common countries at the top of the list, then the rest alphabetically.
You then contradict youself by saying that radio buttons should always have a default. While I agree with you, I agree for a different reason. “The purpose of a series of radio buttons is to have a reader choose one of the available choices”; which is the same purpose of a select box, which you say shouldn’t have a default value.
The difference between a select and radio buttons is that with a select box we don’t have a choice *not* to provide a default value. One will always be visible. But with a radio button, if no default is provides, it is not obvious to a user that they need to make a choice. It might simply be assumed that the fields are optional or worse, have them mis-interpreted as un-ticked checkboxes. Providing a default gives a hint.
@Nick Dunn: Your concern outlines something that occurred to me as I wrote the piece. I tried to think of a best case scenario for choosing a country, but couldn’t think of one to be honest. Perhaps I can revise my stance and say that my annoyance with “Please select” as a default option is not universal. Country selects are indeed unique.
You’re absolutely right in pointing out my hypocrisy with radio buttons. I totally agree that it doesn’t make the most sense, and your insight is definitely helpful. I didn’t really think of things as you’ve outlined, but I like what you’re saying. Perhaps my reservations as outlined in the article are predisposed due to my past interactions with poorly designed forms?
Thanks for your well thought response, I hope it sparks further conversation!
On selects, you could easily use the following syntax for a “Please choose one” option and not have to do anything extra in regards to validation:
<option value="">Please choose one</option>As you’ve argued, I’m not sure something like this is even necessary, but I’d rather see “Please choose one” – or something similar – then having it default to the first actual option in the drop down.
On validation, I like to display all error messages at the top of the page, and then highlight each error near the appropriate field. That way, the user knows immediately what went wrong, and they can quickly find the fields needing correction.
Oops, that didn’t display right. The markup I was looking for is:
Please choose one
P.S. It would help if you let us know which HTML we can use in the comment field, Jon 😉
He shoots, and misses again!
Let’s try this:
[ option value=”” ]Please choose one[ /option ]
P.P.S. Or maybe just a preview button.
@chris: Thanks for your suggestion, and I apologize for my lack of proper instruction on the comment form! I think I’ve updated your original comment to reflect the code you mean. I may find myself alone when it comes to being irked by initial defaults in
selects.I definitely agree with you on the recursive selects. They are very useful when they are around. For example, when ordering parts for my car. But, I would rather see multiple pages with breadcrumbs for what I selected earlier. For usability, as you mentioned.
I don’t really have a preference on the select boxes. Obviously, a default value that can pass validation would be bad. But an option of “Please select one” or just a blank select option with no value set would be fine.
One thing that annoys me about form validation is the error messages at the top. I like to see the error messages “attached” to the form element it belongs to. That way I can just scroll down the page quickly to see where exactly I made the error and fix it.
The decision to include a default value on selects and radio buttons should depend on whether or not those fields are required. In both cases, defaulting to a selectable value on non-required fields would result in a value being submitted regardless of whether or not the user wanted to leave these fields blank.
Even if the fields are required, I fail to see how automatically choosing an option could be anything but problematic for a user. The form SHOULD show an error if the user doesn’t actually make a choice.
Hey there, I just wanted to say nice article, I found it very interesting. I am 22 years old and earlier this year landed my first programming job at a web development company. Often times on our websites I still end up doing a lot of the grunt work and that often times includes the forms for the websites so reading this article gave me a lot of new ideas to think about when creating my forms.
I agree that validation is almost an “artform” as there are many ways to go about doing it, however there are also practices that should be followed to go about doing it in a well fashioned way. When I started at this job one of the FIRST things I noticed is that the previous developers often times did little or no validations at all on their forms! I thought it was the craziest thing ever and spent a lot of time re-coding their existing work.
Anyways, guess that’s all I wanted to say. Came across your site for the first time today and within five minutes I had already bookmarked it so ya might see my comments again sometime! 🙂 Have a good day
Darren
@JR Tashjian: I think a bit of my OCD snuck into my annoyance with a few of the issues I brought up in the piece. I whole-heatedly agree that error messages grouped at the top of a page (without replication next to the field itself) are nearly useless.
@R.A. Ray: You’re definitely not alone, I should have been more specific in stating that it does indeed depend on implementation.
@Darren Felton: Thanks very much! I’m really glad you enjoy the site, and thanks for the encouraging words. I hope you find some other pieces of interest as well!
Sorry for taking this long to reply, all. Last week got a bit hectic!