Re: Preferences UI operation theory
Re: Preferences UI operation theory
- Subject: Re: Preferences UI operation theory
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 05 Jan 2005 06:54:37 -0500
on 2005-01-05 1:38 AM, Scott Stevenson at email@hidden wrote:
> On Jan 4, 2005, at 10:01 PM, Mark Dawson wrote:
>
>> Are there any rules of thumb as to when a preference change happens
>> immediately and when it applies later (such as next open document)?
>> Somewhat of a reverse way of asking this: Is there any standard for
>> when to apply a preference to the active document vs to the next
>> opened document?
>
> Users expect preferences to take effect as soon as is logically
> possible.
Yes, in most cases. Except I would phrase it "as soon as appropriate or
convenient" to take account of the fact that there may be
application-specific reasons to defer effectiveness of some preference
changes. This has always seemed to me to be an area where considerable
design flexibility is necessary to take account of the many different things
that applications are designed to do.
I think it's reasonable to have some preferences that apply only to "new
documents," if that makes sense in light of the uses to which your
application is put, as long as they're clearly identified as such. If you
have a number of "new documents" preferences, it would probably be a good
idea to group them with an appropriate group heading indicating that they
apply to new documents. Contrariwise, MS Word has some Print and Save
preferences labeled as options "for current document only" and Compatibility
options "for Document1".
In other situations, it may not be possible (or easy) to write your
application to provide immediate effectiveness of preference changes. In my
app (PreFab UI Browser), for example, I allow the user to turn off help
tags, but I include a small-print note under that setting in the preferences
window indicating that "(re-enabling help tags requires relaunch)". I could
in fact make it take effect immediately, but only at the cost of
considerable additional code that, in my judgment, just wouldn't be worth
the effort for a preference like this.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden