• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: UI: "Direct manipulation" is in conflict with "Forgiveness"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UI: "Direct manipulation" is in conflict with "Forgiveness"


  • Subject: Re: UI: "Direct manipulation" is in conflict with "Forgiveness"
  • From: Charles Srstka <email@hidden>
  • Date: Wed, 18 Sep 2002 18:49:13 -0500

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.

In the HIGs, Direct Manipulation is expressed using the drag and drop metaphor. But to me, I've always thought about it as when you're changing settings, you're directly manipulating them. (EG Preferences.)

Some applications work this way and the preference pane just has a close button. You make changes and they are automatically saved, there is no undo.

Other applications have "save" and "cancel" buttons in their dialog boxes.

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.

The changes they make can be undone-- its not a "loss of data" situation, except that they'd have to re-set them. Some of the settings are involved-- they require making two or three decisions to set the setting.

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.

I don't think this is a very big issue, as the preferences are relatively easy to figure out.... but I wonder what the appropriate policy is in general.

Jay
_______________________________________________
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.
_______________________________________________
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.

  • Follow-Ups:
    • Re: UI: "Direct manipulation" is in conflict with "Forgiveness"
      • From: Jay Prince <email@hidden>
    • Re: UI: "Direct manipulation" is in conflict with "Forgiveness"
      • From: Eric <email@hidden>
  • Prev by Date: Re: How to take a screen shot
  • Next by Date: Re: NSButton Colour?
  • Previous by thread: Re: Cocoa-style HTML documentation
  • Next by thread: Re: UI: "Direct manipulation" is in conflict with "Forgiveness"
  • Index(es):
    • Date
    • Thread