There you are, sitting at your desk. Your thoughts are coming alive on the glowing display in front of you, brought into existence by your fingers effortlessly running across the keyboard. The outside world has become a distant memory - even the music flowing into your ears from your headphones has grown muffled and removed.
You are in flow.
Suddenly an unexpected idea spawns in your head. This idea must be preserved and dealt with, but you can’t risk losing your flow, so you quickly launch your favorite notes application to jot the idea down before it escapes the grasp of your mind.
A new version of UberNotesMaster is available, would you like to download it now?
Stumped, you try to gauge whether the update is quick enough that you won’t lose your flow, but you have already lost. Your flow is interrupted, the idea is escaping, and your application is still not updated.
Typically, when an application announces that it has a new version available, you have two options:
While I like upgrading my software as much as the next person, I launch an application for a reason; to use it - instead the application forces me to choose between performing the task at hand or get the latest version of the software. You know what, I want both!
Instead of asking me to update an application when I am actually trying to use it, how about dealing with the update after I am is done using the application?
This way, the upgrade dialog could appear when I quit the application, and the update would take place while I am doing my work in another application. A much smoother experience whose only interruption is easily dealt with.
It might, however, prove to be quite frustrating when you attempt to shut down your computer and all running applications want to update themselves. Also, OS X users are known to never actually shut down applications and also never restart their machines, so they would end up never updating.
A variation of the above would be to still ask me, the user, when I launch the application, but allow me to say “Yes, I want to update, please download and update in the background while I continue with my task at hand”. The actual update then happens after I quit the application, making the entire process almost invisible to me.
We could also move the application update process out of the actual applications themselves. This strategy is known from the iTunes App store, where updates to all installed applications happen in the background while you’re doing other stuff. Smooth and seamless and allows you to maintain your installed software when /you/ are ready for it.
The process in itself is probably the smoothest offered, but it also bears the penalty of centralization. This software updater application somehow needs to know about all independent and unique applications you have installed and be able to update them.
Larger software vendors like Adobe have taken this approach and created their own - usually pretty crappy - updater applications. I would love to see something kickass here - preferably from the ISV community, but it could also be interesting seeing Apple build this into their own Software Updater app (or in the Windows equivalent if one exists).
Now, excuse me, I have to update my blogging application…
How spoton ..The outside world has become a distant memory.
It is time to exit Cyberspace and visit the Outside World for an hour or two.
Great article!
It’s spot on .. I usually click “Later” several times before updating because I’m opening the application to use it! Having clicked “Later” three times, however usually causes me to update it with a grunt :)
I like the Google approach which just update your application if it’s a minor release (I have seen this done for gtalk and google desktop). For major releases it downloads the application in the background and notifies you if you haven’t started the application for a while (did it for Google Chrome).
Well, if you’re really interested in updating software out-of-band, look at the Linux distributions: they have that down pat. Particularly, look at apt and Arch Linux’s pacman. On Debian and Arch Linux (and probably all the rest) even apps like Firefox that have their own update machinery are usually updated using the standard out-of-band updating mechanism (namely, apt in the case of Debian, pacman in the case of Arch Linux).
I use an app called gBrowser - http://www.immaterialgoods.com/gbrowser/ - for image viewing on my Mac. gBrowser has a lovely handling of updates. You still get an “update available” notification on launch (or when an update is detected) but instead of just “apply” or “later” you have also have the option to “install on quit” - which does just that.
So your flow is only marginally interrupted and the updates still get applied. I’d love to see more software updating this way.
This blog post inspired me to fork Sparkle and improve the experience a bit.
http://github.com/fileability/ReSparkle
It downloads updates in the background and only prompts users to install updates when they’re quitting. That is, when the potential for interruption is at its lowest.
If you’re lazy, there’s a prebuilt example at:
ReSparkleTest
Richard, that’s a great point, I had totally failed to consider apt, yum, and others as great examples of out of band updaters. The fact that I have chosen Linux distros because of their package manager just goes to show how important it can be.
Jonathan, I’m sure there are quite a few applications doing this properly - luckily. SubEthaEdit is one, gBrowser is one I didn’t know of.
Alex, that is plain and simple a can of awesome. I am so hoping that will make it into Sparkle proper and from there into a ton of the apps I use. Thank you for putting your code where my mouth is.
What a fine introduction to this article, well written!
What I’ve been wanting for years is some kind of general OS update mechanism. This should work so that when I have the time to update my apps, I just ask the OS to update all apps in the system. Just like Ruby’s “gem update”, just for apps!
Software providers should then be able to push out new updates via the OS. I know there’ll probably be some serious security issues to consider, but the user experience would be smoooooth :)