I'm making a form (for a CMS), where the text fields initially show previously saved content that the user may edit and resave. Should I offer some kind of Reset or Undo functionality to this?

A Reset button restores the text fields before the form is submitted, while an Undo button restores them after submitting. Offering both a Reset and Undo button sounds more confusing than helpful.

Or should I instruct the user to reload the form page instead of using Reset (or use Ctrl+Z or similar for individual text fields), and use the browser's Back button instead of Undo? Does this work reliably in various browsers?

Jakob Nielsen discusses Reset buttons here: http://www.useit.com/alertbox/20000416.html but that's mostly about forms that are initially empty.

What Jakob says. Undo is very useful. "Reset" is just a pain in the bum. (This forum software is a classic: always have at least two buttons, of which at least one has a confusing name -- "Close fast reply" is impenetrably dense -- and always make sure that in similar but slightly different situations ("fast" reply and "not-fast" reply) the button everyone needs is in a different position).

Not quite sure I understand your question, particularly if this is javascript...

Not javascript. I use two submit buttons, one with say name="undo" and one with name="save", and let PHP isset() sort them out.

The problem is that the user may regret edits either before or after saving the form. After saving it seems simple enough to use an Undo button. But if the user feels regrets before saving, two things might happen depending on how I write my PHP:

* Either I disable the Undo button when the user loads the form page "from somewhere else", and only enable the Undo after the user has saved the form (the form submits to the same URL). But if the user regrets his edits before saving, how will he know that he must first save his incorrect edits before being able to redo them (not to mention how counter-intuitive this sounds)?

* Or I make the Undo button functional even when the user loads the form page from somewhere else. But then if the user clicks Undo before saving he will not restore the initial content, but whatever was saved during some previous edit.

If the last part sounds confusing, here's an example. First the user changes the text "foo" to "bar" in a form field, and saves. The "database text file" and the new form field now contains "bar", while the "undo file" contains "foo". A week later the user changes "bar" to "baz" in the form, but before saving realizes this was a mistake. Now suppose the user doesn't remember what the form field just contained (i.e. "bar")? He can't click the Undo button now (before saving) since it will restore the old "foo", not the recent "bar".

Sounds like you need a database called history which has the same fields as your current database, plus say a time stamp and a userid.

When the data is changed update the current db and add the entry to the history db, and if you want to go back to a previous entry, display the history db and then select the entry you want have on your current db.

That sounds like my current Undo, that part is no problem. But what to do if the user regrets his latest typing before he has saved it?

Maybe I could let PHP print an Undo button (really an extra submit button, see above), and then use javascript onchange to remake it into a Reset button as soon as the user starts typing (so he can no longer Undo the latest save, only reset his typing after that save).

This may sound a bit simple, wouldn't the user move the cursor to the spot and then make a change?

I am guessing that you want to make the data entry user proof.

I think this is a terrible idea. The way to make something reliable is for it to be transparent, and a button that does one thing when you look at it, and a different thing when you click it moments later is just asking for confusion.

Look, if the user isn't capable of editing a form, there is no hope for them. I'm filling in a form now, and I find I have an Undo button (it's ctrl-Z) and a back-out-and-start-again button (the browser Back button). Any atempt by you to fake this stuff will be more nuisance than it's worth. (What will happen if I press ctrl-Z?)

As Geoff says, if you want to provide a "Go back to previous version" button, you _must_ show the previous version that is going to be gone back to. And mark it explicitly with something clearer than "Undo".

(Actually looking at your suggestion more carefully it seems even crazier. When I type stuff in a (properly-behaved) form, I know I am only typing on my computer, and not (yet) affecting the system I'm interacting with. But you would disable the "Go back" option the instant I start typing?? So I type something, then think oops, and press ctrl-Z. The form is now back to where it started -- is your javascript going to detect this, and reinstate the "Go back" button????)

I think that if you follow the "philosophy" on which html forms are based, not only does this generally improve usability, but it also saves a huge amount of work.

HTH

True, but if there's lots of content and the user made lots of changes he may have trouble remembering what the initial content looked like. If the user knows about how to use Ctrl+Z (Cmd+Z on Mac OS?) this shouldn't be a problem, though (but I see now that Ctrl+Z only works for a single form field in Firefox and Opera).


Didn't understand that.

I use a CMS which allows saving versions. I don't enable that for my users, because I fear it would just confuse them. Likewise, I think an "undo" button in a form would need lots of explaining. My users seem to have no problem editing what they entered in a previous session. And they seem to understand that closing their window will abandon their edits.

If you want to provide extra functionality for your users, maybe you can have two buttons: "Save" and "Revert to Last Saved." Users may understand what they mean from prior experience with desktop applications.

"Revert to Last Saved" was a good phrasing!

[quote]I am guessing that you want to make the data entry user proof.[/quote]
Didn't understand that.
[/quote]


Basically saying you want to make it idiot proof....

Yes, it's a bad habit I have. Especially if the feature just confuses the users, idiots and non-idiots alike.

The wiki software that I'm familiar with uses the term "rollback" for content that has already been submitted, but you want to go back to a previous version. The term "cancel" is used when you throw away something you're editing, but haven't submitted. Some systems provide an explicit "cancel" link, but others just let you close the window, or follow a link/bookmark to some other URL.