A better Software Update mechanism
I’m using Sparkle to update Find It! Keep It!. It’s a state of the art desktop application update solution. It would however like to see some improvements.
What I don’t like about the current solution
Don’t interrupt me!
Sparkle asks whether you want to update the app when you start it. When someone opens his mouth, it’s not a good time to ask him something: he’s about to say something. Starting an app is the same.
Sparkle can also ask you whether you want to update the app when it’s running. That’s just plain rude: it could be interrupting the user’s thought process, especially as, IIRC, it causes the application’s icon to bounce if you’re using another app.
How am I supposed to know?
There is no way the user can know whether an upgrade will improve his experience, or waste time as he tries to recover his mistake. Asking can only make people feel stupid. Web Applications don’t ask. You get the upgrade, and you may not even notice.
Automatically upgrading software on other people’s computers could be a support nightmare, so it must be very easy to go back to where you were. Sparkle currently doesn’t provide a downgrade path.
Don’t make me wait!
Sparkle downloads the whole app on each update. For people on slower connections it’s noticeable and irritating. It would be better if the user didn’t notice it.
Overall impact
About 60% of my users seem to have disabled Sparkle. That’s a lot given that during the beta-test cycle, upgrades are not optional.
A solution
Transparent upgrades
Updates are small bidirectional binary diffs (created using bsdiff for example) that are downloaded in the background. To minimize user visible lag, they could be downloaded in small sections.
By default upgrades are applied silently at application startup, but the user can require a confirmation step using the Application’s Preference Panel.
In built version selector
The Application’s Preference Panel easily lets users switch back to an older version. It shows the version information for each version that Sparkle currently only shows when checking for a new update. Because each downloaded upgrade is a bidirectional diff, one can always downgrade.
Downgrade Appcasts
The Appcast Sparkle currently uses to inform the Application that an upgrade is available is enhanced so that a developer can correct an “Oops” by retracting a faulty upgrade. Adding this to the appcast protocol would be easy.
Harness
A small unchangeable harness is used to launch and monitor the App. If the app crashes on startup before the user could access the preference panel, it retracts any recent unproven upgrades and sends crash logs to the developer, after asking the user. Using a process to monitor another is extensively used for high reliability Telecom Systems: nine nines reliability (that’s 30ms downtime a year).
Growl and Email
If Growl is installed, it can be used to inform the user of the upgrade.
Generally however I think email is the most appropriate forum to inform the user of updates: one is more inclined to read information if one is not busy doing something else. Notice that even users who worry about providing their email addresses to the software developer can be catered for: the app itself can email the user with the information currently in the appcast when an upgrade has been downloaded.
Why I’m hoping Sparkle will implement this
I’m hoping the current Sparkle improvement discussion will consider and adopt this idea: Sparkle is already a standard, with tools like AppFresh supporting it.
August 14th, 2007 at 3:12 am
sorry I have to disagree with all the silently stuff.
Sure it is a bit annoying to prompt the user all the time but it is their computer not yours, they should authorise all changes. That is what the installation authorisation dialog that asks for an admin user’s password is for too.
smaller updates sounds like a great idea though.
August 14th, 2007 at 3:38 am
I think silently should be the default: I personally just need to be sure that I can rollback bad changes easily. I don’t need to know most of the time.
Of course, for people who really care to be asked, “the user can require a confirmation step using the Application’s Preference Panel”. I’m certainly not advocating overriding the admin password if the user is not an administrator though.
August 14th, 2007 at 8:27 am
I’m definitely planning to do diff’d updates for Sparkle 2.0.
We’ve discussed the version downgrading, but there’s lots of concerns about backwards-compatibility of file formats and various problems that could arise in going backwards. Generally stuff isn’t forwards-compatible, you know? Any thoughts on that? Forcing the developer to explicitly define rules for going backwards to each version kinda sucks.
I like the idea of downgrade versions. I sure have made some bad releases that I would like to retract. I’m thinking a list of retracted versions at the bottom of the feed like so would work:
aslkdfjasl;kdfjal;ksdjf
3.0
If you changed something in the archive, it’d certainly have a different DSA signature since its SHA hash would be different. This means that Sparkle would have to keep around the update archive to check against all the time, which is kinda silly.
The harness idea is rather ingenious, actually. I like. It’s esoteric enough that I’m not sure I’ll get to it, but I like it.
And yeah, I’ll notify by Growl. I don’t know if by email. It’s easy enough, I guess.
Thanks a lot for your thoughts!
August 14th, 2007 at 4:19 pm
[…] ansemond.com Find It! Keep It! developer’s blog « A better Software Update mechanism […]
August 14th, 2007 at 4:20 pm
Hi Andy,
Thanks for considering these ideas.
Your point about file-formats is a good one. I wrote up an answer here because it’s a complex problem.
Yes, I was thinking along the same lines for retracted versions.
In my vision, one would keep the bidirectional diffs around, unless the user requested to delete them. When you’ve got disks ranging from 80 Gb to a Terabyte, a dozen extra Mb over a year is probably not going to be noticeable. And, as a user, I’d be much happier knowing I’ll never lose my stuff due to an upgrade. Maybe I’m weird, but I keep the old versions of all the software I rely on.
My wife also pointed out over supper last night that one should check whether or not the software is supported by the OS you have when upgrading. For instance Delicious 2.0 is I believe Leopard only. People with Tiger should not have the option to upgrade to it because it’ll break something.