[play.webdev] Playground standards for online forms (v0.8)

  • From: "Chris McGrath (PLAY)" <cmcgrath@xxxxxxxxxxxxxx>
  • To: "'play.webdev@xxxxxxxxxxxxx'" <play.webdev@xxxxxxxxxxxxx>
  • Date: Mon, 27 Oct 2003 10:26:02 -0800

Hi all,
 
We've started a document with standards for online forms at Playground. This
was developed for our intranet (uPlay), but many of the standards are
valuable for contact forms, preferred customer registration forms, etc.
 
If you have any suggestions for these standards, please email them my way.
Thanks!
 
Web page attached.
 
Chris
 
 
c h r i s  m c g r a t h
internet systems analyst

  p l a y g r o u n d
 division of intrawest

www.greatplaygrounds.com
 telephone 604.675.7532 
 
   
Standards for uPlay Online Forms

Our goals

  1. Make uPlay forms as easy to use as possible
  2. Solve design problems up-front to reduce development time
  3. Keep uPlay forms consistent across-the-board

Contents:

  1. Breaking up form into sections
  2. Step-based forms vs. 1 long form
  3. Requesting date input
  4. Data validation
  5. Error prompts
  6. Indicating mandatory fields
  7. User testing
  8. Caption placement
  9. Button naming
  10. Background colour
  11. Stating required documents up front
  12. Confirmation screens
  13. Generated emails


1. Breaking up form into sections

All forms should be broken up into logical sections. Similar information should be grouped together under a heading.

Sample:
Form divided into sections
Figure 1.1

TOP


2. Step-based forms vs. 1 long form

Break forms up into steps if any of the following apply:

  • The form will take a very long time to complete and it is important to maintain a connection to the server
  • The information cannot be captured in approximately 2 screen lengths or less
  • The form changes based on user input
  • The transaction is very critical and the user must be assured that they are doing the right thing

Follow these guidelines for step-based forms:

  • Indicate what the current step is
  • Indicate how many steps are left
  • Keep the submit button above the fold
  • Submit button should be titled "Go to next step"

Sample of a step-based form:
Sample of forms divided into steps
Figure 2.1

TOP


3. Requesting date input

Date input should be requested via dropdowns. This improves data integrity and eliminates confusion over mm/dd/yy, dd/mm/yyyy, yy/mm/dd, etc.

Sample:
Sample of date input box
Figure 3.1

Clicking the calendar button pops up a calendar so the user can click on a date instead of clicking the each dropdown.

Sample:

Figure 3.2

TOP

4. Data validation

Data validation is always both client-side and server-side. Server-side and client-side should behave identically. Do not use _javascript_ pop-up boxes.

TOP

5. Error prompts

  1. Indicate errors in red text to the right of the input box or caption.
  2. Summarize errors in red text immediately above the submit button

Sample: See figure 2.1 above

TOP

6. Indicating mandatory fields

  1. Indicate mandatory fields with a red asterisk immediately after the caption
  2. Under the submit button add this footnote: * Required fields are indicated with an asterisk

Sample: See figure 2.1 above

TOP

7. User testing

User testing is the only way to validate our assumptions about the best way to design online forms.

  1. Watch users perform a pre-defined list of tasks.
  2. Don't talk.
  3. Ask the user to think out loud.
  4. Test 5 representative users (why 5 is enough)
  5. Take notes
  6. Be careful about using Vancouver staff only, who may be more computer saavy than the intended user

TOP

8. Caption placement

Place captions immediately above the input field.

Sample: See figure 2.1 above

TOP

9. Button naming

Name buttons carefully.

  1. Start with an action word (Go, Save, Create, etc.)
  2. The button should describe, in 5 words or less, exactly what will happen when it is pressed. For example, "Send SOs to leader" is better than "Submit". "Complete purchase order" is better than "Finish"
  3. Do not use "a", "an", "the" or other unnecessary words
  4. Only capitalize the first letter of the first word

TOP

10. Background colour

Use a light colour behind forms. This helps the input boxes stand out clearly.

Sample background colors:

Sample: See figure 1.1 above

TOP

11. Stating required documents up front

If a form will require certain documents to complete, state that at the beginning. Examples:

  1. Driver's license
  2. Passport number
  3. SIN or Social Security number
  4. Credit card number
  5. PO number
  6. Budget category ID

TOP

12. Confirmation screens

On all forms, end with a confirmation that the form data has been received, and explain what will happen next.

Sample:

Figure 12.1

On complex forms, the 2nd-to-last screen should be a review of all data entered to that point. It should give the user the ability to edit any of the data.

Sample:

Figure 12.2

TOP

13. Generated emails

If a form generates email, follow these guidelines:

  1. Write a brief, descriptive subject line
  2. If action is required, start subject line with "ACTION REQUIRED: "
  3. Give something unique in subject line so multiple emails from the same system can be differentiated. Use names. For example: "ACTION REQUIRED: Complete exit checklist for Jack Nimble"
  4. Provide details in message text. Instead of "There is a new Purchase Order for you to review", say: "Jack Nimble has requested you to approve the following purchase order:" Then output purchase order details in the email, like date, number of items, etc--possibly even the entire purchase order.
  5. Provide hyperlink to system in message text.

TOP



   

Other related posts:

  • » [play.webdev] Playground standards for online forms (v0.8)