Re: gnome-stock pixmaps - Apply/Revert/Close

[Bruce Dodson <brucedodson rocketmail com>]

My beef with the "top" part of the scheme is that the
rules are too complex.  I am convinced that, although
the developers might appeciate this fine-grained
Undo, Joe User will not.  Furthermore, the developers
will think twice about return on investment when the
time comes to implement it.

In your scheme, Apply does not mean "Apply"; it means
"Group and Apply".  Changes do not become active
until they are applied, and thereafter they are
treated as a single change.

So what happens when you have unapplied changes and
you hit Undo?  Does it undo them one at a time, or
revert to the previous checkpoint?  

In the former case, the user will be confused,
because he is undoing something that has not yet been
done.  This is too abstract, and to make it concrete,
many users will believe that changes take effect
automatically.  Thus they will sometimes forget to
hit Apply before Close.  

In the latter case (Undo reverts to previous
checkpoint), the Grouping is meaningless from a
user's eye view, and the Applying is still less
meaningful than it should be, for the reasons
discussed above.


Really, Undo is not even very necessary here.  These
modeless dialogs mostly for state toggles, and other
easily-manually-undoable changes.  In such a case, an
Undo button is just a gizmo.  Give me one good
example of where this button can be useful, and I'll
give you three where it can be misused or cause
problems.
  
Furthermore, Undo will be hard to implement.  It
requires the dialog to have too much knowledge about
the its contained widgets, and other parts of the
application.  (e.g. If you apply a change, say to a
font, then do some typing, then undo the font change,
does the document have to undo the font change too? 
If not, the action hasn't really been undone.)

Undo is confusing because it undoes changes to an
abstract thing: the application state.  Joe User
doen't have an application's eye view; he expects
Undo to undo changes to his document.



Well, I could go on (and I have) but let me just jump
to an alternative that I think is more reasonable:


Apply  - Applies changes, modifies application
         state to match dialog state

Revert - Discards unapplied changes, resects
         dialog to reflect application state

Close  - Well, whatever the Close Button discussion
         resolves.  It looks like it just closes,
         keeping the application state as it
         currently is.


Notice that there is no grouping, no multiple-level
undo, and no confusion.  Furthermore, it's much
easier to implement: Revert just initializes the
dialog to reflect the application's current state. 
Further Reverts have no effect, or perhaps Revert
would be disabled initially, and immediately after an
Apply or Revert.



---Ben 'The Con Man' Kahn <xkahn@cybersites.com> wrote:
>
> Re: Close being close and apply.  
> 
> 	When you have a dialog box with just a close
> button, it usually means that you are using an
immediate dialog box.  All
> changes you make in this window will be carried out
at once.  The close
> simply closes the window.  This is a very intuitive
interface, but only
> works for small, atomic selections.  (And for
selections which do not have
> major ramifications.)



In Ben's case (which is extremely common and
extremely valid), Apply and Revert would not be
present.  It can be understood that, if there's no
Apply, changes are auto-applied.  In such a case
Revert could never to anything, because the
application state and the dialog state are always the
same.  This is reasonable and intuitive, because it
means that the dialog works like a toolbar.  Even the
Close button is unnecessary if we assume the window
manager provides a way to close the dialog.



Regards,
Bruce Dodson
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com