| Introduction Compared to most elements of Web application design, HTML forms are refreshingly simple so you can focus more on business and data tier design. Nonetheless, it's still possible to spend an extraordinary amount of time developing and maintaining forms. With care, you can reduce the effort behind this task and produce better results as well. This article presents some good practices in design and implementation of cross-browser HTML forms. It assumes the use of Source view in Visual InterDev or a text editor. This is by no means a comprehensive study, just a few guidelines. The Need for Good Form Design Here are a few benefits of solid form designs: - reduced development time
- increased reuse of code
- enhanced user experience
Some Principles Behind Good Form Design Before you begin coding the forms in your application, take a moment to plan your site. Isolate the points in your application where you will be using forms for data input. Next, for each input screen, whiteboard a few layouts or sketch them on paper. I've used various tools to assist in this process but usually revert back to a blank sheet of paper. Layouts should be simple and clear. Try to split your form into sections with appropriate subheadings. This will help the user understand what is being requested. It will also encourage you to place data entries in a logical sequence, which is often what a user expects. Prototypes are very helpful during the design process. After you've decided on layout, present it to your customer. Hard copy is acceptable, but a simple prototype can usually be put together quickly. However, be cautious with this approach -- customers sometimes forget that there is more to an application than a set of screens. Explain that your goal is to settle on a layout early in the development cycle so that you may apply it throughout the project. Finally, do a little surfing. Examine how other sites present forms. Web design is becoming more standardized, and as a result, users expect more uniformity. A number of shopping sites mimic Amazon's look and feel, while many reference sites tend to follow Yahoo!'s example.
Details About Tables Use tables to lay out your form. How you implement tables is important, so here are a few guidelines to follow: If possible, the table should be no wider than 600 pixels or so. Nearly one-third of your users may be using monitors 15 inches or smaller (see http://www.gvu.gatech.edu/user_surveys) and will have to horizontally scroll to view the entire table if it is larger. To do this, use a single-pixel transparent gif spacer in the column definitions or create a blank table row at the top or bottom of the table, which contains the spacer. Example: <tr><td><img src="/images/pixel.gif" width="600" height="1" alt=""><br></td></tr> - Set the table width to 100% and the table will expand to fill the screen for users with larger monitors. If you leave the width attribute off the table definition, the table will not expand.
- Table borders should be set to 0, which will result in a cleaner, more usable interface.
- Use cell padding or spacing attributes or spacer cells to create white space between columns.
Note that there is incomplete support for the width attribute of table cells. You are better off using the single-pixel gif technique mentioned earlier to provide an absolute value for a column.
Details about Form Elements There are a number of points to consider regarding form elements, as follow: - Limit the number of items in your select lists. Long select lists of greater than 100 items are not only difficult to use, but they are also a performance hog and may even crash older systems.
- Put the most often-selected entries at the top of the select list. This may apply to checkboxes and radio buttons as well.
- When possible, use the size attribute with your select lists. Again, this is easier to use.
- Typically, checkboxes are used to implement on/off choices, though some users may prefer a radio button.
- Don't present long vertical lists of checkboxes or radio buttons.
- Both select lists and radio buttons should have a default choice selected.
- Avoid using Reset buttons except in applications that support continuous data entry. Usability studies have shown reset functionality is not needed by most users (see http://www.useit.com/alertbox/20000416.html).
- Field labels should be displayed in a distinct manner from the form element. Ideally the label will help indicate what should be entered in the field.
ASP/VBScript-Specific Implementations Consider using a COM object to render tables and forms. Not only can this be a real time-saver, but it will also help enforce consistency throughout your application. Several objects are available for purchase or you can develop your own. Another option worth exploring is the new Class capability in VBScript 5.0. Classes give you the capability to organize raw script into a component structure with methods that can be called like COM objects.
| 
