Server-Side Form Field Validation
- Client-side validation reduces server usage.
- Client-side validation dependent on browser scripting. Intense user aggravation when a
form page wont 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
- Highly complex client-side validation scripts can make for heavy, slow pages.
Form Validation Best Practices
- 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.
Web Form Suggestions and Best Practices
- 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
- Use caution when applying styles to form fields.
- Form fields should be as short as possible. Since fields do not wrap, avoid making them
- 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 users 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.
Search/Query Web Form Best Practices
- Design forms assuming most users dont 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 users 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 users
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.
Recommended Form Tests
- 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
- In TEXTAREA boxes, be careful of carriage returns.
Valtara Digital Design http://www.valtara.com/csc123/
Copyright 1999, 2001, Valtara Digital Design, Blitzkrieg Software