Foundations: Installation

This is the last of my planned articles in the Foundations series.  If I think of anything else I think is important I will add new articles, and if you have any ideas for other aspects of world class software you think should be included, feel free to email them to me.

I've already done a short rant on software installation, but this time I want to go into more details and give some background on why I think people tend to get it wrong so often.

Why Is It Hard?

Writing an installer is taking on the compatibility matrix head-on.  For each Operating System, each version of each OS, and in the Windows case each Service Pack for each OS, the installer is the first code to run on the computer and is responsible for doing all the nasty work necessary to make the rest of it work correctly when it runs.

One example of a difference is a program that targets Windows 2000 and higher.  Would it be acceptable if the installer failed to run on Windows 98 SE just because the program doesn't?  So now extra work needs to go into the installer to make sure it can run (and is tested) on operating system versions that the program specifically doesn't run on so that it can give a clear, informative message to the user explaining why the installation won't proceed.  All the rest of the code of the program can assume that everything that was part of Windows 2000 Gold (the original version that shipped on CDs) is available without further checking, but the installer doesn't have that luxury.

Another installer for a program that works on both Windows 98 SE and Windows XP has even more work to do.  Fundamental pieces of the OS are different, and the installer is the first and most important piece of code that has to be able to handle those differences correctly.

User Centric

Most installers are technology centric.  By that I mean they're driven by the technical requirements of copying files onto the target computer, registering COM classes, doing a tap dance in the registry, and creating shortcuts everywhere the developers could think to do it.  The questions they ask users tend to be irrelevant or the wrong question.

For example, how many installers ask the user for the path to install to?  How many of their users actually choose anything but the default?  So they're usually using an entire screen with too much information on it for a purpose a small minority of their users will want to use.  Now, here's the kicker:  Of those users who do choose something besides the default, how many of them just want to put it on a different drive?  If you simplify the operation to what most users want to do, you could have a much simpler dialog with a big selector for the drive and an 'Advanced...' button for those who really want to muck with it more.

Wizards have their place, but mostly what people want to do is have two buttons:

1. Install
2. Cancel

Advanced users who want to get more finicky about the process will want button #3: Advanced.  This is where they can tweak all the settings they care about before finally hitting the 'Install' button.  For power users, being able to save those settings to a file (like an XML file...) and load them in another install would be keen.  With Group Policy software installation domain administrators can do the equivalent of this, even more painlessly.  Most applications that will or could be deployed in a corporate environment should have a high level of support for it.

Categorization

I covered this topic in some detail in a previous article, but the basic idea is: install based on helping the user categorize, organize, and find their software.  Not on what will put your icons in their face the most often.

Entry Points

Some users want shortcuts on their desktop, some might even want your application's shortcut on their desktop, but the default should be to not litter their workspace.  If they check a box in your installer saying they want it, great.  That may be how they work.  Don't litter by default, but let the user tell you how they like to work.

Uninstall and Clean-up

Allow an easy, straightforward uninstall.  Completely clean up after yourself.  If you have interesting user settings, add a setting for the uninstaller to determine whether or not to leave those user settings alone.  This allows the user to reinstall later and preserve those settings.  In the interest of considering user data sacred, the default should be to preserve and let the user choose to let the uninstaller wipe those as well.

ARP

All applications should be properly listed in the Add/Remove Programs control panel, and the information should be correct.  Be verbose about the support information, and correct about the total install size.  Consider these areas where Windows displays information about your application to be part of your application, because they're aspects of how the user interacts with your product.

Repair

Have a 'repair' option for your installer and make it work as well as you possibly can.  Put the effort into making it smart about getting your application back to a usable, reasonable state from any starting state.  You should never have to tell someone to uninstall and reinstall your application, repair should be the easy answer from any kind of file corruption, setting issue, deleted files, etc.  First line of product support should be able to quickly determine the nature of a support problem and their answers should either be education or using this repair option (if it is done perfectly).

Administrator Privs

Be very careful not to require administrator privileges for installation, and put extra effort into avoiding it.  Most applications don't need it, Power Users at a minimum should be able to  install most software.

Auto-Update

This is a feature that has proven hugely successful for Windows and is becoming more and more common for many applications.  Sometimes it is automatic, sometimes it is a Help menu option, and sometimes (especially games) it happens when you try to connect to a server.  My thoughts on this:

1. It must be opt-in.
2. It must be coded in such a way that information is downloaded, not uploaded, to determine whether things on the local computer are out of date.
3. It should be as automatic and schedule-able as possible.
4. There should be no UI required external to the application.  For instance, it is lame to bring up a web page that the user must then click around on to start a download, and then manually close the app and run the installer.
5. The update should feel seamless, at most requiring an automatic restart of the application (don't make the user restart it themselves).
6. Communicate the changes for an update effectively.
7. Have a mechanism for undoing the update so users who run into compatibility problems don't hate you.

For me the ultimate auto-update experience is to be able to opt in to automatic updates, have them download when I'm asleep and completely unaffected, install without my intervention, and my application gets better and better over time.  If I do run into an issue I can easily determine what updates have been installed recently and undo them in reverse order until I see the issue is gone, and I can automatically report the issue I had so the application vendor will yank the update, fix it, and then put it back when things are fixed.