Chapter 14: Installing, Training, and Helping

Two of the major obstacles in putting out a highly useable software package are getting the software easily installed on the user’s computer and helping the user learn the software. For installing software, many software companies use a third-party installation program (such as Wise for Windows Installer and InstallShield). And some companies write their own installation programs.

For helping people learn the software, companies can offer training courses and online help. In this chapter, I talk about these three issues: installing your software, providing online help, and creating a training course. And as usual, all are under the realm of highly useable software.

Installing Your Software

Here’s a quick quiz in the form of an essay question:

Describe the software package your company is creating.

Unless you work for a company that creates one of the commercial installers (such as InstallShield), you probably didn’t say anything about an installer. You talked about what the software does, not how it gets installed on the user’s computer.

So why, then, do so many companies devote so much time to an installer? I know of a great many companies that refuse to use one of the commercial installers and instead write their own installer. A lot of these companies spend a lot more time on the software product itself than the installer (rightly so). But the installer is itself a software package that has its own usability issues and can be filled with bugs. Imagine if you have the best program out there, but your installer stinks and half the people encounter bugs and can’t even get your software installed! Or what if the people have to jump through major hoops and can’t get your software installed? If they do successfully get your software installed, a junky installer will not leave a good first impression in their minds.

What an Installer Does

At heart, what does an installer do? It copies files to the hard drive. If you’re old enough to remember the early personal and home computers that actually had hard drives, you’ll probably remember having to run various batch files that would simply copy the files to the hard drive, hopefully in their own directory. (However, I do remember doing some consulting for people who had no directories besides a root and kept all the files for all their programs in that main directory!)

But even if you don’t remember the simple install procedures from back then, you’re probably keenly aware that an installer simply puts the files on the hard drive. And that’s part of the problem: Installing software is actually much more complex and sophisticated than just copying files. If installation were simply a matter of copying files, companies that make installers probably wouldn’t need to exist. And further, how would you like to be told that the product you’ve been working on is trivial and something anybody could build? Certainly the people who work for the installer companies wouldn’t appreciate being told that, because they know just how complex their products really are.

Other than the fact that the installer packages are typically complex with sophisticated scripting languages, the final installer that you ship with your product does a great deal more than just copy files. Here are some things good installers do:

• Check for a previous version of the software and possibly uninstall the previous version, or ask the user for permission to uninstall the previous version. And if they’re asking for permission, carefully explain to the user the ramifications of the user’s decision.

• Create a directory tree to hold the new files, or in the case of a previously existing version, they might use the existing directory tree.

• Copy files into the directory tree and occasionally into the system directory. (Although I’ve made clear throughout this book my feelings about the system directory: Keep out!)

• Compare versions when attempting to copy a file but the file already exists.

• Update the Registry (on Windows).

• Register OLE and COM components (on Windows), again carefully tracking versions.

• Set up file extension associations (and ask the users whether to modify associations that already exist). And, as usual, carefully explain to the users why they might want the file associations and how they’ll be able to then double-click filenames in Windows Explorer to start up your program.

• Possibly create property sheet components that run when a user right-clicks a certain file in Windows Explorer.

• Optionally install icons on the desktop and add groups to the Start menu.

• Accomplish all this in a highly useable manner, following all the design rules that I’ve given throughout this book! (The installer is, after all, software in its own right.)

This list shows that creating a good installer is a lot of work. Are you really up for all this? To create a good installer, you really need to implement a complete software engineering cycle, using a sound methodology, just as you would do to create any good software. The installation program cannot be an afterthought. This means that where you were creating the most awesome application on the planet, you’re now creating two software packages, each being the most awesome application in its particular class. Do you have the time? Do you have the people? And if you have three more programmers, do you really want to devote them full time to your installer?

I think you’re getting my point here. Before writing your own installation program, please give serious consideration to purchasing one of the prepackaged installers such as InstallShield or Wise. If nothing more, consider the cost: You could have three people spending months on an installer, fixing the bugs and such, or you could purchase the installer program and have one person spend maybe two weeks on it, give or take some time depending on the complexity of your own needs. And remember, the installer is a part of your software package, and you will have to support it in the same way that you support the main program you’re selling. If you wrote your own installer and it crashes, your support team has to deal with it.

True, a third-party installer could crash. I think I once saw InstallShield crash. Once. And I went to their website and found that I had an outdated file on my computer. I got the new file and all was fine. But you know what? InstallShield took care of me. When I was installing your program and encountered this crash, I didn’t bother contacting you; instead I went to InstallShield for help.

But besides the support issue, the bigger issue is that word once that I threw into the preceding paragraph. I’ve seen InstallShield crash only once. Now I’m not being paid by the folks at InstallShield to say these great things about them (I’ve never even met them), so this isn’t some kind of commercial advertisement. I’m just pointing out that they have a pretty solid program, so why should you waste your time trying to top it? Remember, they have one up on you: They’ve been around for years. I first encountered them back in something like 1993, a decade ago. That’s a lot of time to work out the bugs. And InstallShield isn’t the only company that makes installers. Wise for Windows Installer is another fine program. Microsoft also ships a pretty decent one with its Visual Studio products.

In the following sections, I talk about usability and installation. I’ve already talked in previous chapters about installing libraries, dealing with version issues, and my own hot button about putting files into my computer’s system directory. So I won’t harp on those again. But I will say a few more words about other usability issues.

But I hesitate to talk about another issue, and that’s the if you insist issue. If you insist on writing your own installer, you will have some similar usability issues to work through. I’ve already made my opinion known about writing your own installer, but probably a few of you believe that your needs are somehow unique and that the commercial installers just can’t cut it. (I find that hard to believe, but again…if you insist.) For you cowboys out there, I will say this: The following sections apply to you as well. Whether you’re writing your own installer or not, you’ll still have to deal with dialog box issues that require good design and so on.

The Standard Choices

You’ve seen the three choices when installing software:

• Typical The most commonly used components in the package will be installed. (Note that sometimes installers instead have an option called Complete, where the entire package is installed.)

• Custom The user can choose which components to install.

• Minimal Only the components absolutely necessary will be installed.

For the first choice, if you’re going to use Complete rather than Typical, please really do make it complete. Install everything. Many times I’ve chosen Complete, only to discover later that a few esoteric libraries and help files were left off, and I was informed that I needed to insert the original CD when I tried to use those features. Because I had chosen Complete, I was a bit irritated.

Remember who probably uses Custom. That would be the power users. Beginners rarely use the Custom install. So the real question is, What do you use for the defaults under Custom? My personal preference is that when I choose Custom, and then get to select which options I want to install, I prefer to have everything selected initially. From there, I can go through and remove the options I don’t care to install. Remember, I’m a power user, and this isn’t a problem. Where I do get frustrated is when the Custom installation opens up with some options checked and some not. If this is Custom, why did somebody already choose some defaults for me? How do they know what I want to install and not install?

The Minimal installation is a bit tricky. Originally, I think developers included this goal for use on laptops and other computers with limited resources. But today, most medium-priced laptops are nearly as powerful as medium-priced desktops, and the laptops certainly have plenty of disk space. Instead, then, today some people expect the Minimal option to be for the beginners and novices who might not need all the extra bells and whistles. They might want just the basic features. They might not want all the additional templates or whatever you might offer along with your product.

But be careful with the Minimal install. If you are targeting beginners with Minimal, then the beginners probably want online help. Do you include online help in the Minimal install? Typically, install programs treat the Minimal install as only the minimal components necessary to get the application to run. If you’re shipping a word processor, this would mean no extra templates and clip art and translators and all that jazz. But what about online help? If Minimal is for beginners, then they’ll need the online help.

Personally, when I’m teaching courses to beginners, I tell them to go with the Typical option. The reality is that rarely will the Minimal option be good for the beginners. Beginners need online help, and they usually need components to help them get going, such as wizards and templates. Because power users tend to fill their hard drives a lot more quickly than beginners, most likely disk space won’t be a problem with beginners. Therefore, here’s what I recommend:

SUGGESTION

Consider not even offering a Minimal install option. Instead, offer a Typical option for most people and a Custom option for advanced and power users.

In your dialog box where the user chooses Typical or Custom, consider including some text explaining that the Custom option is for advanced users. (That’s probably a bit safer than the reverse, stating that the Typical option is for beginners. A lot of power users will opt for Typical, and you don’t want to insult them. Software insults people too much as it is.)

Some people offer another option, Run From CD. These days, with 80-Gig hard drives the norm, running off the CD isn’t particularly important. But some people might want it in case they’ve filled up their hard drive.

And in some cases, you might have another CD-oriented option. Take a look at Microsoft Streets and Trips, which is Microsoft’s very nice mapping software. That software came with a laptop computer I recently bought, and I noticed during installation that I had the option of keeping all the data on the CD, which would require that I insert the data CD whenever I ran the program, or of installing all the data to the hard drive. Now interestingly, the default was to not copy all the data to the hard drive. But if I have my laptop in the front seat of my car (no, I don’t use the computer while driving…really…trust me), the last thing I want to do is have to fiddle with inserting a CD into the computer every time I want to use the mapping software.

RULE

If your software includes a large data CD, give the users the option of installing all the data to the hard drive. With huge hard drives these days, that shouldn’t be a problem.

For what it’s worth, I just checked how much disk space my full Microsoft Streets and Trips installation takes up, including the data. The total is 872,004,297 bytes. That’s a bit less than a Gig, which is not a problem at all. (And also, the program runs faster off a hard drive compared to a CD!)

In the past, another Microsoft product, the MSDN developer CD, didn’t give you the option of copying the data to the hard drive. A company I once worked for ordered a copy for me, and I got tired of inserting the CD every time I wanted to use it. So I copied the whole database to the hard drive, but then I had to tweak the Registry. That was a bit messy, and I would have been happier if they had just given me the option to install the data right to the hard drive.

Reinstalling, Repairing, and Removing

Some installers give the user a repair option. When the user starts up the installer, and the installer detects that they’ve already installed the software, the installer offers to repair a current installation. The repair makes sure that all the installed files are present and makes sure that the Registry entries are all present and correct. If anything is missing or corrupt, the installer fixes the problem by either copying the missing or corrupt files or by adding or fixing the Registry entries.

Those Touchy COM Components

If your program installs various COM components (such as ActiveX controls), the notion of staying out of the system directory isn’t as clean as I might hope. When you install a COM component, you register it with the system. If some other program registered the COM component that you’re about to install, and then you save the component to your own directory, you could end up wiping out the previous registration and pointing the registration to your own copy of the component. Then when you uninstall, the other program will no longer function properly.

Further, if the other program runs, it doesn’t make a whole lot of sense to have the other program run a library that’s in your directory. (As a power user, I tend to get a bit suspicious if I check up on the libraries that, for example, program A is using and I see it’s using a library in another program’s directory, say program B. My suspicion is that program B somehow hijacked program A and is doing something it’s not supposed to be doing.)

For this reason, I’m probably willing to give a bit and allow you to put the COM component in the system directory under the specific conditions that you did not create the COM component or, if you did, you are using the COM component for several different programs that you wrote.

The repair option is important. Anything can go wrong; a user might accidentally delete a file, or the user might go mucking around inside the Registry and make a mess. And so you can save the users from themselves by offering a repair option.

However, I do recommend that you also offer a complete reinstall option. Sometimes I have found that repairs don’t always work. Typically, a repair option doesn’t go through and compare byte by byte every file with the original on the CD, and so the repair could potentially miss a few things. And for that reason, a reinstall option would be nice.

And, of course, you definitely need a remove (or “uninstall”) option. But always be extremely careful when uninstalling. The last thing you want to do is uninstall a system library that you thought was used only by your program.

Of course, this system library idea gets back to my assertion that you should stay out of the system directory. If all your DLLs are in the program’s own directory, you’ll have no problems with uninstalls. Simply remove all the files in the directory and don’t touch the system directory. Remember also to clean out the Registry entries during the uninstall.

Gathering Custom Options

The standard way to gather user options is by presenting a treeview control (or some variation thereof), whereby the user can choose exactly which options or components to install. Figure 14.1 shows an example of a Microsoft installation. This treeview divides the installation into various components, each containing smaller components. The user can choose entire sets of components to install or only individual subcomponents.

Figure 14.1: The options are available in a treeview-like component.

The options that Microsoft uses are, however, not very clear to beginners. The options allow the user to install the component to the hard drive, not install it at all, or keep the component on the CD and prompt the user to install the CD when the feature is needed.

The problem I have is that the beginner will probably be greatly confused over the difference between not installing the feature at all and keeping the option on the CD, installing the option only when it is needed. In fact, come to think of it, I’m not sure that I understand the difference. By not installing a feature, does that mean the feature’s menu item will simply not be present, making it impossible for me to attempt to use the feature? Or will the menu item be present? And what happens if I choose the menu item? (But this, of course, assumes that the feature is linked to a menu item.) Therefore:

RULE

If you decide to implement both “not install” and “install from CD when needed,” make sure you explain in detail to the user what exactly you mean by these options. Remember: Think clarity.

Different installation programs use different means to specify the options that will be available to your users. Go ahead and use whatever is available to you in your chosen installation program. The major installers are so common that these days you can’t really go wrong, provided you don’t start building your own dialog boxes.

Gathering User Information

In order to gather information from the user, your installer might have custom dialog boxes that you wrote. These are dialog boxes that extend beyond the standard dialog boxes the third-party installer software offers. If you’re going to be building your own dialog boxes, then, remember to follow all the usability rules for dialog boxes and controls.

In fact, I would almost daresay that the rules are even stricter with these dialog boxes than with the ones in application software. The reason is that you’re doing some pretty severe things here:

You’re installing files and possibly overwriting files that might cause another program to break. Therefore, when communicating with the user, you have to be extremely clear about your intentions, and you have to make sure the user’s intentions are extremely clear. Here are some examples of some unclear messages you might have in a dialog box or message box:

• File mystuff.dll already exists. Overwrite? This message would have a Yes button and a No button. This situation is clearly bad because the user has no idea what the implications are either way. If I say no, will the software that I’m installing work? And if I say yes, will some other program break? And what is mystuff.dll anyway?

• Overwrite myfile.dll (date January 1, 2002) with file myfile.dll (date January 1, 2000)? This variation of the preceding message would also have Yes and No buttons. And also like the preceding message, my response is, How should I know? I don’t know if your software can function with the newer version that’s already on my drive. The solution? Write your own version in your own directory, not the system directory.

• Cannot write file. Aborting. Come on now. If your installer can’t write the file, don’t just yell at me about it. Find a way to write it. I have plenty of disk space. Maybe you encountered a bad sector when trying to write the file. Well, figure it out and work around it. Don’t just give up, leaving me stuck.

• Any type of double-negative situation, even if the grammar is fine. Examples are, Are you sure you don’t want to install the coolfun library? followed by Yes and No buttons and, Would you like to skip the installation of the coolfun library? Both of these are unclear and better served by the replacement, Would you like to install the coolfun library? But see the following, because this isn’t perfect either.

• Would you like to install the coolfun library? Okay, fine. I have a choice. But what are the implications either way? Do I need the coolfun library? What features does it add? And what happens if I don’t install it?

RULE

Never leave the user wondering what to do: Clearly tell the user the implications of all installation choices.

And, of course, we have the issue of bad grammar and just plain confusing sentences. Are you sure you don’t want to not uninstall the library before exiting? is very similar to one I’ve actually seen (I’m not lying). If you struggle with grammar (which may be the case if you’re writing in a language that’s not your first), then please have a native speaker do a good copy edit on your dialog boxes and other text. (And this advice extends to your entire software package, not just the installer.)

And regarding the final option in the preceding list, if you get to the point where you are asking the user specifically whether to install a particular library, then you made a mistake. You shouldn’t be opening dialog boxes asking about specific options during the actual copying of files. Instead, you should have a general dialog box before the copying begins, whereby you gather all the user’s choices for what to install and what not to install. See the previous section, “Gathering Custom Options.”