Excellent form implementations exemplify priority and simplicity.
To move toward this goal, the first step is to define exactly what a form needs to request from the visitor. In some cases these requirements and the design patterns used to fulfill them are well established by tradition and common sense, but in others there are too many mitigating factors—such as institutional culture, legal requirements, visitor expectations, and the use or neglect of Ajax—to rush directly into implementation.
I point all this out in order to encourage thoughtfulness and caution in design; the critical importance of forms does not easily tolerate foolish design choices made while leaping blindly.
Application security is beyond the scope of this book, but well worth addressing in detail. Please be certain to follow common security practices, especially sanitizing form input against SQL injection attacks.
Before attempting to design visual assets such as wireframes or composites, you need first to determine the form and function (if you will) of a form interface. The tasks involved can be divided and ordered as follows:
Determine the benefits and requirements of the form, for both visitor and operator. It may seem ingenuous to point this out, but in fact it’s far too easy for developers to consider forms only from their own perspective. When visitor requirements are taken into account, an entirely different set of design choices might be illuminated. ...