I’m not sure I entirely agree with all of these. Or at least I’d like to see more reasoning behind some of these ideas. For example:
Good forms can be reset with a <button type=reset>
In my experience, this is at best a useless feature, and at worst an active hazard - one misclick from someone who had laboriously spent the last fifteen minutes filling a form out, and now all their work is gone.
Or this one:
Good forms should do a pre-flight check for navigator.onLine before attempting a submit
The browser will handle this just fine, and if you’ve done everything right, it’ll handle making sure that information isn’t lost on a restart. On a shaky connection, I’d rather try optimistically and be confident in the ability to retry, rather than having to deal with the page deciding what I’m allowed to do. A better piece of advice here would be to make forms as idempotent as possible, in particular ensuring that resubmitting the same form redirects the user to the same result.
Or, and this is a real pet peeve of mine:
Good forms see custom controls as a radioactive asset that must be removed at the earliest opportunity
Poorly implemented custom controls are bad. Well-implemented custom controls with sensible fallbacks can make the user’s life so much easier. My favourite example of this is the date range selector, which you see on a lot of hotel or flight booking forms. This allows you to clearly select a range of dates, often allows for custom information inside the date picker (like prices), and reduces the number of clicks you need to make back and forth. It is almost always the better option over a native control (especially given that the native control would have to be two inputs here).
There’s also some stuff I’d have liked to have seen here that the gov.uk team have done really well, namely choosing the appropriate form inputs that support the user but don’t restrict them. For example, the address input for most gov.uk forms is a set of four or five text boxes in a row, which the user can fill out in a way that works for them. This makes weird addresses (and in particular foreign addresses) really easy to submit, because you don’t need to work around assumptions that every address has certain attributes. Similarly, they generally use date fields that are also just text boxes, particularly for things like date-of-birth where a date picker is usually going to be a pain to navigate (particularly for older people who have to go further into the past).
That said, a lot of these are good to keep in mind, and online forms would be a lot better if developers kept these rules in mind more often.
I’m not sure I entirely agree with all of these. Or at least I’d like to see more reasoning behind some of these ideas. For example:
In my experience, this is at best a useless feature, and at worst an active hazard - one misclick from someone who had laboriously spent the last fifteen minutes filling a form out, and now all their work is gone.
Or this one:
The browser will handle this just fine, and if you’ve done everything right, it’ll handle making sure that information isn’t lost on a restart. On a shaky connection, I’d rather try optimistically and be confident in the ability to retry, rather than having to deal with the page deciding what I’m allowed to do. A better piece of advice here would be to make forms as idempotent as possible, in particular ensuring that resubmitting the same form redirects the user to the same result.
Or, and this is a real pet peeve of mine:
Poorly implemented custom controls are bad. Well-implemented custom controls with sensible fallbacks can make the user’s life so much easier. My favourite example of this is the date range selector, which you see on a lot of hotel or flight booking forms. This allows you to clearly select a range of dates, often allows for custom information inside the date picker (like prices), and reduces the number of clicks you need to make back and forth. It is almost always the better option over a native control (especially given that the native control would have to be two inputs here).
There’s also some stuff I’d have liked to have seen here that the gov.uk team have done really well, namely choosing the appropriate form inputs that support the user but don’t restrict them. For example, the address input for most gov.uk forms is a set of four or five text boxes in a row, which the user can fill out in a way that works for them. This makes weird addresses (and in particular foreign addresses) really easy to submit, because you don’t need to work around assumptions that every address has certain attributes. Similarly, they generally use date fields that are also just text boxes, particularly for things like date-of-birth where a date picker is usually going to be a pain to navigate (particularly for older people who have to go further into the past).
That said, a lot of these are good to keep in mind, and online forms would be a lot better if developers kept these rules in mind more often.