Updates: the software after-party

Humans are moany creatures. From digressing about the over-roasted nature of Starbucks coffee to how our neighbours are too noisy, we like to complain about how difficult our life is.

And people like to complain about software. People moan about the price, the poor documentation (often with good reason) and the lack of enough features. But indecisiveness is engraved in our genes, too, since people moan when their software doesn’t work, then moan when they have to update it, or install the latest patch to make it work.

I admit that I have some sympathy, since the majority of most software updates are done poorly, and are something of an annoyance. User experience isn’t just about the software itself – it also encompasses the delivery and after-service of the product, and both of these are often implemented badly, with little consideration about the people who are going to use them.

A good software update process should be:

1. Unobtrusive
2. As frictionless as possible

But a lot of software updating mechanisms are bad. Here are the key offenders:

1. Timing

I think Joel Spolsky proposed this very well in his discussion with Jeff Atwood in episode #62 of the Stack Overflow podcast:

Spolsky: Well one thing that always bugged me about Firefox is that, my Firefox window is sitting there all day long, doing absolutely nothing, except for those few minutes of the day when I’m using it; and sometimes I really need to use it, so I launch Firefox, and at that exact moment it says “This would be the perfect time to do an upgrade!”

Atwood: Yes.

Spolsky: So it’s kind of weird. Like, why is it at startup it does the upgrade? How about at exit or at idle time or something – some time when I’m not using it. It picks the only time when it’s annoying, to do the upgrade.

I think this is perhaps the biggest bug-bears of software updates. Applications always seem to want to update themselves at the most inconvenient times. This principle of only updating at startup is actually proposed as the standard for Mac applications in the Apple Human Interface Guidelines (an article which provides guidance on developing software for OS X):

To provide a convenient application-update experience, follow these steps:

1. When your application fully launches the first time after installation, start a separate thread that checks for updates.
2. If a newer version is available, keep track of this fact in your application. Do not notify the user at this time.
   The next time your application launches, check the state of update availability you determined in step 2. If a newer version is available, immediately notify the user.
3. If a newer version is not available, start a separate thread to check for updates and keep track of the results in your application. Do not notify the user at this time.

Although I’ve expressed fairly positive feelings about the Apple Human Interface Guidelines I still don’t agree with this.

Apple’s argument for this method is to “avoid startling the user with unexpected and intrusive update notifications that occur outside the context of your running application” and to provide “an update notification consistently and immediately at launch time”. Although I can see where Apple are coming from to a degree, I think they’ve got it wrong. As Joel says, the best time to do an upgrade would be when the application is idle, and waiting until application startup to do the upgrade is in itself often an annoying interruption.

2. Restarting

One of the most irritating dialog boxes (perhaps of all time) is the “Please restart your computer to finish installing updates” dialog box:

It’s annoying because it’s obtrusive. People generally don’t want to quit all of their running applications, restart and then spend more time getting back into the flow of what they were doing again.

A well-designed software update process should work in such a way that the update does what it can do without restarting, then perform the required tasks when the user organically decides to restart at their convenience. If the application can update itself without restarting the entire operating system, even better. And reminding the user every 5 minutes or placing an annoying icon in the task bar can be somewhat irritating too.

3. Preserving Configuration

Although a fan of the Opera browser, when upgrading from the Opera 10 Beta to the Release Candidate, it decided to use my settings for the last stable version of Opera installed (9.64) and not the Beta, which I’d been using for a couple of months. The end result was that I lost a load of bookmarks and feeds which I had subscribed to during the period I was using the Beta. Let’s say I wasn’t too happy.

Preserving the configuration from the last version is a really important part of a good software update and helps to ensure that it is a seamless, frictionless transition. It also makes your users more willing to update if they know that their data is safe.

4. Automatic Updates

I have mixed feelings about automatic updates. On the one hand, they are really convenient, because they are silent and work in the background; however, you have to also “trust” the application at some level to be happy with it updating itself when necessary.

Also, you may not always want every update – patches and updates to improve security obviously have their attraction and are important and should be installed. However if it is an update to add some extra functionality or some plugin that I don’t need (for example Windows Vista Ultimate Extras), I wouldn’t necessarily install it.

A good way to provide a workaround is to categorise updates and provide different user-configurable automatic update settings for different categories – for example, I’d be happy to allow certain applications to automatically update themselves with security patches, but if there was an update that wasn’t strictly urgent or some kind of fix, then ask me whether I want to install it. This also removes some of the intrusiveness that most updates have. However, this method can be sketchy ground with some users, especially if enabled by default.

Final Thoughts

I don’t think software updating is taken into as much consideration as it should be. The application itself is not the only part of the experience that the user wants to be as frictionless as possible, and developing software which offers a good experience to the user also means taking both the preamble and the after-party into account.