Updating out-of-date software and applications seem like such a simple task for technology savvy users that it is quickly overlooked. Developers assume “Oh but of course, users simply need to click on my little notification box…accept terms…choose a installation location…” Do you see where I am going with this? I think it is time to re-think how we (IT professionals) think and approach about the simplest of tasks for our user base.

Let me run you through the scenario of what a typical Windows user has to run through for updating their computer third-party applications. For this example, I will lay out how some companies perform updating elegantly (Google’s Chrome) and how others fail to achieve an acceptable experience (Oracle’s Java); and finally I will lay out an overall plan how all of these seemingly disparate platforms can unify their experience and improve the overall experience for each of their user bases.

Adobe has a page on their site that discusses the varying levels of Adobe Flash version penetration among its user base (located here). Sample data from September 2010 shows that at least a quarter of its user base does not have the most up-to-date version of the player (in this case, it is version 10.1). This is an unfortunate statistic, because in addition to the new features and performance improvements that are released with each new version, it also bring with it numerous bug and security fixes.

Oracle’s Java, which is approximately supported by well over 700 million PCs (source), has the following process for users to update their pieces of software:

1. The Java Scheduler (a background process named jusched.exe) determines that the current version is out of date.
2. A small pop-up appears on the lower right hand corner of your screen that says “Java Update Available”
3. The user clicks on this pop-up, assuming they’ve seen it when it first popped up.
4. The user is prompted with a window that states the latest version is “Java X Update XX “, the user clicks Install.
5. Java Scheduler begins to download in the background, when that is completed a new pop-up appears at the bottom right of the screen notifying the user to click on it once more.
6. The user clicks on the pop-up and clicks Next and agrees to the License Agreement.
7. The user is prompted with an additional screen to install some toolbar or additional software that Oracle has an agreement with
8. Java goes through the process of updating
9. Java is now updated

This process depends on many variables that puts the onus on the 700 million users to ensure that they know what the Java is, see the icon in the taskbar or the dock, and verify multiple times that they indeed want to update it. No wonder products aren’t often updated. Although this is one example of how users are faced to update their applications, it is very similar to many others out there today.

The second update method we will take a look at is the method that Apple’s App Store uses on the iPhone. This process is slightly less intrusive than Java’s, but can still use some improvements. Here is the process that users must go through:

1. The App Store periodically checks to see if any updates exist for installed applications. If an update is identified, the App Store application subtly notifies its user by putting a number on the application badge.
2. The user notices an update exists for one of their applications and click on the App Store badge.
3. The user clicks Update All and enters their iTunes password and clicks Ok
4. The App Store then minimizes and begins downloading and installing all updated applications
5. The application in question is updated.

The only interaction required by the user is to notice that an application requires updating and to act on it by confirming that the user wants to update all applications in question. Again this puts the duty of application updating to the users.

Now let’s take a look at a third and final method of delivering software updates to users. Google’s web browser, Google Chrome, has a very stealthy way of updating its software. Here Chrome’s process:

1. Chrome determines that the current version is out of date
2. Chrome downloads an updated version of the browser in the background. No notification is given to the user.
3. The user is done with their browsing session and closes all windows.
4. Chrome remains open in the background to begin installing the updated version. Again, no notification or disruption to the user.
5. Google Chrome is now updated.

Although on the surface this may only appear that the update process only chops off four steps, it is like comparing apples and oranges. Java’s method of update method requires multiple confirmations from the user and disruptions. Google’s process is completely transparent to the user as no confirmations, pop-up boxes, dialogs, and any other type of disruption occurs for the user. The only thing the user has to worry about is what blog to read next.

So which system is best? I propose that designers should combine the last two methods (Apple’s App Store & Google’s Chrome). By combining background updates (Chrome) and a centralized update repository (App Store) users would be able to update all of their applications efficiently. This can only be achieved if we could provide an unified approach for updating any type of application.

As it stands today it is up to each individual application/software to manage its update process. I call on OS developers to provide a method for users to utilize their current update method (Microsoft’s Windows Update & Apple’s Software Update) to third party developers. With that said, if the OS update methods were to implement background installs and allow for third-party software developers to utilize their update process, it would greatly increase the overall user experience for computer users.