Re: [Usability] inability to experiment

["Matthew Nuzum" <newz bearfruit org>]

On Tue, May 27, 2008 at 7:31 AM, Calum Benson <Calum Benson sun com> wrote:
> See, this is where the argument went round in circles last time :)  Some
> others on the usability team at the time also suggested this approach, but
> personally I don't think Undo is necessarily appropriate for dialogs-- it's
> rare to make more than one or two changes in a dialog at a time, in which
> case it's usually just overkill.  And when you do make multiple changes,
> they're often quite independent of each other, so you don't necessarily want
> to have to undo your last N changes to undo the first one you made.
>  (Although, sometimes, you might.)

Tell me what you think of the following description of the proposed
change. Also, how does a person go about making a change to the HIG?

I propose a change to the interface guidelines that _suggest_ a
"revert" or "undo" button be added to dialogues that affect user
changes instantly (which is the common way now).

If a "revert" button is used then all of the changes in the dialogue
should be undone back to their state prior to the dialogue being
opened (aka fully atomic), or in the case of a dialogue that provides
some kind of user confirmation when making an irrevocable change then
the revert button will undo all changes since that confirmation. The
revert button will be disabled if no changes can be reverted (i.e. the
dialogue was just opened or the user just confirmed they wanted to
make an irrevocable change).

If an "undo" button is used then incremental changes can be undone in
steps so that each click of the button undoes one logical step. By
logical I mean that a series of user action that may be construed as
one action can be undone together. For example, if a dialogue asks for
textual input, typing the letters "matt" is one step, not four.
Clicking undo will _not_ remove each letter that was typed in turn,
but will instead undo all of the text input for one field leaving the
input field the way it was before the first letter was typed. The
number of steps that can be undone is application dependent but it is
suggested that the user be able to go back to the state the dialogue
was in when the dialogue was opened or the last irrevocable change was
performed. If the user cannot undo any more steps the "undo" button
should be disabled.

The choice to use "revert" or "undo" is up to the application
developer but for application dialogues that perform a single specific
task it is suggested to use "revert." For dialogues that help a user
perform a process or series of steps then it is suggested to use
"undo." But the best idea is for developers to look at the use-case
for the application and decide what would work best for users and if
in doubt favour revert since it is the simplest for the users.

In either case, the "revert" or "undo" button on dialogues should
appear at the bottom right of the dialogue to the left of the "Close"
button [1]. The "revert" or "undo" should _not_ be the default
selected button. If an application developer deems it useful to
include "undo" and "revert" both then "revert" should be at the bottom
of the dialogue to the left of the close button and the "undo" button
should be in the toolbar or drop down menu.

The above is suggested for dialogues, not required, however some undo
mechanism is strongly recommended. For example, Inkscape has numerous
dialogues. It does not make sense to put a "revert" button on all of
them since the application's undo facility provides redundant
functionality. So the dialogue for editing a gradient would probably
not need any change. However the "inkscape preferences" dialogue would
be a good candidate to receive either an undo or revert button since
the document's undo button does not have an effect on the changes made
through this dialogue.

[1] Example button placement: http://code.bearfruit.org/~matt/tmp/Dialogue.png

-- 
Matthew Nuzum
newz2000 on freenode