As a reviewer of software products, I am disproportionately exposed to the installation process. I install lots of products. Alas, it is poor practice in a review to complain about installation, because it's a factor that the end user will generally perform once or twice. And so whether it's hard or easy will likely have little effect on the purchasing decision. So, readers don't want to hear about how hard I worked to get the software up and running. They do want to hear about problems encountered after installation, not before.
Because installation falls in a no-man's-land, where doing it poorly is rarely a cost and doing it well is rarely perceived as a gain, most software packages do it poorly. The list of poor practices is so long, that I can't do it justice in a single editorial. But it's long past time that companies started covering even the basic issues:
- Every change to the system performed by the installation should be reversible by the uninstall script. This is particularly true on Windows systems, where products have no qualms about associating file extensions with their software, littering the register with their keys, adding unexplained directories in various parts of the user's home space, and leaving behind this detritus after the software is uninstalled.
- Environment variables should be set sparingly, with the needs of the user in mind, and they should removed by the uninstallation process. The offense most commonly seen is the change to the execution path. Many products still prepend their favored directory to the head of the path, rather than putting it at the end. This approach runs a high risk of causing unintended problems in the event that a vendor's binaries collide with the name of some other utility on the system. If the vendor is lucky enough not to use binaries with names that create a conflict, then they should be just as happy being at the end of the execution path, so as to minimally affect the user's system.
Now let's look at an area that is often neglected: installation wizards. These supposedly user-friendly little apps are generally designed by experts in the software who cannot view the wizard's contents through the eyes of a first-time user's eyes. Frequently, features will be described by their internal name and given that many wizards have no meaningful help systems (actually, many have no help option at all), they force users to consult PDFs on other media. For example, a checkbox with the words "Install CJK fonts" is the kind of thing I have in mind. As "CJK" stands for nothing more obscure than "Chinese, Japanese, Korean," why not use the non-jargon name so that a user can know right away what to do. (It might be argued that users in those Asian countries would know what CJK fonts are, but that's no help to users who don't live there and still have to decide what to do.)
The place at which installation dialogs become truly ridiculous, however, is the approval of the license. The text box is invariably tiny and the experience of reading the undersized print so maddening that you cannot but feel that what the vendor is really communicating is: "Don't read, just approve." Nowhere have I ever seen a license consisting of a summary of the entire license with a link to the full text should the reader care to look at it in detail. Yet, there'd be no harm in such a friendly approach.
Timing is another problem that occurs, particularly with the installation of updates: The delayed information that the installation requires rebooting the system. This lack of important communication is more of the notion that "my vendor stuff is more important than the stuff you're already doing." In the case of new product installs, the delay is more likely the result of the vendor's concern that the knowledge of the need to reboot will lead the user to delay installation. But the right solution can hardly be to induce the user through ignorance, and then spring this option whose need was known all along.
And after booting, has the installation started running a new service in the background? If so, this should always be explained to the user during the initial installation so that intelligent choices can be made. The condescending view that users cannot be expected to understand the implications of running a service in the background comes from years of explaining nothing at all. Many wizards today have the option for a custom installation, which self-identifies users who are likely to be advanced and to whom such concepts can be presented and explained.
Given the long tradition of hostility to the user needs, it's tempting to think that you just have to live with what you get. But market forces actually do occasionally take installation difficulty into account. Consider, for example, the success of the CI server, Hudson. When Hudson first came out, it was one of numerous competitors in the low-to-mid-range CI server realm. It faced entrenched competition in products such as Cruise Control — an excellent, widely respected, open-source CI server. Within two years, though, the field had consolidated around Hudson for one primary reason: It was drop dead simple to install and get running. It ran as a JAR file. So installation meant copying to a directory of your choice and running the JAR file. When Hudson opened, you pointed it at an Ant file and answered a few questions about which directories to use. After that, Hudson was ready to run CI jobs without further configuration.
Few packages have so deeply understood the need for simplicity and been so richly rewarded for it as Hudson. We're starting to see a bit of a return to simple, non-disruptive installation in mobile apps, which seem to avoid many of the problems I discuss above. But they achieve simplicity in large part because they generally perform one task only. If they recall Hudson's success as their complexity (inevitably) grows, we'll be in good shape. Now, all we need is to get desktop and, especially, server apps to get on the same bandwagon.