Interesting article. I've done several use case studies as well, and found that:

1.) The "farther" away from the Operating Systems actual buttons a "Web Form"s buttons are, the harder they are for the user to use. (e.g. fancy buttons look neat, but buy nothing)

2.) "Graying" a button, will most often be viewed as "disabling" a button, and is not advised (unless the intention is to visually show a disabled button)

3.) If using images to present buttons, ensure that the buttons have a hover state, and visually appear depressed when clicked

4.) Avoid using hyperlinks, in the same horizontal row as buttons (it appears to the user as a graphical glitch, which then causes confusion and lack of confidence in pressing any button/link)

5.) Negative actions (Reset, Cancel, Delete, etc.) should have a confirmation, before proceeding.

5b.) Cancel should only have a confirmation, if something on the form changed

5c.) Reset should really only be used on a search form, in 95% of the remaining cases, it is just an accident waiting to happen

6.) Positive actions to the left... Negative actions to the right (Ok/Cancel)

7.) Never mix button behavior. If "Apply" in the Operating System means "Apply my changes, and keep me on this screen", then your Apply button should do the same.

8.) Likely the most important rule of all time for web forms. If the form submission results in an error, return the user to a screen where they can correct the information however; REPOPULATE the information the user entered! (omitting the field(s) in error is acceptable, but the user should not have to re-enter any correct information)

If I was simply told about a book dedicated to the subject of Web Form Design I'd have rolled my eyes, thought "how dull", dismissed it as a waste of time and moved on.

In reality however I wasn't told about the book - I was pointed to this article - and I found it to be amazingly well written, thoroughly researched and extremely interesting.

Thanks! - I'll now be the first in line to buy a book I never would have thought I'd be interested in :-)

Ryan, Though we did not explicitly test "Back" it is still a secondary action. The goal of every form is completion so we should make sure "Continue", "submit", "Save", and any actions that help people achieve that goal are prioritized. Utilizing the scan line of a form is a great way to prioritize primary actions. So instead of using the notions of "forward" and "back" to dictate primary action placement, I rely on primary scan lines that illuminate clear paths to completion.

thanks~