Oh app, for crying out loud, go update yourself

When I start my PC these days, I see six or seven different applications in the Windows system tray screaming for attention. “An update is available! Update me!” “No—Update ME!” they cry. Great. Another click, another progress bar, another completely minor upgrade accomplished. One wonders: is there a meaningful role for the user in this process at all?

When it comes to updates, companies making client software have an enormous disadvantage versus web-based competitors. Deploying new server bits is a problem of considerable complexity in its own right, but at least the web software company gets to decide when to deploy and who conducts the upgrade. The user has no choice whether to use the updated site or not. In my own experience, most site updates seem to go rather well (your mileage may vary), so it’s not something I even pay attention to.

The client software manufacturer, meanwhile, has the challenging task of deploying bits to a quantity of machines orders of magnitude greater in size. The target machines could be running in any number of configurations the manufacturer isn’t even aware of, much less have in their test matrix. The update process is under the supervision of a user who generally has no idea what to do if something goes wrong.

Nevertheless, the mere existence of the constantly upgrading web-based competitor puts considerable pressure on the client software manufacturer to make the update process as transparent as possible. To be sure, client software updates are much less of a pain than they used to be. DLL hell is, by and large, no longer a nightmare plaguing every single update. Persistent broadband connections make checking for updates easy, and downloading new bits quick. In the vast majority of cases, the user needs to supply no additional data, the updates fall under EULAs the user has already agreed to, and the software already knows where it should be installed.

So why make the user agree to the update at all? Why not just do the update for them—at least in the cases where the user doesn’t have to do anything else?

Users at the extreme end of the techno-savvy spectrum may demand the ability to control when updates happen. Let’s stipulate that they should have the right to do so. I expect that most users, however, don’t care to exercise this right. I think the average person would only ask the following of any client software manufacturer regarding updates:

Rule 1: Don’t screw up my PC. This includes things like surreptitiously switching my home page, spamming my desktop, etc.

Rule 2: Don’t try to upgrade your product when I’m in the middle of using it. In general, don’t distract me from what I’m doing right now. To be honest, you’re really not that important to me.

Rule 3: Don’t reboot my PC. That’s rude. Whatever Adobe Acrobat Reader is doing that requires a reboot isn’t worth it to me.

I think that’s about it. Is the typical client software upgrade user experience these days actually supporting these goals?

Following a reboot on my main home PC, MSN Messenger (now called Windows Live Messenger) is the application most likely to be yelling for attention. Its upgrade experience is at the, er, “good” end of the user experience continuum for these sorts of things.

This little window that pops up is called a “toast” by the MSN design team because it pops up like a piece of toast. This particular piece of toast is lying. Clicking it brings up a dialog that does not, in fact, offer any more information.

Instead, the toast has actually tricked the user into starting the upgrade process. (For the record, this particular upgrade to MSN Messenger Version 7.5 will require a reboot.) The user can try to leave, but only by being forced to agree to be bothered again later. The user can click yet another button to see a web page that (finally) tells them why they should care about this upgrade:

It's interesting to wonder which of the features listed above was the one that required a reboot.

In any event, the list of new features is beside the point. The placement of this information—three clicks away from the user—makes this fact obvious. The user has no choice in this process. It really doesn’t matter whether they like the new features or not. The manufacturer has updated the software, and will at some point stop supporting the old software. The user is going to have to upgrade at some point, or run the risk of being shut out when they really do need the service.

Why can’t the manufacturer simply arrange to have the client software automatically upgrade itself at some convenient time?

First, there’s the matter of preference—the user might not actually prefer the new software to the old software. This is entirely likely, but allowing them to keep running the old version seems like an incredibly inefficient solution to the problem. This creates tribes of users running old versions, complicating maintenance and improvement of both the client and server software. The enormous resources thus wasted could be put to better use finding out why people hate the new software and addressing the core design issues. This is what good web sites do. Or, if the differences are irreconcilable, the manufacturer can resort to leaving in program options that preserve aspects of the old user experience. In any event, making upgrades optional simply delays the inevitable disappointment of a forced upgrade when the manufacturer eventually can no longer support the old version.

Second, there’s the matter of bad upgrades. Sometimes this is because the manufacturer wrote buggy code. Postponing the upgrade isn’t going to fix this problem—the user is going to play upgrade roulette at some point. As noted earlier, the hapless user’s hardware and software stack may operate in a configuration outside of the manufacturer’s testing matrix. If this really is a critical reason to leave upgrades under a user’s control, then the existing user experiences fall far short of actually supporting this goal.

The problem is that no upgrade experience I’ve seen actually helps the user conduct a realistic evaluation of whether they can expect the upgrade to go smoothly in their configuration. As seen above, upgrade announcements for most applications are entirely rosy lists of new features, with no indication of what might go wrong. The little pop-up toast affords no links to resources such as upgrade FAQs, knowledge base articles, or most importantly, current user discussions of issues related to the upgrade. Users who care about upgrades currently must find this information on their own.

Given that the mainstream user can’t invest that kind of time, the only user experience that makes sense for them is automatically upgrading them at a convenient time (e.g., the machine is idle and it’s the middle of the night). If the program is in use, the program should at least download the bits, install as much as it can, and be prepared to cut over to the new version when the user next restarts the application. (Mozilla Firefox does this, although with too many dialogs for my taste.)

To support those users who want to carefully manage the upgrade process, the manufacturer can offer an option for manual upgrades. This option should—quietly—notify users when an upgrade is available. Since the mainstream user can’t be bothered to understand that option, the option should default to automatic upgrades. This scheme is, in fact, the route that Microsoft has finally taken with Microsoft Windows upgrades. Their user experience certainly isn’t ideal, and yet on balance Automatic Updates probably saves far more grief than it inflicts. Given the challenge of the client software upgrade problem, that’s about as good as anyone can expect.

Comments

[Simon]

And what would you recommend to do in case the current user doesn't have admin rights? Inform the user at some point or leave him/her alone? At best probably default to the later and optionally allow the former...

[Alexander Groß]

What's even more annoying is software that's trying to update but will eventually fail because I'm running as an unprivileged user. One has either to download the updater manually and do a runas or start the application as an administrative user and trigger the update manually.

Unfortunatly, most products don't detect if they're performing the update in a limited environment and offer an runas-dialog accordingly.

My two cents.

Alex

[dc]

I disagree. Automatic updates, as you describe them, result in confused and unhappy users. Obviously, it would be ideal if every single user wanted to and did keep up to date with the latest versions of all their software, but in the real world this is just not true--and for good reason.

By and large, computer users (especially non-savvy ones) follow the "If it ain't broke..." rule closely. As you note, updating will possibly cause no new problems, but may cause a dozen. Not updating will not cause any new problems--unless Microsoft gets lazy and decides to not support old versions of Messenger (again). (I've never heard a good explanation why this keeps happening. Is IM protocol really that hard to keep backwards-compatible?)

Updating is, generally, good. Not updating, however, is not generally bad--unless your software was bad in the first place. Unfortunately, the best compromise, to me, is the current paradigm, which at the least keeps the user informed and in control over what software and new "features" are being installed on their computer. We should work at improving that experience, and not go behind the user's back in the name of helping them.

[Shaun]

One thing I don't like about the automatic updates that programs go through nowadays is the frequency with which they have to be updated. Windows is notorious for this, but Adobe is bad as well (which was mentioned). Why are such frequent updates required? My first conclusion is that the company does shoddy programming. I also wonder how many of these updates are there to fix something from a previous update that wasn't coded well, etiher.

It seems to me that unless they put out a crappy product that needs to be fixed pretty quickly, there's not a dying need to have a new update out every couple of weeks. I'm willing to cut Windows some slack due to the people that will go to their graves trying to destroy it, but everything else seems excessive. Waiting for a couple of months before trying to push out a new update doesn't seem like a bad idea on any level (with the obvious exceptions of accidental bugs that even great programmers make on occasion).

This greatly reduces the different version problem talked about in that blog because there aren't so many updates to provide different versions. As for MSN, pushing out an entirely new update over renaming the audio and video components? Come on! Save useless junk like that for another version when something important needs to be changed.

Users don't want the bleeding edge of a program. They want one that works. I don't know how they figure the problem is how to get updates to users without bothering them. I think the real problem is figuring out how to push out as few updates as possible. If that means we have to wait an extra couple of months for some minor feature, I think I can speak on behalf of the average user when I say that this is quite all right.

[Tom O'Neill]

Great post. But one advantage of at least telling the user about the upgrade is that it gives them a clue what might be the problem if their computer suddenly stops working.

[Centaur]

No. Software should not autoupdate itself, for several reasons.

First and foremost, software runs as a limited user, and updating requires write access to the binaries which is only granted to administrators. Thus, an application cannot do anything but ask the user to ask the admin to update.

Second, updating requires Internet connectivity, and sometimes a substantial amount of traffic. Suppose Microsoft releases an Office service pack of 100 megabytes. Also suppose a local area network with 300 users having the same version of Office. If they all start downloading, it will cause almost 30 gigabytes of traffic, rated $55 per G, for a total of 1650 US dollars. On the other hand, if I bring the update from my work place (where it was downloaded and stored on the server) and offer it to my neighbors, it costs us nothing.

Third, if Office decides to update itself, it might (and most probably would) use up my prepaid Internet limit, which will cause me to be disconnected from the Internet. The update will fail, unless the updater supports resume — and it most probably doesn’t. So I lose my traffic limit — and this means money — for nothing. Also, I lose my Internet access, until I manage to go and pay for more, which may (if it was Friday evening) be two days and three nights later. A weekend without Internet access, what?

Fourth, if software can update itself, it can possibly be tricked into updating itself with a malicious update. On the other hand, if I am told that an update is available, I will visit the vendor’s web site and find out that there is no update. Or I will download the fake update, install it on a controlled machine, see the effects, submit it to my antivirus vendor and not install it anywhere else.

Last but not the least, I have the right to know exactly which version of which software I have installed, if for nothing else than bug reporting. If it autoupdates, I lose this knowledge and have to resort to unhelpful claims like “last Sunday it worked and today it doesn’t”.

No, software updates must be done in a controlled way by the system administrators. Even if said administrator is the same person that ordinarily uses that computer.

[Ilya Birman]

When you pay per traffic, you never let any program download anything automatically. You must first decide whether you want to pay money for this upgrade. And believe me, if its "Audio was renamed to Voice", it's not worth ANY money :-) I don't want to download some 5 MB (or what) to throw $.6 away just for that.

The only thing I let autoupdate is my virus scanner database.

So I vote for "Update? yes/no" dialogs, where "no" actually exists and means "no" :-)

[Michael Zuschlag]

Some of comments seem to be comparing auto update with no update or "manual" user-initiated update, but I don't think that's what Jan has in mind. I believe he's talking about comparing auto update with *prompted* update, and here I think auto update makes more sense. What's worse than auto update with a limited user? Prompted update that annoys the user with "Would you like to update?" then after the user clicks OK, says, "Nope. Sorry. Never mind."
That said, auto updates aren't for every update. They probably should be limited to updates that really everyone *needs* to do (e.g., security issues or major-task-halting bugs). If it is truly important enough to demand a prompted update ("Update *Now!* We *cannot* tolerate users who aren't updated!"), then it's probably important enough for auto update.
But "Audio was renamed to Voice"? That probably doesn't belong in either auto update or prompted update, but user-initiated update (that includes: user has issue, checks knowledge base, see patch available, downloads patch). A compromise is to provide the user with the opportunity to subscribe to an email list that sends details of each update as it becomes available.
There are really two rules: (1) Give the user enough information to make an intelligent decision on whether to perform a task or not, (2) Let the user decide *when* to engage in a task that requires his/her interaction. Prompted updates break both rules. Auto updates breaks only (1), and I believe Jan gives examples of when that's okay.

[Peter H.]

My vote for one of the most annoying instances: the monthly update by Microsoft to install the "Microsoft Genuine Advantage" check. How many times to I have to approve these updates before Microsoft decides I have the real thing?

Massive disagreement with Centaur. Optomize for 80/20. If you're downloading 100 megs, that's a corner case. Windows has way too many dialogs popping up everywhere. And to those who pay by the byte ... you're on the wrong side of a tectonic shift in thoughts about bandwidth.

[gsl]

I strongly disagree with you. Although you are certainly addressing a valid issue, I believe you are trying too hard to solve it.

There are several reasons why applications should _never_ auto-update itself.

1. Trust. Although you might trust companies like Microsoft and Adobe (I certainly don't. WGA phoning home is one good example), how would you feel about your file-sharing app auto-updating itself? Or iTunes auto updating itself in order to give you even better DRM? This isn't necessarily about the risk of receiving malicious software, but how the user feels about letting an application change the permanent state of the computer, possibly breaking it because of a minor bug, without having any idea about when it happened and what caused it to happen. What good does system restore do then?

2. Security. How many of the 20 different auto-update implementations, that is installed on your system, do you think have a bug that allows "bad" people to remotely execute their code on your computer without you ever knowing about it. The nature of this functionality is to execute code downloaded from a server without "bothering" the user. Put the word "malicious" in front of code and you've got every hackers wet dream coming true.

3. Technical issues. What if I am connected to the net through my mobile phone? That small update relative to the broadband standard of today might be pretty expensive then.

4. Resources. When should this update happen? Unless you can make the update happen in a flash, there is no way to do this without annoying a significant percentage of your user base.

5. Unexpected behavior. An update would typically do stuff that the application doesn't usually do. This might conflict with the user permissions, firewall settings, antivirus, and other applications that restricts what an application is allowed to do in an effort to prevent the execution of malicious code. Obviously, this might result in the user being hammered with warnings, for no apparent reason, and might even result in a broken application if the updater is poorly coded.

An application should behave in a predictible manner. It should never go off and do stuff that it doesn't usually do, without asking the user. It should also never alter the permanent state of the computer without explicit user consent. These are basic design principles.

So then what? How can we solve the problem?

Well, the problem here isn't really new. It boils down to being a common task that is implemented in 10,000 different ways, because there's no rules that define how it should be done. The solution is simple; create a framework that developers can use to implement the functionality in a consistent way. The user will as a result easily learn how this works, and the entire notification and update process can be made less obtrusive (which means less annoying).

Imagine an update control panel that gives you an overview of the update status of every application in the system. Notifications might be as unobtrusive as a small icon in the notification tray showing the number of updates that are pending. A stronger notification might be issued if updates have been pending for a month.

Sorry about the article-type length of the comment, but it just had to be said :)