Auto-updates

The idea of auto-updating software is not very new; since modems have been around, several software packages have made use of auto-updates, where the software automatically downloads new data and software. America Online is one such program that has, for a very long time, done auto-updates. I was also involved in a project back in 1993 that did auto-updates. There are two types of auto-updates:

• Updating the software executables and libraries

• Updating the data

Regardless of which type of automatic updating your software employs, some common usability points exist between the two:

• Allow the users to cancel an automatic update.

• Include a timeout check in case the file stops responding, and let the user choose whether to resume.

• Allow for resumable downloads if possible.

• If the downloaded file is corrupted, discard it! Don’t overwrite a perfectly good file. (This should go without saying, but I’m mentioning it here just in case.)

In the following two sections I cover the usability issues surrounding both types of auto-updates.

Automatically Updating Your Software Itself

Of the two types of auto-updates, auto-updating software is the touchiest. The reason is you don’t want to be messing around with the very executable files that encompass your running program! Windows systems, for example, will not let you overwrite or delete files that contain currently running code. Unix is a little friendlier on the way it does file locking, in that it will actually temporarily maintain two different versions of the file: The programs that have the file open will see the original until they shut down and restart. Other programs will see the new file. But you can still run into problems with Unix if you are modifying several libraries: You might have five shared libraries that you are modifying, and you’ve so far downloaded and modified three of them. Just then another user might start another instance of the software and load all five shared libraries. Three are new; two are old. That could be a mess.

From a safe programming perspective, then, you want your software to change itself only when convenient for the user. In general, here’s a good rule of thumb regarding convenience:

• Windows users are likely to tolerate auto-updates of software.

• Unix users are not likely to tolerate auto-updates of software.

• Macintosh users might be willing to tolerate auto-updates of software.

As for the Unix situation, if you’re a programmer, you probably have worked with Unix systems administrators. Do they really seem like the type of people who would want their software downloading automatic updates to itself? I didn’t think so.

From a usability perspective, consider the following when updating the software:

SUGGESTION

Wait until the users have finished using the software before updating. In other words, wait until they want to exit the program.

I made that a suggestion and not a rule, because you might have times where you absolutely must update right away, such as in a stock program or some program with legal issues. Now here’s another one:

RULE

Let the users decide if they want the update. (They might not be interested in the new features.) And further, let the users choose if they want the software to never update itself; they might, after all, be happy with the current feature set.

I can think of at least one program that updates itself when you exit, and then it restarts automatically. Let the users specify whether they want the program to restart. Don’t automatically restart the program for them, especially if they’re exiting. And finally, when downloading an update:

RULE

Warn the users how long the update is going to take, please. (This is especially true with dial-up connections.)

Automatically Updating the Data

Because a lot of people have “always-on” Internet connections (such as cable modems), your software can take advantage of the Internet and automatically download revised data right while the users are working. For example, Microsoft Streets and Trips has a really nice feature where it can download all the latest road construction information from across the United States.

If you are going to include such data auto-updates in your program, please follow the suggestions I’ve outlined throughout this chapter about not assuming that the users are online and so on. But also consider these points:

SUGGESTION

Don’t require the users to automatically update. They might not want to do it right now!

And on a similar note:

RULE

Don’t sneak around and update behind the users’ backs. Ask before downloading an update, whether directly or through a user scheduling the update.

The second point is especially important in this day and age of viruses, Trojan horses, and other dangers. If I see some Internet activity going on in the tray section of the taskbar of my Windows system, I get extremely suspicious. If I see that my computer is downloading data, then I get worried. So don’t be sneaky about the downloads.

You might also let the users schedule downloads. For example, if their computer is always on, you might give them a way to configure your software to download the data updates at midnight every night. But again, include a safety check: If for whatever reason the Internet connection is not active, handle the problem accordingly, such as by simply skipping the download and kindly notifying the user.

Tip

If you choose to notify the user, please follow all the good usability suggestions; don’t freeze the computer by putting up a system-wide modal dialog box, for example. I’d personally opt for a message in the status bar, perhaps—something very innocuous.

After your program downloads the data, it can handle the data appropriately. Sometimes when you’re writing a program that downloads data, you might have no choice but to restart the program. But please try to figure out a way that you don’t need to restart the program. Can you unload the old data and then reload the new data? Only in extreme cases should your program require a restart. Don’t force a restart simply because you, as a programmer, find that to be the easiest option. Choose good software over programming ease!

But also, if the users are in the middle of working with the data, don’t force them to stop what they’re doing. And don’t interrupt their work with a modal dialog, loudly announcing to them that new data is available. (Don’t you love it when you’re typing along and a dialog suddenly and mysteriously opens just as you happen to press the Enter key, and the dialog takes the Enter key, instantly shuts, and you’re left wondering what on Earth happened?) Instead, save the data away, and wait until a logical and gentle time to let the user know that new data is ready—if you even need to let the user know. If you don’t have to, then don’t!

For example, suppose your software calculates some financial data, and it periodically downloads various rate tables. The user might be entering some checks or whatever, and while doing so your software happened to download the new data. As soon as the user is ready to run an analysis, you can go ahead and let him use the new data you just downloaded. Why announce it to the user?

Or, you might do this: When the user is ready and clicks the Calculate button, you might open a dialog box asking whether to check for new data. Include on the dialog box one of those “Don’t show this dialog box again” check boxes in case the user doesn’t want you to ask each time.

Or, don’t even bother: Include a separate “Download the latest rate tables” command, and let the user choose when to download the tables. With any of these options, you’re not sneaking around, and you’re not halting the user’s work.