Have I missed anything from my list of web form best practices?

Question

So I have been putting together a list of best practices to apply to forms recently and there is a lot of conflicting research out there. I have been combing everything from blogs through to HCI conference reports. So the question is have I missed something or included anything that has since clearly been refuted through research?

Field labels

The following should be a table but UX doesn't seem to render them properly.

Label placement

Short form with simple/short labels  =  On top or to the left, but right aligned
Short form and complex/long labels   =  To the left and left aligned
Long form and simple labels          =  To the left, but right aligned
Long form and complex labels         =  To left and left aligned

• Labels should use sentence case and not title case as it is much easier for the human eye to read
• Bold text should also not be used for form labels for similar reasons

Required fields

• Legend describing meaning of required indicator at the top of the form
• Asterisks (standard indicator) to appear after the form fields label
• Asterisks should ideally be highlighted by a colour - red by convention
• Do not rely on colour alone to indicate an error as this can be easy to miss, difficult for colour blind people etc
• Do not confuse the meaning of the asterisks by using it to denote optional fields
  • Firstly fields marked optional should generally be avoided
  • Secondly they should have the full word after the field label e.g. (optional)

Buttons

• Submit button should appear at the base of the form and be right aligned
• Avoid reset buttons as they have no use to real people and just annoy when accidentally clicked
• Make the path to completion as visible as possible - one button equals less load as there is no choice to be made

Grouping

• Relevant fields should be logically grouped together
• Consider using a fieldset to group more than two fields

Errors

• Never rely on colour alone - all errors should be accompanied by a text explanation
• There should be a message at the top of the form stating that there are errors in the form that need to be corrected
• Individual error messages for each field describing the issue for that particular field should appear above the label and field
• Messages where possible should be vanquished by client side validation as the user resolves them
• Messages can also appear to the right of a label and field if error messages are of a suitable length and the form is not too wide

Select lists

• Should be used for 3 or more options - less than this and radio buttons should be used
• Anything more than 15 options should always make use of the Chosen progressive enhancement script
• If Chosen is used the other select lists in the form should maintain its style
• Use them sparingly as they are very heavy and eye catching
• The first option in the select list must be a place holder
• Place holder should reflect the label rewritten as an action

Place holders as labels (ala Apple store)

• These should be avoided as it makes it hard to review a form before submitting it
• They should fade slightly when the fields is given focus
• Place holder to disappear only when the user enters some text and triggers keyup

Date fields

• Should be enhanced by the use of a calendar date picker

Form success

• Redirect the user to a confirmation page on successful completion of the form

The redirect on success stops the user from seeing messages like “Resend submitted information or cancel?” It also stops users from the refreshing the page and triggering a re-post.

Answer 1

Accessibility

• Provide a logical tab order for keyboard only users.
• Provide labels for all controls for screen reader users.

You can get more info at these links:

http://www.jimthatcher.com/webcourse8.htm

http://www.afb.org/section.asp?SectionID=57&TopicID=167&DocumentID=2375

http://webaim.org/techniques/forms/

Answer 2

User interaction

• Forgiving Format: Permit users to enter text in a variety of formats and syntaxes, and make the application interpret it intelligently. (Jenifer Tidwell)
• Input Hints: Beside an empty text field, place a sentence or example that explains what is required. (Jenifer Tidwell)
• Good Defaults: Wherever appropriate, prefill form fields with your best guesses at the values the user wants. (Jenifer Tidwell)

Organizing the form

• Split the form into several pages and use a wizard (with a progress bar) if the form is very long or if it is natural to go form step by step or i a particular order.
• Responsive disclosure or Responsive_Enabling: If some part of form should is rarely done, you could hide/disable this part until it is needed.

Testing

• Perform some user tests on the form. Measure how long it'll take to complete, measure the dropout and remove ambiguities.
• Check how the form looks and behaves in different browsers and on different devices (ex. touch devices).

Answer 3

Nice list. All I can think to add is to detail how the form will need to work for Non JavaScript users.

Non JavaScript users

• Place holders as labels, date picker, in-line errors for example would all need specific no-script alternatives.

Answer 4

There is not one answer to all questions

As you say, research conflicts here. To me there is no one-way answer to these issues. I would say that a lot of these things depend more on the situation in which they are used. It can be better to apply a set of generic ideas (like Pau Giner answered), instead of checking all items on the list and thinking you're done.

Be friendly

I would add one generic rule: Be friendly to the user.

For example in not giving them the fault saying that there are errors in the form, instead say something like almost there! can you fill in that field as well?. Another example is to remember filled in fields after the form said there are problems.

But again, these are just examples. To me it is better to keep such generic rules in mind.

A little nuance to giving examples

Firstly fields marked optional should generally be avoided

Sometimes it can be very good to both mark required and optional fields, especially when used in combination with sets of fields. And you can for example hide all optional fields in a > Advanced options section.

Submit button should appear at the base of the form and be right aligned

That depends on the looks of the whole form, and how the labels, fields, and rest of the page is aligned. As Daniel Newman also said.

There should be a message at the top of the form stating that there are errors in the form that need to be corrected

Individual error messages for each field describing the issue for that particular field should appear above the label and field

When there is only one 'error', name that error in detail directly at the top instead of leaving the user with a general "there are errors in the form".

[Select] Place holder should reflect the label rewritten as an action

There are more elaborate answers about that subject, see What should be the default option of a required dropdown list?

[Place holders as labels] These should be avoided as it makes it hard to review a form before submitting it

In short forms (up to say 5 fields) that doesn't have to be a problem and can create a much more clean form. Also when there is constant feedback about the fields you're filling in, there is less need to check everything before submitting.

[Date fields] Should be enhanced by the use of a calendar date picker

Depends on what kind date you want. Do you really need that precision of a single day? For example when asking people when in the future to remind them of something, a list with tomorrow, Saturday, next week could also be enough.

Redirect the user to a confirmation page on successful completion of the form

Could be a bit more subtle, the confirmation page isn't always thing successfully added, but could also show the thing added (like when posting an answer here). The redirect part (preventing a refresh warning) is a good thing though.

---

I hope it helps.

Answer 5

Very, very helpful post. Just one change that I would recommend:

Buttons

Submit button should appear at the base of the form and be right aligned

I would argue that the placement of a submit button depends on the form style. In a multi-stage "wizard", I absolutely agree that next/continue/submit should be right-aligned. However, for more simple forms (especially when there is only one button; no back/previous button), I believe that the button should be left-aligned with the input fields, to minimize visual fixations and follow the user's visual path (Sources: "How you should align your form buttons" & "The best way to align buttons on forms").

Also, to add to this section, Submit buttons should never just be labeled "Submit"; rather, they should be task-specific... e.g. "Create Account", "Subscribe Now", etc. (Source: "Why your form buttons should never say submit")

Answer 6

Some design principles that can be general but apply to form design:

• Avoid the unnecesary. Avoid asking information that is unrelated to the purpose of the form. Use flexible input, structured input or the fill-in the blanks approach instead of asking for specific formats.

• Organize the information. Most principles regarding layout have been already commented.

• Provide guidance to the user. The user needs explanations that clarify what, why and how to answer.

• Don’t make things difficult on purpose. Don't hide options or force the selection of the user (e.g. newsletter subscription). Explain the benefits instead.

Months ago I posted about those principles. You can obtain more detail and examples at http://pauginer.tumblr.com/post/7080830292/form-design

Answer 7

Personally I don't use asterisks to denote required fields. All fields are required by default. I put '(optional)' next to the additional, optional fields.

Answer 8

I can add a few things, more about what data you collect than how you design the form:

If there's only one thing to know about a user, ask about that

Many web pages and services demand a full gamut of information about a user, when there's often only one of two things about a user that they need to know. If you're serving content that's inappropriate for minors, for example, all you really need to ask is "Are you over 16?" - not demand my name, email, telephone number and full date of birth.

If the user has already submitted some data, never ask for it again

It's not just annoying for the user to enter data several times - when you make a user submit more than once, there's always the chance they create a duplicate record by entering the same data slightly differently. Think John Smith submitting 'John William Smith' on one form, 'John W Smith' on the next. These duplicate records create major headaches for both you and your users further down the line.

If you can guess data from heuristics, try that

If there's any other information about the user which suggests certain data, try and default your form's options appropriately. For instance, if your user is connecting from a French IP address, set 'Country' to 'France'. If you're offering a user a software download, and their user agent suggests they're using Linux, offer them a Linux version by default.

Answer 9

Buttons

I would say that input:reset elements can and should be used with the label of "cancel"; they should also look distinctly different from the input:submit button. Quite often the cancel button should perform additional functionality (e.x. kick the user back to the previous page/step/state/whatever), but part of the functionality should also be to clear the form of all data.

Answer 10

validate on both sides:
client-side, for ux; ideally you can accomplish this via html5 attributes alones.
server-side, for validation; validate all form controls to ensure successful, and secure form submission.