UI meditations: forms with multiple buttons, when to validate

Posted by Amos Robinson on February 3rd, 2008 filed in , , ,

I’ve been thinking a little bit about the best way to implement a form like this:

Wendy hears that Amos is taken to hospital - start date is thrown out, and Amos is swapped out for another resource

  1. Wendy changes start date to 2008/02/05
  2. Wendy presses “Delete” for Amos resource
  3. Amos resource is removed
  4. Wendy presses “Add resource”
  5. Asks Wendy: which resource?
  6. Wendy selects resource “Derek”
  7. Resource added
  8. Wendy selects “Save”
  9. Project is saved

For a strict, valid and usable XHTML implementation (Ajax is not an option; I’ll be blind in forty years and will still be using this), the submit button to add a resource should be redirected to a separate page: the only other options are to ask which resource in the current form — in which case default submit buttons would be screwed — or have a separate form in the same page, which would cause Wendy to lose some of her changes if she had changed the start date after deleting the resource.

As above, but Wendy enters invalid date

  1. Wendy changes start date to 2008/55/55
  2. Wendy presses “Delete” for Amos resource
  3. Amos resource is removed
  4. Wendy presses “Add resource”
  5. Asks Wendy: which resource?
  6. Wendy selects resource “Derek”
  7. Resource added
  8. Wendy selects “Save”
  9. Errors shown: start date is not valid
  10. Wendy changes start date to 2008/02/05
  11. Wendy selects “Save”
  12. Project is saved

Is this any good? Or would it be better if the validation error was thrown on the very first form submit - when the resource was being deleted? I don’t think it would be. You’re forcing your user into an arbitrary workflow, and there are bound to be legitimate cases that simply won’t work because of that. One example would be if Wendy didn’t know the start date right now, but blanked it out immediately so she knew that it needed to be specified. She could ask her manager for the date, and be adding the forty new resources (ten bats each corner) while waiting for her manager to get back to her. A nice possibility, I think, would be to have the Delete action and some client-side JavaScript put a warning on the invalid date field, and the Save action would still hard-error.

As first, except it’s 16:59 and Wendy has to leave at 17:00

  1. Wendy changes start date to 2008/02/05
  2. Wendy presses “Delete” for Amos resource
  3. Amos resource is removed
  4. Wendy presses “Add resource”
  5. Asks Wendy: which resource?
  6. The clock hits 17:00
  7. Wendy selects “Cancel”
  8. No resource is added. Wendy is taken back to the edit project screen
  9. Wendy selects “Cancel”
  10. No changes that Wendy made were saved. Amos resource still exists, date is still 2008/02/02.

I don’t think this one needs any argument. Transactionality is awesome.

Summary and result

  • Don’t rely on JavaScript: you’ll be blind one day, and will have rendered yourself unable to enjoy the fruits of your labour. Of course though, a good accessible form should be able to have JavaScript tacked on relatively well
  • Default buttons on forms are good: pressing enter on an input should produce a meaningful result (e.g. save)
  • Don’t require users to input entirely valid data until necessary. If it can’t possibly hurt any real data integrity, let it slide for now
  • Transactions are awesome.


(I had a tiny bit of trouble with Inkscape’s SVG output, and realised it was because I was using flowed text, which is new in the SVG specification. See Inkscape FAQ: What about flowed text? if you ever come across this.)

Leave a Comment