One Damned Thing after Another

Back in the world of manual installs, whether you install software off of a CD-ROM, a file server, or the Internet, the process you go through is basically the same, consisting of two steps. First, the software must be copied or loaded onto your local hard disk. Second, the software generally requires some initial configuration so that both you and it can work smoothly.

Edward Tufte, author of The Visual Display of Quantitative Information (Graphics Press, 1983), detests the manual software installation process, calling it "one damned thing after another." It doesn't help the user to achieve his goals; it doesn't help the program to perform its functions.

Most applications now use standard installation shells, like InstallShield on Windows or the Mac Installer. These programs are a significant improvement over the days when vendors created their own from scratch, and users now are now somewhat familiar with these standard formats. But even within these frameworks, little consideration is given to the interaction from a goal-directed point of view. Installation programs thus continue to blindly interrogate the user, force him to make uninformed decisions, and make arrogant assumptions about the way the computer is used.

The most common problems exhibited by installation programs are a microcosm of some of the nastiest software interface design problems in general. Most installation programs exhibit at least several of these design errors:

• Demanding responses without informing you of the consequences

• Not informing you of the scope of your actions

• Asking you questions to which you are unlikely to know the answer

• Asking you for answers it can determine for itself

• Not doing its homework

• Not providing for uninstallation

• Ignoring evidence of its previous activity

• Abusing system-wide files

• Putting files where they don't belong

• Overwriting shared files

• Not offering you any information about the program

• Confusing installation with configuration

• Demanding your active participation

We'll now discuss each of these transgressions in detail.

Demanding responses without informing you of the consequences

Without a doubt, this is the most common of all the transgressions of installation programs. The installation program puts up a dialog box that looks something like the one in Figure 36-1.

Figure 36-1: This is a typical installation program's first dialog box. As when you play a video game, you have only your wits to guide you. Is a full installation too much for me to handle? Am I smart enough to customize this program? Does it make me a wimp if I choose a minimum installation?

The program starts right off by asking you a question that will clearly have global consequences, is probably not reversible, and the effects of which you don't understand. Some more advanced installation programs, notably those from Microsoft and Apple, make a reasonable disclosure of the effects of your choice on how much disk space will be consumed. However, you are still guessing about the meaning of the choice. What the user needs to know is exactly what functionality he will be sacrificing if he chooses a minimal installation. It isn't enough to merely know the disk space implications, he must know the usefulness implications of his choice, too.

Some versions of this question deal with system-level resources such as communications ports, video drivers, and the like. These are particularly vexing because the wrong choice can instantly lock up the computer system, crash other programs, lose data, and sometimes even require rebooting the computer from a boot diskette and manually fixing the damage done by the installation program. Although the consequences for making a wrong choice are severe, the user is rarely made aware that this is not the time for a guess — not even an educated guess.

To counter user interactions with this kind of problem, software should practice informed consent. The user should only be asked questions whose consequences he understands. In particular, he must understand the consequences to him, not just to his computer. If the program offers configuration choices, the user must be well informed about how the various configurations affect the program's capability to help him achieve his goals.

For example, an appropriate way to create an atmosphere of informed consent is to offer an itemized list of the features, expressed in terms of what they do for the user, and which are either included or excluded from the various choices. Additionally, a prose description of the big picture from the user's point of view is necessary. Something like the following would be nice:

A minimal installation is designed for laptop and notebook computers with available disk space of less than 100 megabytes. The MicroBlitz PIM-Meister will consume about 40% less space than a full installation on your hard disk without sacrificing any critical functions. What you will sacrifice includes: most, but not all, online help text; the tutorial program for beginners; four out of seven Wizards; and, most of the more obscure import and export utilities. If you want the minimal installation but feel that you must have one or more of the excluded facilities, you can easily request the minimal installation with special options and add the desired facilities back in. Also, you can always easily change your existing configuration by running the installation program a second time.

First, this statement describes the main reason why the user might want to choose the minimum installation option. Second, it describes, in some detail, exactly what is sacrificed to get it. Third, it informs the user how and why he can override the setting if he wants to. Fourth, it reassures the user by informing him how he can change things at a later time, should his needs change. This is informed consent, and the user will be able to make intelligent choices and feel good about them. Apple's installers are not quite this verbose in all instances but, in general, do a similar job of seeking informed consent.

It's a taboo in programming circles to create verbose programs, but this applies mainly to programming tools for programmers and to frequent program communications. Installation is neither exclusively for programmers nor is it frequent, so don't be afraid to explain installation issues to users at length. Your users will thank you for it.

Not informing you of the scope of your actions

A typical installation program wastes no time on what a programmer considers idle chitchat with the user, but that chitchat is important to dispel the user's uneasiness. Imagine if an appliance repairperson arrived at your house and, without a word to you, started wrenching apart your plumbing and dismantling your refrigerator. You would feel much better if the repairperson gave you the big picture first:

The compressor on your refrigerator is completely dead because the motor has seized. I will have to replace it completely. I have the replacement motor in my truck and it will take about an hour-and-a-half to make the repair, including recharging the system with coolant in an environmentally friendly way. Your warranty will cover the cost of the parts but not my labor. I charge $45 per hour. The plumbing will need some minor work because the icemaker is directly connected to your pipes. Anytime existing iron-pipe plumbing is disturbed, there is a slight risk of starting leaks elsewhere in the system. I will make every effort to keep the pipes from moving to reduce that chance.

You are now informed of how much time the operation will take, how much money it will cost, and what the risks of failure are. You are aware of the scope of the operation. Wouldn't it be nice, then, if our install program told us something like this:

I am going to install MicroBlitz PIM-Meister on your system. This means copying the program from the distribution CD onto your hard disk, decompressing the files, and then configuring the program for your specific needs. Judging from the speed of your processor, I estimate the entire process will take about 7 minutes for a full install and as little as 2 minutes for a minimal installation. The program will occupy between 45 and 124 megabytes on your hard disk, depending on which configuration you choose. In other words, it will take between 2.7 and 4.7 percent of your total capacity. Your disk is currently less than half full, so the available space will be reduced by 4.6 to 8 percent.

I will place all parts of the program and all associated information in a special directory that I will create new. You will be given the choice of where that directory is located and what it will be called, but you can also just keep the default of PIM-Meister. By necessity, I must make at least one entry the Windows Registry. This entry will be restricted to a single parameter line that will have absolutely no effect on the operating system or any other program, even if you later decide to uninstall PIM-Meister. If you select the check box, I will also create an icon for launching PIM-Meister in the Programs folder of the Start menu.

This installation program maintains an internal status log so that, in the unlikely event it crashes, it will know how to pick up the pieces intelligently if you merely rerun it.

You can uninstall this entire program at any time simply by pushing the Uninstall button. The program will be removed from your system, leaving as few traces as possible, but leaving any data files you created with PIM-Meister untouched. If desired, you may request the space-saver uninstall, which means the program is removed but all your personal settings are saved. A subsequent execution of the install program can put PIM-Meister back exactly the way it was.

This monologue is prolix, and experienced users won't want to read it. But new users will find it very reassuring to hear what the implications of the installation process are. They will be happy to understand the scope of the process they are about to undergo.

Asking you questions to which you are unlikely to know the answer

An installation program may ask the user to specify the desired serial port. Most users don't know what a serial port is or how many they have, let alone which one is best for this program. Game and sound card installation programs frequently ask users about available interrupt vectors, a question that can't be adequately answered by most computer engineers, let alone a typical home user. Business software installations can be expected to ask about network support and the type of mouse in use. Most users have no idea what to answers to such questions.

It's a bad idea to ask users questions that they can't answer. First, it doesn't get the program the answer it needs. Instead, it gets a guess. Second, it makes the user feel bad — he just proved himself inadequate in front of a machine. How embarrassing!

If the program needs to know about serial ports, it should test them and see which ones are occupied. It can search in various configuration files for clues as to how they are currently being used. It can even ask the user to move the mouse and look for activity on the various ports to eliminate that possibility.

If the program needs to know about interrupts, it can examine them or listen to them to determine whether or not they are in use or available. The installation program can make a very good guess (and probably a much more reliable guess than the user's) about what interrupts are available by deduction and by looking at system information files and the registry, if there is one. By recording its findings and then telling the user it is about to do something that might lock up the system, the user can close all other running programs and be prepared for the program's error. If one occurs, he can then rerun the program, and it will find its earlier notes. It now knows what didn't work, which should be enough to enable it to deduce the correct choice. Don't force this choice onto a user who cannot be expected to know the answer.

Asking you for answers it can determine for itself

This is a common problem in all software, but the authors of installation programs are deservedly notorious for it. The program asks you what type of display device your computer has when it can easily check the system for the answer to that question. The program asks you how much disk space is available when it can interrogate the file system to get the exact answer. The program asks you where another program or file is located when it can easily search the disk to find it. The program asks you which hard disk you want to install on when you only have one hard disk.

The computer's job is to remove unnecessary trivia from our lives. Questions like these only add more pointless trivia and are offensive. Most information needed by any program can and should be determined without asking the human user.

Not doing its homework

One of the most obnoxious ways an installation program can misbehave is not being aware of its own existence. The installation program blithely installs an identical copy of a program that already exists on the disk. Or, it doesn't know that it is being used just to change a configuration, so it copies files from CD to hard disk that are already there.

The designer of an installation program should write a list of all the environmental givens that the program needs, including such things as RAM, video, disks, microphones, joysticks, mice, modems, or speakers. The installation program should then check that these assumptions are indeed true before proceeding. The program should perform a common-sense examination of the system before it starts working. It should look for previous copies of itself; it should look for other, required software; it should check for fatal or dangerous conditions like lack of memory or disk storage.

Most intermediate users make some attempt to configure and personalize their sovereign applications to make them more convenient. It is very frustrating when an upgrade for that application ignores those personalized settings. Many business executives get a new computer every year or so and then find that they must painstakingly recreate their settings by hand for each major application they use. A good installation program should know how to import these settings from other computers, as well as other versions.

Not providing a means for uninstallation

Although many software vendors seem unaware of the fact, customers often want to remove software from their computers. A customer might remove software because it is needed on another computer, because it is not needed on this computer any longer, because it takes up space needed by other more important programs, or because the user has decided that the program is not good enough to keep. Every vendor should provide a tool for removing its program, just as it provides a tool for installing it. The uninstaller should be just as robust and full-featured as the installation tool. It should follow the principle of informed consent, telling the user what the scope and consequences of the program are. The Add/Remove Programs control panel and the Program Registry provide this functionality on Windows, provided that the application has properly installed itself. Program installers also can provide this functionality, as shown in Figure 36-2. Apple, for some reason, has never understood the importance of uninstallation: It is still an onerous manual process on the Mac.

Figure 36-2: A good installer is aware of the fact that its software has already been installed and offers maintenance and removal functionality if it is launched under those circumstances. This installer could be a bit more helpful in providing useful information up front, like which files are installed and where, how much space is taken up by them, and how much is available. (This information is shown on later screens, but users need it early to make informed decisions.) Mostly, however, this installer has the right idea. InstallShield's wizard at least gives users the ability to retrace their steps or cancel if they decide they don't want to go through with an install or uninstall.

It is reasonable to assume that the user does not hate your program but is removing it because he merely wishes to regain some disk space by removing a no-longer–needed tutorial or some subsystems that have proven unnecessary. Uninstallers should give the user the ability to remove individual pieces of her program without affecting the main function of the application. The user may also wish to move the application to a different hard disk or to a different place on the same hard disk. The uninstaller should know how to make the transfer so that all references are updated and the program works smoothly despite the transition.

If a user needs to temporarily reclaim the space on disk occupied by the program (say he needs additional free space for a two-week business trip), the uninstaller should make this easy to do. It should remove all the big, space-consuming files but leave behind all the directories, configuration files, and entries in other system files. When the user returns from his business trip, the installation program can be used to put the big files back on his disk without overwriting or forgetting about his personal settings. The program would be reinstalled just as before.

Some programs such as networking, peripheral drivers, and printer-sharing software are not only installed on the hard disk, but are also activated by files at boot time, thus becoming a permanent part of the operating system. Software like this makes a special demand on its uninstaller. The uninstaller must be able to disable the program without physically removing it. If the user wants to, for example, run a game program that demands absolutely all available memory, the user should be able to disable the network drivers for the duration without physically removing them from disk.

Ignoring evidence of its previous activity

Installation programs should keep a log of their activities on the user's hard disk. This log tells the program what it has done before and what it is doing now. If the program learns anything from a previous execution, either by testing the system or by asking the user, it should be recorded here so reprocessing can be speeded up and the user doesn't have to be bothered again. The installation facility for Windows has this SmartRecovery feature. Installers should also know when their software has already been installed and offer uninstallation and update options if invoked under those circumstances (see Figure 36-2).

Abusing system-wide files

Windows applications should limit themselves to no more than two or three entries in system-wide facilities (such as the Windows Registry). If the program needs more information, it should create its own initialization file(s) and store the information there.

Putting files where they don't belong

The application should operate in its own directory. If it requires multiple directories, these should be made subordinate to the program's main directory. The program should never put files in other directories, unless required by the particular platform (for example, extensions on the Mac). Otherwise, if the user were to install a new version of the OS, the application's files might be deleted in the process. The resultant malfunctioning and confusion would be very unpleasant and completely avoidable.

Application programs often ignore the possibility that the operating system will be reinstalled or upgraded. The program is often inextricably dependent on entries in system files that, when the OS is reinstalled, will disappear. Most programs then require a complete reinstallation, including redundantly recopying the files.

Although all a program's supporting files should be placed in that one directory subtree, this is not necessarily true for the data files it creates. It is good practice to keep program files and data files separate, and the install program should begin with that assumption. Current practice in many Windows programs is to put all data files in the My Documents folder. The intent here is good, but when dozens of programs all put their data files in this one directory, chaos ensues. It would be much better if a program's data files were stored — by default — in a named subdirectory under My Documents instead.

Overwriting shared files

Many applications use runtime libraries of some sort. Visual Basic applications, in particular, use the VBRUN dynamic link library (DLL) and usually a few VBX or OCX DLLs for each of the installable controls used in the program. When a program installs the DLL or VBX, it may overwrite one with the same name already installed by another program. For example, if program A uses a commercially available VBX grid control named GRID.VBX and program B, from another vendor, uses a proprietary VBX grid control that is also named GRID.VBX, the installation process will cause problems. Even though the names are the same, the functionality and interfaces may be quite different. When program B is installed, it must ensure that it doesn't just overwrite the GRID.VBX file by assuming that it is an earlier version of itself. If it makes this assumption, program A will crash violently and mysteriously. The ensuing confusion will leave the user perplexed and angry.

A similar problem arises if two different programs use different versions of the same DLL. Imagine that both programs A and B use version 1.0 of a DLL called DATBASE.DLL. The user then purchases the newest release of program B that includes the newest release of DATBASE.DLL, version 2.0. The installation program for B likely assumes that it can blithely replace version 1.0 of DATBASE.DLL with version 2.0. But program A won't know how to deal with the new version of the library, and a crash is unavoidable. Crashes like this are particularly insidious because the user could install the new release of program B in January and not get around to running program A until June. He will have no clue as to what caused the problem. If anything, he will blame the completely innocent program A. Because this problem can affect any vendor, even though the vendor is not strictly at fault, it means that you must take defensive action to keep the problem from happening to you.

The problem can be avoided by following two simple guidelines. First, use names that aren't likely to collide with those from other vendors. Instead of naming a library GRID, try using XGRID, GRD or even G7QL. The user will likely never see these names, so they don't have to be mnemonic. Second, append a unique number indicating the version of the library. Name the first release XGRD1, the second release XGRD2, and so on.

Not offering you any information about the program

The installation program should keep the user informed at all times of what it is doing and what remains to be done. Contemporary installation programs put a dialog box on the screen with a small completion meter showing the amount done expressed as a percentage. Most of these meters are frustrating and confusing, however, because they don't adequately explain what they are representing. Does the meter show the progress for this file? This section? This CD? The entire installation? Is it expressed as time or as bytes copied? Users have become used to being burned by meaningless meters, and they know enough to ignore them. They know that the installation program is just being obscure.

Confusing installation with configuration

Because most programs need some rudimentary configuration before they can run well, the installation procedure usually includes a configuration step. This is reasonable, but the configuration process may need to be performed more than once, whereas the copying of files from the CD is usually a one-time operation. Installation designers frequently forget this and intertwine the two processes so that a reconfiguration cannot be done without an unnecessary copy operation. The installation program should be smart enough to recognize that it is being rerun and offer the user the option of just reconfiguring the existing instance of the program without incurring the entire overhead of recopying.

Demanding your active participation

Some installation programs make unreasonable demands on your time and attention. They require that you actively participate in the installation process, even though you would just as soon delegate the job to the software. The WordPerfect for Windows installation program, for example, interspersed questions for the user with the actual copying of the program onto the hard disk. In other words, it asked you a question, then installed a few files, then asked you another question, and then installed a few more files.

Thus you are forced to consciously baby-sit the entire process. Installers should ask all relevant questions at the beginning and then let the user get up and walk away while the installation proceeds. It should also issue an audible alert if a new CD needs to be inserted, releasing you from having to watch the screen.

Far and away, the best install process is one that demands no user involvement whatsoever.