Form Design Notes

Building & Managing Web Sites
Form Design

Client-side validation reduces server usage.
Client-side validation dependent on browser scripting. Intense user aggravation when a form page won’t work correctly due to client-side scripting errors.
Server-side validation can perform more robust checking.
Many validations are business rules, and server-side validation supports best practice of moving business rules to a client/server middle tier.
Reliance only on client-side validation does not protect server-side scripts from malicious inputs.
Highly complex client-side validation scripts can make for heavy, slow pages.

Test all validation rigorously. Test client-side validation even more vigorously.
Use client-side validation for simple checking (e.g., empty fields).
Perform complex validations on the server.
Client-side validation dialogs should be clear, concise, and include a caption.
Validation messages should be clear and specific.
Validation should jump to the field(s) the user needs to correct.
Avoid validation alerts to the user that makes them feel stupid.

In general, forms should be short and simple with minimal amounts of text.
Browser render form fields very differently, so avoid forms heavily reliant on complex formatting.
Use caution when applying styles to form fields.
Form fields should be as short as possible. Since fields do not wrap, avoid making them too wide.
All data submission forms should have some type of confirmation page.
Avoid returning user input on confirmation page unless it can be edited.
Use Radio and Checkboxes correctly.
Avoid very long forms. Break into multiple pages.
Provide an indication of the user’s progress on multi-page forms.
Form should not return a server error when submitted with empty fields.
Allow user to go back in multi-page forms.
Field caption text should look different from explanatory text.
Forms with sensitive information should expire immediately.
Test, test, test your forms.
User testing of forms is critical.
Consider malicious or accidental inputs in server-side form processing.

Design forms assuming most users don’t understand Boolean logic.
Offer no more than 2-4 search elements on entrance query/search forms.
Use radio/checkboxes when 2-4 options are listed. Use Drop-down fields for longer lists.
Provide an advanced/alternate form for more sophisticated searches.
Prominently feature the user’s query with the query results.
Return a count of the query results.
Provide some indication of where user is the result count.
In many cases results are best formatted without visible table borders.
Query results should include the date/time and a specific URL.
When possible, replicate search interface in query results, ideally with the user’s current query inserted into the interface.
When queries return no results, offer suggestions on alternate strategies.
Submit button should be visible in the first screenful.

Default form submitted--user does not enter or change any data.
Text data in numeric fields.
Bogus dates--a good date to try is February 30.
If data not entered in a field, do later pages fail due to database null values. Especially important for fields that might be searched.
SELECT elements either don't allow multiple selections, or thoroughly test multiple selection features.
Submit extremely large/long data into your fields.
If your form deals with dates, be especially cautious of form behaviors that cross over to the next or previous year.
In any text data entry that will be submitted to a database via a SQL statement, check for and do a server-side replacement of apostrophes with appropriate characters for your OS/database (two apostrophes for ASP/SQL Server).
In TEXTAREA boxes, be careful of carriage returns.

Valtara Digital Design http://www.valtara.com/csc123/
Copyright 1999, 2001, Valtara Digital Design, Blitzkrieg Software