[Sparkle] Proposed solution

[Martin Redington]

On 8/6/07, Andy Matuschak <andy at andymatuschak.org> wrote:
>  Alright guys, thanks for talking this out with me. I think I have the basic
> behaviors I'd like in mind now. Here's what I'm envisioning:
>
>
> User opens an app using Sparkle for the first time. It gives a brief
> explanation of what Sparkle is and asks if he wants to install it.
> If user agrees, the app's stub downloads and installs the package: a
> prefpane and a daemon with login item.

I would really like to see the original behaviour supported. If the
user chooses not to install the prefpane, I don't want update checking
disabled for my app.

Offering too many choices to the user at startup is confusing, and
some people may not want this behaviour, so maybe this could be
configured by the developer, to give the user the choice "install
sparkle prefpane or check for updates independently" (the language
obviously needs work).

If there's just a stub with the app, maybe the standalone version
could download a checker to ~/Library/AS

> If the user refuses, nothing happens; he'll have to find the Sparkle
> homepage later if he wants it.

> The daemon begins checking for updates. If one is found, a Sparkle icon
> appears in the dock and bounces (though perhaps not repeatedly like Software
> Update—argh!), badged with the number of updates available.

> The update window looks identical to Apple's Software Update window.

+1. Could be nicer maybe, but its a good model.

> Release
> notes are displayed. There are check boxes, but all are checked by default.
> Buttons: Install Updates (default); Always Install Updates; Remind Me Later

The always install needs a bigger warning sign.

"Always install all updates automatically" (horribly long for a
button. probably much much worse in German).

> Like in Apple's SU, you can skip an update by deleting it from the table
> view

I didn't even know you could do that.

>  but I'll also have a "Skip Version" button on the right side of each
> row. When clicked, that update will disappear, and subsequent updates for
> that app will be unchecked by default until the user updates it again. If an
> update to this application is the only available one, the update window
> won't be triggered.

I'm not sure this is necessary. buttons in tables generally look ugly too.

I think you can just rely on the user unchecking it, and still notify
them if a new version appears. Granted that will be mildly annoying
sometimes, but that is still how every other (mac) update mechanism
that I can think of behaves.

> Always Install Updates does the thing I want: just installs the damn updates
> when they appear. Maybe there'll be Growl notifications.

> If an application is open, it'll say "MyApp is running; update will install
> when it is quit."

I'm not sure what's better here. The iTunes model is "quit iTunes, or
I won't update".

Silent background updating may be dangerous (and actually this is
another argument against updating automatically, even though I totally
grant that the case for its utility is made).

If I start up an app right in the middle of an update, isn't it
possible that I'll load some objects (nibs, frameworks, whatever) from
the pre-update version, and some from the post-update version. That
could be very undesirable, although it would be rare.

I can think of various hacky fixes for this, but nothing especially elegant.

> The prefpane has two tabs: General, and Applications
> The General tab has:
> A big Check Now button with last check timestamp
> A check for updates check box next to a popup button with: Daily (default),
> Nightly, Weekly
> A check box for "install new updates automatically." (off by default, but
> checked by that Always Install Updates button)
> The Applications tab has a big table of all registered applications; columns
> include:
> Icon, name, author, current version.
> Update action, a popup button: [Ask Me (default), Always Install, Ignore].
> The last of this triggers similar behavior to the "Skip Version" button
> described above.
> When a new app is launched, it is registered with the Sparkle daemon unless
> it's launched from a read-only location. The Sparkle daemon keeps a
> CFURLAlias to the app, so it'll be good even if it moves.
>
> I think this design deals with everything as elegantly and unobtrusively as
> possible while still giving a lot of flexibility. Feedback?

I think you could easily add more functionality to the "applications"
tab. e.g. version history, release notes access etc.

>
> Things not yet figured out:
>
> Sparkle+. I want to merge that stuff in, but I'm not sure how it fits in the
> UI. Sparkle's already asking something of the user on that first
> prompt—installing a prefpane for this weird thing!—so I don't want to ask
> about sending anonymous info then too. I think instead that I'll ask the
> user if it's okay to send that data on first click of the "Install" button
> from the "hey there are updates" prompt.

I think a checkbox "Send machine info" or something, with a help button would
be fine here, and less cluttering.

> Old versions. Do we care? Seems like it could cause issues pretty readily,
> and it wouldn't be used much.

Probably not (but see below). If the developer supports that, let them
go to the site.

> Branches. This could probably wait until after an initial implementation is
> done, but I really would like to be able to support public/private betas
> while concurrently updating the main feed.

Do you need anything more here than an extra tag for the branch
somewhere (in the info.plist maybe).

I'd make the appcasts separate as well.

Each app is now uniquely identified by its signature, and its branch
tag (which can be empty). Sparkle just treats these as different
items.

This also allows me to update my 1.0 (pre-leopard) version and my 2.0
(post-leopard) version separately, while keeping the same signature.
I'd just give them tags, which although they correspond to different
"versions" in the real world, are just arbitrary tags as far as
Sparkle is concerned.

> Let's keep talking about posets.

I haven't looked into posets, but I think it may be better to keep it
much simpler than that ...


> Licenses. What do you think of the solution in my last email about those?
>
> - Andy Matuschak
> PS: Is anyone else amused that MS's software updater duplicates Apple's SU
> UI, but there's never more than one update at a time, so a table view is
> really silly?
> _______________________________________________
> Sparkle mailing list
> Sparkle at lists.andymatuschak.org
> http://lists.andymatuschak.org/listinfo.cgi/sparkle-andymatuschak.org
>
>