Michel Jansen

Silently autoupdating software is amazingly powerful, but also incredibly difficult to pull off without either stifling innovation or estranging users.

I was reading this post by Paul Irish on browser market pollution, or how IEx will be the new IE6. What shocked me was how different the life cycle (or “half-life”) of each browser is.

Just look at these graphs (source: Ars Technica):

It is easy to see when a new version of Chrome is released: the prevalence of the old version drops like a rock and in a mere month the new version has almost completely taken over. At any given time, almost everybody using Chrome is either running the latest version or the one before. Hardly anyone lags behind more than a version. Compare this to IE’s version graph and the differences are shocking. New versions hardly get adopted and a third of all users lag two or more versions behind (with IE’s release cycle, means they are missing out on a whopping six years of web evolution). I won’t go into the consequences this has for web developers (Paul Irish already did a great job doing just that), but it is interesting to look at the mechanism responsible for this difference: automatic updates.

Chrome and Internet Explorer represent two extremes in update strategies. Whereas one browser silently updates itself to the latest version whenever possible (without ever asking the user), the other only rarely gets updated automatically through Windows Update (and even then, business users relying on ancient versions get warned in advance and told how to prevent the update). Chrome’s autoupdate was the first of its kind and has been called the browser’s most important feature. It works so well, that it has since been adopted by Firefox as well (unfortunately, Ars Technica did not include a nice graph showing the version adoption for Firefox).

Although the silent autoupdate is good for keeping them secure, it also has its drawbacks. Google’s way of treating the browser as a web-app that can be updated at their wish, not when the user chooses, also brings some problems of its own. While taking away control from the user and forcing updates is good for security and the support for new technologies, it may also cause users to feel lost. In the appropriately titled article “The Cloud’s My-Mom-Cleaned-My-Room Problem“, Alexis Madrigal of The Atlantic called this “parental computing”; Google decides what is best for us and cleans up our browser of bugs and reorganises things the way it thinks is best. For the browser’s core this is fine, nobody minds a faster and more secure browser, but when it comes to making significant changes in the user interface, people get upset. Maybe they didn’t want those changes. Maybe they actually like the changes, but they still feel as an unwelcome surprise.

As a result, it is much harder to get away with major changes. Just take a look at the evolution of the “chrome” of Google Chrome. In over three years of development, there have barely been any changes in the browser’s user interface.

Compare this to the revision history of Firefox, and the difference is clear:

Granted, Firefox has been around for a solid four years more than Chrome, and the first screenshots are taken on Windows XP and the latter on Vista, but it is still hard to deny that the first four revisions of Firefox were major. At some point in the browser’s history, silent autoupdating was introduced. If you guessed that that version was 4.0, you are right. The Firefox 7 that was released today looks almost the same as version 4.0 did. It is important to note that the time between 6.0 and 7.0 was a fraction of the time it took to go from 3.0 to 4.0, but the similarities to Chrome are clear.

If updating their software is a conscious decision on the user’s part, it is much easier to get away with major changes. The problem is that users just don’t want to take that conscious decision that often. Chrome updates at least weekly and it is unacceptable to present the user with a “please update now” dialog every week. A compromise might be to release a bit less often and ask the user to update. This is for example what Apple does with their iOS. Every time you plug your phone into your USB port to sync or charge it, Apple checks for a software update. This is about the best time possible to present you with a “would you like to update” dialog. On top of that, every major revision of iOS introduces new features that are announced with a lot of “boom”. People really want that new iOS. Still, looking at the versions people are using over the past year (data taken from Chitika Insights), iOS’ half-life is rather disappointing:

It takes a year for iOS 4.x to climb from a market share of 50% (the day after its release) to about 90%. That is a year of people plugging in their phones weekly or daily and deciding not to upgrade, despite all those exciting features in iOS 4. There are many reasons people might have. Maybe they are awaiting a more stable version (early versions of iOS 4 had some problems). Maybe they are running a jailbreaked or unlocked phone and they are waiting for an update or maybe they simply never connect their phone to iTunes. Either way, a year is a long time to support an old OS.

Unsurprisingly, beginning with version 5, iOS will start updating over-the-air; no longer requiring people to hook up their phones to a computer (although the update still asks the user to confirm). Microsoft’s Windows Phone too, will be pushed out en masse. It is just a matter of time before OS updates too, will be done silently.

The value of silent autoupdating is clear. The question is, what to do with those major changes? The current trend is to have a very rapid development cycle, with in the case of Chrome a new major version every month. Soon, version numbers will no longer have any meaning. Maybe this is not a good thing. Maybe it’s time to restore meaning to major versions. Maybe it is good to get a dialog once or twice a year, that tells you: “This is new, this is improved. Do you want this now?”. Silent updating is quite brilliant, so please let that keep the bugs out and the performance in, but don’t let it stifle innovation by creating a fixed UI. This way, we can have the best of both worlds.