[Sparkle] Thinking about unifying Sparkle...

[Martin Redington]

More comments on 1) and 2) below ...

On 8/5/07, Andy Matuschak <andy at andymatuschak.org> wrote:
>
> 1. What kind of interface is appropriate for notifying the user of updates?
> A lot of the time, they don't care at all that something's been updated—a
> tiny bug fix, a small new feature, whatever. I don't want to be intrusive.
> Here are the options as I see them:
>
>  a. Don't do anything to notify the user.
>  b. Just basic notifications, like Growl, in the upper-right when an
> update's installed. If you click a bubble, you see the release notes. This
> is hardly elegant. Maybe something a little more... Delicious?
>  c. When you start the app, it says "Hey, this is a new version! Wanna see
> what's new?" and offers to show release notes. This is just as obtrusive as
> the current system, really. So probably not.

a or b as user options in the prefpane, or ... make it work like
software update.

version history and release notes should be accessible from the
prefpane, if you have one.

the user needs to be able to configure updating on a per app basis (or
manually choose which updates to accept, a la SU)  so if they have an
old version that they need, they don't have to worry about it being
overwritten.

> 2. How does the prefpane get installed? Sparkle is so effective and
> ubiquitous now because users don't really have a choice: the app comes with
> Sparkle, and by golly, it's going to keep things up to date! If I switched
> to Growl's distribution method, I don't think nearly as many updates would
> actually get executed. Ideas:
>
>  a. When an app that supports Sparkle is opened for the first time, it
> introduces Sparkle and offers to install it. This is rather obtrusive and
> inelegant, though it only occurs a maximum of once for the whole system.
> Also, if a user says "no", he doesn't really have a way to install it later.
> That's an issue.
>  b. Option (a) but do it when the app quits for the first time. Then it's
> not so much in the way of actually doing things but it still generates the
> "argh no I said go away why are you doing things" anger response.
>  c. Just install it. It's not like it's going to kill the user. The problem
> with this is that they may wonder how it got there or why notifications of
> app updates are appearing. Furthermore, they'll have no idea the prefpane
> exists.
>  d. Option (c) with some kind of explanatory dialog on first open / quit.

a, with a Growl type distribution as well.

for sure not c or d (can you say Smart Crash Reports). b sounds poor too.

> The other problem with this is that even though Sparkle is system-wide under
> this mechanism, every app's still got to ship with and contain a copy of it
> for it to install itself. Kinda lame.

Just ship a stub in the app. Download the current binary at install
time. Make the stub an actual app, so that it can run separately from
the main app, so the user can get on with that, while sparkle d/ls and
installs in the background.


>
> I could really use feedback on this, guys. Let's get creative! Especially on
> problem #1. I'm probably going to end up rewriting pretty much everything in
> the process of making it system-wide; I'll separate all the components so
> it'll be easier to support plugins / prefpanes / whatever, too. I'll try to
> do binary updates, and I'll merge in Sparkle+ stuff. It'll be great. If
> Caltech ever gives me a chance to breathe.
>
> Wheezingly yours,
> Andy Matuschak
>
> PS: Great coats, sparkle.andymatuschak.org couldn't be uglier. Ideas?
> _______________________________________________
> Sparkle mailing list
> Sparkle at lists.andymatuschak.org
> http://lists.andymatuschak.org/listinfo.cgi/sparkle-andymatuschak.org
>
>