Peter Seebach ([mailto:crankyuser@seebs.plethora.net?cc=&subject=All I want is a quick, easy install] crankyuser@seebs.plethora.net) Freelance writer 5 May 2004
application that a user sees, why is software installation such a notoriously buggy procedure? This month, in The cranky user column, Peter chronicles the ups and downs of installation, from the golden era of the floppy disk to the rise of the standard installer. He also offers some user-centered advice on building installers that work the way users want them to.
Users have been installing programs directly onto computers for a long time now. Once upon a time the only software on your hard drive was the OS; external application programs were accessible only through distribution media, typically a floppy disk. But, the addition of internal storage brought the possibility of storing applications directly on the computer, where you could get at them whenever you wanted.
Early Mac systems enshrined the simplest installation procedure ever: just copy the program to the hard drive. You would click on the application icon, drag it into your hard drive, and the Mac OS would take care of the rest. The Mac's handling of resources allowed crucial supporting data to be part of the application's main file, making this installation method viable for most application software.
Some programs required more support files, though, which complicated the installation procedure. Generally, you would just have to drag an entire folder to the hard disk. But if the program came on two disks (not so uncommon in those days) you might have to copy files from both disks to the same place. This led to confusion and error, which gave rise to finding a better way.
Enter the installer. This was a special program that installed all the bits of a program correctly for you. The installer would copy one disk and then prompt you for the next one. It would copy files into the right folders. It would tell you when installation was complete and instruct you to restart. The installer did everything. In theory, the installer should have made life easier for end users. It should have been the key to a veritable utopia, where everything could be installed with one or two clicks of the mouse. But it wasn't.
One rule of thumb in user-centered design is: Just because you can, doesn't mean you should.
The downside of installers is the same thing that makes them great: an installer can do nearly anything. No matter how complicated the installation procedure, the developer can safely assume the user won't see it. Unfortunately, this leads, time and again, to the compulsion to do something interesting. The worst expression of this compulsion is also the most common: the developer decides to modify the operating system instead of just running under it.
For example, it's cheap and easy to add system extensions, so a lot of programs these days require these (or similar modifications) as part of the installation procedure. In most cases, the extensions aren't really necessary, and in some instances they're downright irritating. Take the Macintosh version of the MYOB accounting package, for instance. MYOB requires a system extension to compress files. The file compression extension could have been left in with the application, or built into it, but it's installed systemwide. The program could save files uncompressed without the extension, but as it is you're left with no choice. As a result, if you upgrade your OS, you have to reinstall one part of the application separately -- and you can't make backups until you do!
But the tinkering doesn't stop there. Rather than install all the application files in a single directory, some developers install some of them in a separate, specially named directory. This makes it easier for future programs to overwrite files with incompatible versions, but it can also lead to excess baggage in your hard drive.
For example, the long history of 8.3 filenames on DOS and Windows systems means that many files are given terse and illegible names, even on modern systems where there's no name length issue to worry about. The System32 directory on my laptop contains 2,235 files. What's "nscompat.tlb"? I don't know. It was installed at 1:30 on February 10; I assume it's important. Three other files were installed at the same time. I don't know what they are, either. They were installed along with a video game, but its installer log doesn't mention them. For all I know, my System32 directory held a newer version and the game overwrote it silently. That happens a lot.
These days, every new application I put on my computer wants to tweak my OS to its own specifications. That is the reason that one of the most time-honored troubleshooting suggestions for both Mac and Windows systems is "do a clean install." Reloading the entire OS is sometimes the only way to fix mystery problems that you otherwise cannot debug. On the other hand, a clean install can create its own problems -- for example, if the system install puts in an older version of a core library that has since been updated.
Standard installers are a great solution to the problems I've talked about so far, at least in principle: application developers get an installation component for free and users get a standard, recognizable installation procedure. Everyone comes out a winner.The first standard installer I saw was on Commodore's Amiga; the company designed a very nice standard installer and encouraged everyone to use it. These days the standard installer on the Mac is pretty decent, and there are also some very popular third-party installers.
Many of the free UNIX systems have migrated towards package management systems. While closely related to the standard installers, most packet management systems aren't as friendly as the typical user might like. They tend to be light on support for anything more complicated than copy these files in, although this is improving with time. They also often lack a way to control installation features such as choice of directory or which components to install. If choosing which components to install means installing a separate package for each component, why bother?
On the plus side, packet management systems are largely automated, and thus hidden from the user. Competition and development among these systems is in full swing -- bad for users today but with good potential in a few years. You can look forward to the day when clear design features have been identified and standardized.
While most standard installers are pretty good, none of them are perfect. Many contribute to the same problems you see with widespread use of installers. The Mac OS X installer has a particularly nasty bug that deserves special mention. It destroys symbolic links (aliases or shortcuts, for you non-UNIX folks). If any file it wants to install is anywhere in a path that, at the beginning of installation, contains a symbolic link, the installer replaces the link with an empty directory. It does so silently, without warning, and you cannot disable this feature. As a result, a lot of developers who might otherwise use the standard installer (a big benefit for users, one would hope) are stuck using others, whether commercial or written in-house. Either way, users lose.
Even with the bugs, standard installers are a benefit to users and developers alike. The next step is to take these components seriously enough to debug them. If a platform's standard installer is relatively free of bugs, a user has little reason to learn other installers.
While considering the benefits of taking installers more seriously, I propose that all standard installers utilize self-containment. Self containment, inherited from the NeXT, is one of the particularly nice features on Mac OS X. Rather than store an application's installation data in a single database, OS X allows each application to be loaded as a self-contained file hierarchy containing all its associated files. From the user perspective, this is the same old installation procedure -- just drag the icon to your hard disk -- but the back-end results are far more organized and effective.
On the Mac, preference data is normally saved in a per-user preference directory (on OS X) or in the systemwide preference directory (on OS 9 and earlier). However, each application's preferences are stored separately. You can even delete an application's preference file if you want to; applications are expected to run correctly even if their preference files are missing.
Programs on a Windows system, by contrast, are supposed to store all their installation data in a single, centralized, often-corrupted database, also known as the registry. This technical decision can make managing Windows systems truly nightmarish. It's hard enough to keep a program and its preferences in separate databases, but separating the program from data it needs to even start running is awful.
A centralized file like the Windows registry is vulnerable to damage from any program. If it's damaged almost every program has trouble running. You can't reliably identify the preferences for a given program, since they may or may not have been stored in a likely area. The database is full of keys created for specific functions, even though you no longer need many of those functions. My laptop has hundreds of registry keys created to identify progress in restoring provided third-party software packages during installation. Chances are that no program other than the factory-restore CD will ever look at these keys, but they haven't been deleted. I have no way to find out what program might need them, so I just have to leave them there.
This lack of self-containment is one of the most persistent hassles to users. You know it's bad when you can't expect to reload your operating system without allocating an extra day or two to reload all your applications, find and reload all relevant patches, and so on. Self-contained programs, on the other hand, give users a great deal of freedom in installing and removing software without requiring special tools. (And it pays to remember that every special tool you need to perform a task is a possible point of failure.)
The fact is, your program has no business modifying my operating system. A system's OS should be modified with great care, if at all. Installers have become unnecessarily complex over the years. Most are trying to solve a number of unrelated problems at once, while they're often unable to perform their primary task reliably. The solution is obvious: stop trying to reinvent the wheel. Instead, invent a standard installer that's bug free and built using the best-of-breed features that are already out there.
This week's action item: Try copying an application from one computer to another. Does it work? Why not?
Peter Seebach is a freelance writer who's participated in the e-business game for years and just wants everyone to play fair. If you have comments, feel free to contact him at [mailto:crankyuser@seebs.plethora.net] crankyuser@seebs.plethora.net.