I'd agree with that. Would the current sparkle+ dialogue be good enough for that?
Chris On Thu, Jul 28, 2011 at 6:06 PM, Colin Barrett <co...@springsandstruts.com>wrote: > Any feature that phones home should have a user-visible off switch. Period. > Anything else is disrespectful of the privacy of our users. > > -Colin > > > On Jul 28, 2011, at 4:01 PM, Jordan wrote: > > Are there plans for any sort of fall-back or more 'advanced' toggling for > these preferences? In other words, some of the items that can be removed > from the UI could still be optional toggles that are configured purely with > hidden prefs. I'll use the Sparkle Update option as an example: > > remove "Automatically check for updates", in my opinion users should always > get informed about new versions (pks) > > - *I'm unsure. Pretty much every app I know that uses Sparkle has this > setting... -Robbie* > - *I feel the same as Robbie, although I must agree - I can't think of > a situation where anyone would actually disable this? (paulwilde)* > - *What about adding a checkbox "Do not remind me again" to the > update-information-window? (pks)* > - *Disagree. We always need an opt out for auto updating because it > involves phoning home. Also, IT people want to do manual updates of > software. It must stay. -Colin* > - *Disagree. Opting out of options that phone home is important. -Steve > * > > The suggested solution (by pks) to use a "Do not prompt me for updates" > option in the update window does provide an opt-out to prevent the > application from phoning home. Colin brought up the point that IT personnel > would always toggle this off, so removing it would annoy those folks. Why > not also have a hidden pref for this. Hidden prefs are exactly the kind of > thing IT personnel are accustomed to making use of. They're likely scripting > their installs anyway, so using a command-line toggled hidden preference is > perfect. > > We have transitioned certain options to hidden preferences in the past and > I don't recall there being any major problems resulting from it. I think > some people suggested at the time that continuing to use a hidden preference > still provides complexity to troubleshooting that wouldn't be there if the > preference were removed altogether. This is true in theory, but I don't > think we have run into that problem in practice all that often (I can't > think of a single occurrence from when I was more actively involved). > > While I think that where possible a complete removal of any given > preference would be great, there will always be cases where someone comes up > with a good reason not to remove it; this can be seen at this very time by > skimming through the comments on the PreferenceReduction2011 page. Hidden > preferences may provide exactly the happy-medium required to allow for UI > simplification while still appeasing power users. > > Cheers, > > Jordan > > ---- > Sent with Sparrow <http://www.sparrowmailapp.com/> > > On Thursday, 28 July, 2011 at 2:27 PM, Colin Barrett wrote: > > I've updated it with my feedback. Would be great to get input from more > people. > > http://trac.adium.im/wiki/PreferenceReduction2011 > > -Colin > > > >
