Channels ▼
RSS

Design

Installation: Where Software Remains in the Dark Ages


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.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video