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: Bill Cheeseman <email@hidden>
- Date: Thu, 19 Sep 2002 08:45:45 -0400
on 02-09-19 12:43 AM, Jay Prince at email@hidden wrote:
>
On Wednesday, September 18, 2002, at 04:49 pm, Charles Srstka 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).
>
>
That's the method I was thinking about, but I didn't want someone to
>
accidentally hit cancel after doing a lot of configuration and loose
>
ALL their changes. The reason is that some of what occurs during a
>
preferences session is the creation of new data that can be a time
>
consuming process.
>
>
I think the solution is to save *That* data (it isn't really a
>
preference until its assigned to a configuration) and loose any other
>
changes if they press cancel.
This is not correct UI for application preference dialogs, as I recall the
latest Aqua Human Interface Guidelines. Preference settings are supposed to
take effect immediately (i.e., when you click a checkbox or radio button or
make any other change).
It is still permissible, according to the Guidelines, to hold the changes
until the user dismisses the dialog, but in that case you're supposed to
include a button named "Apply" so the user will have a clue that new
settings are at risk of being lost otherwise. If you don't have an Apply
button, the "OK" button is ambiguous by itself (or even with "Cancel")
because of the Mac OS X user's officially-sanctioned expectation that
changing a setting or two had already applied them. There are more details
in the Guidelines about the naming of buttons under either model.
I don't write the guidelines, I just read them....
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
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.