Usable Forms
One important part of designing websites for user interaction is creating effective and usable forms. There are several main cases where users will have to fill out a form in an ecommerce site: (1) completing the checkout process, (2) registering with the site, and (3) contacting you for information/quotes etc. In addition, depending on your site, you might have other functions that require people to fill out html forms.
Generally, people don't like filling out forms. They especially don't like it when they aren't sure what you are going to do with the information - so always explain why they need to fill out the form at all. In some cases, it will be relatively clear, so you probably don't need to explain why you need to collect their address during the checkout process. But in other cases, it may not be. Just why are you asking for their fax number? And what are you going to do with their date of birth? You should first make sure that you don't collect any information that you don't really need. Don't collect a whole lot of information just because you can in the hope that you can use it later. People might suspect that you are planning on selling it, and be much more reluctant to even fill out the form in the first place. If you do really need some information and it might not immediately be obvious just why, then it can be a good idea to include a brief explanation of what you need it for.
The next thing to consider is the overall layout of the form. Sometimes forms contain a lot of fields, so that the user has to scroll down to fill them all out. This can seem a bit daunting, so it may be better to split them over several pages. This also means you can check the validity of a little bit of the information at a time, and can possibly use information entered on earlier pages to change the options available on the later pages. On the other hand, if you split across pages, the user has to wait for the page to load each time, and this delay may be annoying, particularly if there are only a few fields on each display. Also, there should be some logical partitioning of the fields that have been split up, otherwise it will all seem a bit random and disjointed. Still on the subject of layout, you must pay attention to how the fields are grouped, and how the labels are positioned in relation to the data entry fields. http://www.lukew.com/resources/articles/web_forms.html has a good discussion of the options with examples.
Next, you should consider the fields themselves. There are a number of typical cases:
Names: Input boxes. make them long enough to hold fairly long names. Either one single name field, or split into first and last name. It is best to call these 'given' and 'family' names as the customs for name order differ between cultures. If yours is a western audience though, you should put the given name field first.
Addresses: Two main possibilities: Either use one large text area, and allow people to use enter to create new lines within it. This means that you can't use enter to submit the form. This is best if you get orders from a very wide variety of areas with different address formats. The other main choice is multiple lines, say one for street address, suburb, city, country and post/zip code. Country is usually implemented as a drop down box. If you only ship to some countries, only put them in the box. If you truly do ship anywhere on the planet, then make sure you have an up-to-date country list. If a large proportion of your customers come from one country, you could consider making that the default, otherwise the list should initially say something like 'please select'. The size of the field should give an indiciation of how much you expect in each box. For instance, your post/zip code field should be the approximate length of a typical postcode.
Dates: You can either give an unconstrained field for typing a date in, unconstrained fields for typing in parts of a date (day, month, year seperately), constrained fields for typing in parts or a calendar control on which the user can click to select the date. If you are collecting birthdates, consider that most people know their birthday, and can more easily type it directly than select it by any other means. With credit card expiry dates, you should mimic the format it appears on their card. Either require them to type or select from a dropdown something like 04/08, don't make them either type or select April 2005, because doing so incurs a bit of cognitive overhead, as they need to internally make the translation. It isn't much, but simple things like this can just make the overall experience of using the form so much better. If you application is very date conscious, and particularly if the range of dates they need to select from is narrow (say, next three months), then consider using calendar controls. This could be the case for travel bookings, appointment bookings, and things like that. Being able to see that they are booking for a Saturday and so on can help prevent accidental errors. If you are giving unconstrained fields and you do want a particular format, make sure you say so, preferably with an example. (eg 24/02/04). If there is a meaningful default value, fill it in.
Validation: the first and easiest way to validate is to use the appropriate controls for the information you are trying to get. Next, you can set maxlength on fields to ensure that people don't enter too much though. Make sure the number you set really is the maximum valid value. There's no need to set one just because you can. It's unnecessary to set it for something like name, for instance.
Make your error messages gentle and constructive. Imagine you are sitting next you beloved old Aunt Mabel, and she is filling out the form and has made a mistake. What would you tell her? This is what you should tell your form users. Don't just say 'error, please correct', say 'Please enter your email address before you continue', and then set the focus to the email address field. Yes, this requires javascript and a lot more effort, but if the form is important to your site, then it is worth taking the trouble. Make sure though, that even users without javascript get something useful - this often requires having both server and client side validation.
When they do submit the form, make it obvious that something has happened - display a clear confirmation message.