Forms Suck - Re: 10 Tips To A Better Form

Tue, 25 Oct 2005 form markup rails comments

At my company, we are working on several large web apps for the health industry. While I would love to follow the recommendations in Forms vs. Applications by Jakob Nielson and redesign the forms, retraining the health professionals is not an option. Sometimes there are legal reasons the forms must not be altered in their transition to the web. Thus we are stuck with trying to make usable webpages that are thousands of pixels long.

That brings us to Particletree's latest article on 10 tips to a better form.

After you are done reading it, come back for my comments. I'll wait. Go ahead.

Ok, here we are:

Remember Your Markup

Particletree does a good job remind us to use proper markup. The only comment I have is that unfortunately there are problems with implicit association of label elements in IE. So
```
<label>Email: <input type="text" id="email"></label>
```
must be the explicit (and uglier)
```
<label for="email">Email: </label>
<input type="text" id="email">
```
if you care about IE users.

The other recommendations are good. Proper use of Accesskey and Tabindex can really help both power users and users with accessibility issues.
CSS

CSS can definitely improve your forms. For larger forms (*cough* medical forms *cough*) we find that using techniques such as CSS-Only, Table-less Forms to be impractical. Our requirement that the online forms look like the paper ones they have been using for years prevents anything but a table from being practical.

One thing we have been doing is using rails helpers to build the forms. We have created our own set of (helper) tags for marking up a form, which produce table code. This allows both the markup to be clearer, and more importantly allows us to have the same markup generate mobile views by changing what the helpers output if accessed from a mobile device. This also allows for faster adoption of future technologies as they become deployed; upgrading to xforms is a matter of rewriting a handful of helpers, not modifying hundreds of views.
AutoTab

My first reaction to AutoTab is that I hate it. I don't want the application to move focus. Correcting typos requires you to return focus on the previous element, AutoTabing is not consistent as it only works on elements which have fixed length (there are ways around this with custom javascript, but it will only work on data sets where you can determine the input is finished.)

AutoTab reduces usability since it cannot be used consistently, thus will never be in my apps unless a hard requirement by the end user.
Field Information

Having information appear related to the current field is a good idea. It allows detailed information about the users current context without overloading them with information related to all contexts.

While you are at it, why not have your (custom rails) input helpers add javascript to perform client side validation. We've been kicking around the idea of having our helpers pull validation information from the model and add it to the form when it makes sense (just an idea right now, we haven't even done a mockup yet.)
Error Displays

Rails out of the box has great error displays. The scaffolding provides decent error displaying; the rails input helpers add an error class to elements that have errors; the models allow error messages to be written in plain English. Make sure you know how rails does these and use those techniques in your apps for great error displays with minimal effort.
Postbacks

There is nothing worse than filling out a form, encountering an error, and having to retype all of your information all over again.

Agreed! To do postbacks in rails, you form tag in your view should look like
```
<form method="post">
```
Then in your controller, use request.post? to determine if the user is submitting the form or asking for the form. At its simplest:
```
def info_new
  @info = Info.new params['info']
  if request.post?
    if @info.save
      redirect_to :action=>:list
    end
  end
end
```
If there was an error with saving due to validation, their previous input will pre-populate the form. Plus you get the nice error messages and highlighting previously mentioned.
onFocus

Using javascript to provide onHover styling is another good suggestion. Remember that elements might have multiple classes (one that says how it should normally look, one that adds that it had an error in it) as using
```
element.className = 'focusHover';
```
overwrites all classes. You don't need an extra span tag for all types of highlighting (for instance changing the background.) If you don't need them, don't use them as it adds up when you have forms with hundreds of fields.
Label Click

Particletree reminds us we can work around issues like the label click issue of IE with a little javascript. I'm not sure if this fixes implicit associations, but if not, fixing it is a better idea than adding an explicit for attribute.
Double Submit

My view on this is that the server side should do whatever it can to combat this issue. Using javascript to disable to submit button can lead to headaches, as well as doesn't fix the issue of the user going back to the form and clicking the button again.

Another way to combat this issue is to take the user to a new page that tells the user their request is being processed, then use meta refresh or some ajax-fu to move them forward when the event is processed.

If you are worried about rapid double-clicks, you can fix that in javascript using an onsubmit helper that records when the button was clicked and only forward to the real submit if it has been more than 2 seconds since the last submit.
Leftovers

Using widgets to enhance usabilty is a great idea. We have been using Dojo (use current SVN as there are issues with 0.1 use with prototype). The date picker (created and put to good use by Renkoo), Tabs, and Editor. Dojo is great because it provides a clean way to develop DHTML widgets.

Unfortunately the curve to start using it is higher than prototype/scriptaculous, so many railers have yet to play with it. Luckily I got a tutorial from Dylan and Alex at the last SHDH (speaking of which I'll be at SHDH5 on Nov 5, will you?)

Particletree did a great job summarizing how to make forms a little better. Too bad they (forms) still suck. The web is a different medium and moving complicated paper forms to web has yet to be sanely demonstrated without changing everything.

Now back to work on those apps.