Neil Mix

If it’s a good idea, go ahead and do it. It is much easier to apologize than it is to get permission.

- Admiral Grace Hopper

Auto-updating software is neat. It saves the customer from painful manual updates, and it helps the vendor by keeping people up-to-date with their software.

Unfortunately, the auto-update feature got off to a bad start in UI. Due to mindless follow-the-leader mentality, it’s had a hard time recovering ever since.

Case in point:

While this is an extreme case, it also illustrates a problem that we’ve all had with auto updates, namely how they manage to interrupt at the most inopportune times.

The problem boils down to 2 factors: a) permission, and b) timing. A little forethought solves both problems fairly easily, but bad precedent of previous implementations casts a long shadow.

Programmers often get snagged on the concept of permission. The (non-conscious) line of thought is: we wouldn’t want to disappoint someone, so let’s make sure it’s OK before we proceed. What’s missing is opportunity cost: people like having their chores done for them. By thinking that doing-without-consent is risky, we miss the opportunity to make the customer to be pleased as punch that someone is quietly getting-things-done for them.

Early on in the history of software auto-updates, someone decided that it was very important to interrupt the customer to make sure that they don’t object to having their software updated. Early versions of auto-updates went something like this:

• start the app
• app says, “Updates to your software may be available. Would you like me to go check?”

First off, how lazy! This comes straight from the playbook of how to ruin your career: when a simple but helpful task needs doing, check with your manager before doing anything. He or she will be impressed with the amount of reassurance and micro-management you require.

At some point someone realized, “hey, that’s kind of annoying.” And thus the auto-update question was no longer asked on startup, but instead asked at some random time on some random interval — but the same time and interval each time, so as not to be confusing.

Did you see the bait-and-switch? The problem was with asking too much permission. But “fix” was to change the timing. I quoted the word “fix” because the solution didn’t improve things much. We went from an annoying every-time-I-start-the-app question to an annoying randomly-interrupt-me-in-the-middle-of-my-workday question.

After a while, someone made the startling realization, “hey, we could check for updates automatically!” No doubt someone objected that permission should be asked first, but thankfully the objections were overridden. So now we have: randomly-interrupt-me-when-updates-are-available. Which is better. And this is pretty much state-of-the-art for auto-updates these days.

But we’re not quite there yet, are we?

So what to do?

1. Just grab the update already! Beg forgiveness rather than ask permission.
2. Don’t interrupt me while I’m working! Wait until the next time the app is started, then perform the update and let your customer know what you’ve changed.

So now we’re at: annoying-interruption-on-startup-only-when-updates-have-been-made. But how annoying is the interruption, really? Presumably you’ve got great new features for your customer that they’ll be happy to hear about. Perhaps rather than being annoyed, your customers will feel pleasantly surprised by the gift of new features they’ve received this morning. Your software just made their lives easier, on multiple levels.

Still sound too aggressive, too risky? Consider this: there’s already strong precedent for the auto-update process I described, just not on the desktop. It’s on the web. Websites don’t ask permission before updating the software. (They can’t, really.) In some cases, when the updates are really big, they might let you know about the changes your first time in. (And occasionally they may provide a graceful “downgrade” to the old version if you protest.)

But most of us never really noticed this subtle distinction between desktop and web auto-updates. That’s because we’re too sympathetic to the underlying technology. But when we wipe the technical details away (as we should when designing our UIs), the truly-auto-update isn’t so scary after all, now is it?

This entry was posted on Tuesday, December 11th, 2007 at 10:14 am and is filed under Engineering.