On Tue, May 27, 2008 at 7:31 AM, Calum Benson <[EMAIL PROTECTED]> 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 _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
