An HTML form should…

• Provide good instructions. Indicate to the user what they should do, what will happen next, etc.
• Clearly indicate which fields are required. Use of asterisks, bold font, or a different font color is the standard. Also have a note that indicates that these formatting changes mean the fields are required.
• Explain why specific data is being requested. This is particularly important, as you want to make the user comfortable when providing their personal information. If you’re asking for anything sensitive or just somewhat unusual, make sure you include the reason why. It’s also a good idea to let the user know that their personal information–email address and phone number, in particular–won’t be used for malicious purposes.
• Use client-side (i.e., JavaScript) form validation. You absolute must also use server-side validation (for security purposes) but using client-side validation gives the user immediate feedback, without having to send the page to the server.
• Use the fieldset and legend tags to distinguish the form from the rest of the page. I really like these tags and also feel they are underused. Multiple fieldset and legend tags can be used to separate a longer form into its logical components. See the example for what these do to a form.
• Place a submit button at the top and button of a long form. I’m not completely sold on this one but thought I’d mention it as Rob Huddleston advocated it in his presentation. The argument for it is that user’s often go back up to a page or may like having it there if they have to correct a couple of quick things. The argument against it is that it may encourage the user to submit the form prematurely (i.e., before they’ve scrolled down and seen the rest of the form).
• Use the label tag for all inputs. This is an accessibility issue, plus using a label brings up some nice features in the Web browers. For example, most browsers will bring focus to a form element if you click on its label. Labels can be written in a couple of ways, but here’s one recommendation:

<label for="something"> Something </label> <input type="text" id="something" name="something" />

An HTML form should not…

• Request information you have no intention of using or needing. Rob Huddleston pointed out, as a common example, that e-commerce sites don’t really need to ask the credit card type, as the number itself indicates the type.
• Use tables. Tables are pretty outdated by now and should be used sparingly, if at all (CSS should be used instead). Besides the aesthetic and standards issues with tables, they break up forms poorly and can interfere with the use of label tags.
• Contain reset buttons. This is one I learned ten years ago that’s really stuck with me. And yet, lots of forms still have reset buttons. The argument against reset buttons is that the user may inadvertently click it instead of submit, thereby destroying all of their efforts. And how often do users actually need to reset a form? Never? Almost never? More likely a user would either reload the page if they want to start from scratch (which I just don’t think they ever need to do) or go to another page if they decide not to submit the form. Really: best not to use reset buttons at all.

Rob Huddleston also recommended the books Don’t Make Me Think by Steve Krug and Designing with Web Standards by Jeffrey Zeldman. I haven’t read either yet myself, although both are on my wish lists. I think it’s safe to say that both are considered standard books on the subjects.

I’ll be posting more on HTML forms in this blog, and you may also want to check out my post on poka-yoke. When I get the chance, I’ll try to add some CSS suggestions for making forms look even nicer.

The thinking behind poka-yoke is that a thing–software, hardware, whatever–shapes the user’s behavior in order to prevent or limit mistakes. An example that Wikipedia gives is how the key in an automatic transmission car cannot be removed unless the car is in park: the car tries to prevent you from leaving it in an unsafe state.

As Hoekman said in his presentation, we should be designing Web sites and software using poka-yoke, but often the design and interface of our creations encourages users to make mistakes. Or practically forces them to. For example, if you want a date in a specific format, you could indicate the format required. But a better solution would be to use a pop-up calendar widget where the user selects a date, that then formats that date properly. Even better, program your system so it accepts a date in multiple different formats in case the user doesn’t use the calendar widget. This last notion is part of a general theory of providing alternatives to your users, not trying to lock them into using your site in one set way (again, this is coming from Hoekman).

For more information on this subject, you should check out Hoekman’s site and his books. I’ve not read them myself, but have added them to my ever-growing list of books that I intend to read someday. His first is Designing the Obvious: A Common Sense Approach to Web Application Design. His most recent is Designing the Moment: Web Interface Design Concepts in Action.

Once you’ve finalized all the functionality and appearance of a site (or thought you have, at least), you should…Confirm that all links work. You can use automated software that will spider through your site and report any dead links. Using one of these applications, and there are free ones available, is really simple and definitely worth your minimal effort.

Validate all HTML. Use an online HTML validation system to confirm that there are no syntactical problems on any page. This should include pages that are the result of form submissions, with and without errors, etc. Any page that a user may see in any state should be validated!

Test! Test! Test! You’ve already tested your site, right? Lots of times? Have your spouse or significant other or parent or roommate or whomever test it. Have someone less technically skilled than you test it. Retest it yourself, this time with the approach of “What happens if I do this?”, even if what you attempt is something you’d never think anyone would ever try.

Test in multiple browsers on multiple platforms. You don’t have to take all of these steps using multiple browsers on multiple platforms, but you should at least hit some of the key pages so you know that everything looks right. Also keep in mind that IE 6 behaves differently than IE 7 or Firefox 2 vs. Firefox 3. Just testing in the latest version of one browser is not sufficient. To simplify things, consider using a site like BrowserShots.org.

Try to hack your site. Make sure you’ve applied good security measures by doing very, very bad things and making sure nothing horrendous happens.

Have a good “Page Not Found” page. Although it’s best not to have dead links on your site, a truly professional site has a nice “Page Not Found” page that handles any missing pages. It should look like the rest of your site, provide a helpful message as to what happened (i.e., why they’re seeing that page), and provide navigation to the site’s actual pages.

Well, that’s the list I have at the top of my head. I’m sure you have other suggestions and I’d love to hear them!

An old way to do this is to just check for the presence of the submit variable. Say you define your form’s submit button like so:

<input type="submit" name="submit" value="Go!" />

When the form is submitted, then $_POST['submit'] will be set (assuming you use the POST method, of course). Unfortunately this approach will not work in two situations:

1. If the user submits the form by pressing Enter/Return in Internet Explorer, the $_POST['submit'] will not be set.
2. If you want to use an image for the submit button.

For that matter, you can’t accurately check for the presence of any other form element because the user may not properly fill out the form (something that your PHP script would need to validate).

One reliable solution, which I have been using in my code and books, is to create a hidden input, with any name and any value:

<input type="hidden" name="submitted" value="1" />

Then, when the form is submitted, $_POST['submitted'] will be set (assuming, again, that you used the POST method). Worst case scenario, if the user manipulated the form so that it didn’t contain this element, then submitted the form, that form wouldn’t be processed (which it’s best that it isn’t anyway).

Another option, which I’ll likely start using in my books (I’ll have to confirm that there’s no downside), is to check how the page was requested. As you probably know, there are two common methods for requesting a page: GET and POST. These are also the values used for the action attribute of a form. Most pages loaded in the Web browser–by typing in an address or clicking a link–are requested using GET. So the first time a page that both displays and handles a form is accessed (i.e., when the form is displayed), it’s a GET request. When that form is submitted, it’s a POST request (assuming the POST method is used, right? Right). So to check which state the page is in, refer to $_SERVER['REQUEST_METHOD']:

<?php if ($_SERVER['REQUEST_METHOD'] == 'POST') { // Handle the form... ?>

As I said, this sounds like a good solution to me but I still want to do a little research to confirm that it’s reliable (e.g., that all Web servers on all OSes populate this variable).