7.8     Form design

This is NOT the latest copy of this book; click here for the latest version.

As mentioned already, forms are the primary way for users to send data to your scripts, so its essential you get them right. Above and beyond the coding aspect of forms, there are a number of basically usability guidelines you should follow in your design:

• Use tables to lay your elements out neatly. This makes the form easier to read, and it is also easier to report individual errors on fields.

• If there is an error with a field, put a notice next to it and a message at the top - if you don't put the message at the top, people will not realise there is an error, and if you don't put a notice next to the problem field, people might not spot it amongst the others.

• Mark required fields - either with bold text, or, more commonly, an asterisk *.

• If your database has a field limit, put a size limit on a text box - this stops people from entering too much text and later finding out their data has been trimmed by your database.

• Don't make your forms too long - they confuse people and make them feel threatened.

• If you split your form across pages, let your visitors know how far they are through the process of form submission e.g. "Page 2 of 5" - this lets people know where they stand at all times, without leaving them wondering "will this next button take money out of my account, or are there more pages to come?"

Note that for the purposes of this book, most examples do not follow the principles laid out above. Yes, this might sound hypocritical but it is a simple matter of space - I do not think you would like to have large chunks of the book dedicated to making output look nicely formatted in HTML.