Re: UI: "Direct manipulation" is in conflict with "Forgiveness"
Re: UI: "Direct manipulation" is in conflict with "Forgiveness"
- Subject: Re: UI: "Direct manipulation" is in conflict with "Forgiveness"
- From: Eric <email@hidden>
- Date: Thu, 19 Sep 2002 02:34:16 -0400
on 9/18/02 7:49 PM, Charles Srstka at email@hidden wrote:
>
Here's how I do it. I load the settings into my controls when I open
>
the prefs window, and I check the controls and write the prefs when the
>
user clicks the "OK" button. I don't actually write the changes until
>
the user clicks that button. If they click Cancel, it just closes the
>
window, and nothing is changed. In either case, there is no
>
confirmation dialog box (there doesn't need to be! That's what the OK
>
and Cancel buttons serve as).
>
>
Charles
>
>
On Wednesday, September 18, 2002, at 12:01 PM, Jay Prince wrote:
>
>
> Apple encourages the concept of direct manipualtion-- the user is able
>
> to control what they want, rather than have to use an intermediary to
>
> control it. It also encourages forgiveness-- if the user makes a
>
> mistake, they should be able to undo it.
<snip>
>
> Is one of these patterns better than the other?
>
>
>
> I could easily cache all the changes the user makes inside of my
>
> (rather complicated and extensive) preferneces panel. But that brings
>
> up the possibility if they say "Cancel" that I discard them all--
>
> should I then bring up an alert saying "Do your really want to discard
>
> the changes you made to X, Y, Z, Q, and J?" (with two buttons
>
> "Discard" and "Cancel"? Which would be weird because they would be
>
> Cancelling a Cancel button press.)
>
>
>
> Going down this path gave me the thought that I should have such an
>
> alert, but the concern that its getting clunky there.
<snip>
>
> Any thoughts on which has primacy? Forgiveness (and a possible
>
> confusing alert) or direct manipultion (and the possibility that a few
>
> minutes of work may be lost.) With direct manipulation, if their
>
> changes are in error, there's no way to go back to the configuration
>
> they may have set three months ago.
<snip>
>
> Jay
>
>
I think Charles' method makes sense here. The "Cancel" button does exactly
what it says, it cancels any pending changes to the application preferences.
There is no need to put up an alert confirming the user's decision. A lot of
apps implement their preferences panel in this fashion (Internet Explorer
comes to mind) and I can't recall a time when I regretted losing the changes
I made after clicking "Cancel." My intent was to cancel all the changes I
had made to the preferences no matter how complicated and extensive they
were.
On the other hand, direct manipulation has the advantage of giving the user
instant feedback without requiring him/her to confirm his/her changes by
clicking an "OK" button (Most of the panes in System Preferences work like
this). What I suggest you do if you decide to go the direct manipulation
route is that you implement undo and redo in your preferences panel.
Whenever the user makes a change in the preferences panel, push that change
onto the undo stack. That way, the user is allowed to restore his/her
3-month-old preferences configuration in case he/she decides that he/she
doesn't like the new configuration he/she has set.
When the user closes the preferences panel, the undo stack is cleared -- the
changes the user made cannot be undone at that point. You may put up an
alert warning the user that once he/she closes the preferences panel,
changes to the preferences cannot be undone. I think clearing the undo stack
makes sense here because each time the user opens the preferences panel,
he/she starts a session of modifying the application preferences; and when
he/she closes the preferences panel, he/she closes that session. Chances are
the user won't close the preferences panel until he/she is satisfied, for
the time being, with the preferences he/she has set. The next time the user
opens the preferences panel, the undo menu item is initially disabled
because you don't want to the user to undo into the previous session.
As an analogy, you wouldn't expect to be allowed to undo a change in a
document after closing the document and then reopening it. It does sound
like an interesting feature, but I wouldn't implement it in an application
without first doing some UE testing.
Anyway, hope this helps you out.
Eric Wang
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.