A general algorithm for installing software goes something like this:
Let's review each step in detail.
Installation Data Collection and Precondition Verification
In this step you collect all data needed in the installation. I really mean all. There's nothing worse than starting a one- hour installation process, walking away for lunch , and then returning to some subcomponent holding up the entire install by asking a minor question, with 50 minutes still to go.
To help make certain you're getting all the data, ask your technical publications department to create a simple form that captures all of the necessary information in writing. An even better approach is to capture all of this information in a file for future reference by your customer and your technical support group . Augmenting these forms with case studies of installations on common configurations is also helpful. Ask for all vital configuration information and important customization data, including where the product should be installed, database connection strings, proxy servers, and so forth. Storing these data in a file enables you to easily support corporate installation environments, because you can use this file as input to mass installations.
Once you've collected the required data, verify as much of it as possible before you begin the actual installation. Don't start the install until you know that everything works. Your verification activities should include any or all of the following.
Although storage systems continue to make astonishing leaps in capacity, ensuring adequate free space is still very important. It doesn't matter if you're installing into a PDA, a cell phone, a laptop computer, or a server farm. Make certain you have enough free space for the target application, its associated data and working storage, and enough "scratch" space for installation.
If your software requires any connections to other entities, check them before you begin the actual installation. I've gone so far as to create installation precondition verification programs that simulate database or external internet server access to ensure that the provided connection information is accurate. I've put the installation process on hold until a valid connection was established.
Configurations of Required Entities
If you're relying on a specific database to be installed, you're probably also relying on it to be precisely configured for your application. One of my teams spent quite a bit of time debugging a nasty error in which our software wouldn't run on SQLServer. The root cause of the error was an improper SQLServer installationthe default collating sequence was the exact opposite of what our software required! Had we checked this setting before installation, we would have saved a lengthy debugging session.
Operating systems with sophisticated rights administration capabilities often restrict the modifications associated with installing software to users with appropriate administrative privileges. This is entirely appropriate when software is being installed in an enterprise. Whether it is a server or a desktop, enterprises have a legitimate right to know that the person with the proper training and authorizations is making changes. Unfortunately, what works well for organizations doesn't work nearly as well for end users, who can become confused when installation programs ask for certain kinds of permissions or fail entirely because of inappropriate access rights. While there is no easy or universal solution for the challenges associated with managing access rights, an awareness of the issue can help you choose approaches that minimize the requirements for privileged access.
Now you can begin the actual installation, which might be as simple as copying a few files to the proper locations or as complex as reconfiguring several system parts . Here are some things to consider during the installation process.
Provide Indication of Progress
The user needs to know that the installation is proceeding. In common end-user applications, this is usually achieved through a progress meter. In complex enterprise applications, this is often achieved via a command-line user interface. In either case, provide some form of feedback.
Provide a Visual Map
Very complex applications organize the installation into steps to give users a form or a map on which they can check off the completion of major activities.
Track Progress in a Log File
Log files (see Chapter 14) are useful for recording the operations performed and the actions taken during installation. They make recovery from installation failures as well as subsequent removal of the installed software substantially easier. At the very least, your customer/technical support personnel will know what happened . Don't forget to capture user responses to questions raised by the installation.
Make Installation Interruptible
With many enterprise application installation processes it is assumed that the installer, usually an IT system administrator, is going to be devoting her full and undivided attention to the installation process. This is, at best, wishful thinking, as IT system administrators are extraordinarily busy people. Instead, I recommend that you create your installation process with the expectation that it will be interrupted at least once.
This perspective is invaluable in motivating the team to choose interruptible installation options. The best way to do this is to make the installation hands free. That is, after you've gathered and verified the information you need to install the software, everything runs without intervention once it has been initiated. The next best approach is to make the installation process self-aware, so that it can monitor its own progress and restart itself at the appropriate place as needed. You can also provide an installation checklist that tracks each step or explicitly breaks up the installation process into a series of smaller, easily performed and verified, steps.
Follow Platform Guidelines
Most platforms have specific guidelines on designing your installation process/program. Learn them and follow them.
Avoid Forced Reboots
If you must force the user to reboot, give them a choice as to when.
Avoid Unnecessary Questions!
If you can resolve a question or a parameter setting at runtime in a reasonable way, do so! Often the person responsible for the installation is doing it for the first time and so they are probably not familiar with your program. Asking unnecessary or even esoteric questions ("Would you like your database indexed bilaterally?") is therefore, useless at best, and harmful at worst, to your system operation. It is far better to pick sensible defaults that can be changed later, after the user has gained appropriate system experience.
If you must ask the user a question, make certain they have sufficient reference material to understand it, the effect a particular answer might have, and whether or not the answer is inconsistent with answers to other questions. Since many people simply choose the default answer, make certain your defaults really are the most reasonable values.
Installation isn't complete until you've confirmed that it was done correctly. This may be as simple as verifying that the right files were copied to the right locations or as sophisticated as executing the installed software and invoking any number of manual and/or automated tests. Unlike installation precondition verification, which focuses on the context in which the software is installed, postinstallation verification should focus on actual system execution. Is it giving the right results? If not, why not? Make certain you log the results from your postinstallation confirmation, so you can use them to resolve any problems.
Once the installation has been verified, clean up! Many installation programs create or use temporary storage. Some do a poor job of cleaning up after themselves . Set a good example and clean up any files or modifications.
Now that things are working and you've cleaned up, you can do other things to enhance your product's usability. Consider the following.