[Sparkle] Sparkle Prefpane Interface
Andy Matuschak
andy at andymatuschak.org
Sun Aug 5 15:40:46 PDT 2007
> It seems to me that the best way to implement the interface would be
> to just have a faceless background app that's launched when the
> prefpane loads (and have it automatically add itself as a login
> item). [...] From then on, it would work pretty much like Sparkle
> does for
> individual applications.
Yep.
> From then on, it would work pretty much like Sparkle does for
> individual applications. If the background app finds an update, it
> will pop up a window listing all of the available updates to Sparkle-
> aware apps, with buttons to install all updates or checkboxes to
> allow installation of only some specific updates. There'll also be
> skip/postpone buttons in the dialog -- to keep it simple, these
> buttons would apply to all the updates that are presented in that one
> dialog; the checkboxes would only apply to installation.
I don't think it has to be nearly that complicated. If there are
updates, install the updates. Maybe there can be an option for that,
yeah. But really, let's think about it. What are the situations in
which a user would not want an update installed? Some new version with
a restricted license agreement? Maybe he wants to keep an old version
installed because he knows new versions suck. Really, the user
wouldn't be able to figure out either of those things from a dialog
with release notes. If he cares enough to stop an app updating (and I
doubt even 1% of users ever will), he can go to the prefpane and tell
it so.
I know it feels a little draconian to be dictating to users "hey we're
going to go ahead and update now," but isn't that the Mac way? Do The
Right Thing for 99% of users, and push aside the rest to improve the
experience for the majority?
This has the advantage of not bothering the user with options for
which the default's almost always right (think branch prediction!),
but the disadvantage is that now the user doesn't know when things are
updated and doesn't get shown release notes. I want to think about
that more.
> Since it's the background app doing the updates, not any individual
> application, this dialog box wouldn't necessarily come up when
> Sparkle-aware apps are launched. (Although, I suppose, it might be
> advantageous to have certain apps trigger the background app to do an
> immediate update check; I could see the prefpane showing a list of
> all Sparkle-aware apps living on the system, and a flag which could
> tell Sparkle that it's an important app -- meaning that the user
> wants the app to trigger an update for that specific app when
> launched.)
I mean, if it's checking once a day, I can't imagine that not being
good enough for a user. I don't really want to complicate the UI with
any extra options if I can help it.
> Growl notifications should not be an integral part of Sparkle.
> Sparkle can use Growl if the user has already installed it, but I
> don't think it should be absolutely necessary.
If I did notification-like things for updates being installed, I
definitely wouldn't want to require the user to have Growl. I might
implement my own more Delicious kind of notifications. Something
swoosh-y and shiny.
- Andy Matuschak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andymatuschak.org/private.cgi/sparkle-andymatuschak.org/attachments/20070805/dc6eb595/attachment.htm
More information about the Sparkle
mailing list