Volume Number: 16 (2000)
Issue Number: 1
Column Tag: Getting it to Market

Software Installation

by Eric Long

If it absolutely, positively, has to be shipped overnight, then you probably should have considered your installer before now. On the other hand, if you began working on your installer six months ago, and have been tweaking it every day since, you've probably overdone it and have created an overwrought monstrosity, which no one but you may be able to work with later. Somewhere between avoidance and obsession is the happy medium, which should be the goal in the creation of a software installer.

How many times have you heard the phrase, "Keep it simple"? It's the mantra of UI. It's also the best strategy for creating installers. Keeping it simple means breaking the problem down into bite size morsels that anyone can swallow, not eliminating useful functionality. Many times, I have heard developers call or write and say things like, "My users are idiots. I have to protect them from themselves." In most cases, that's just not true. Most users are not idiots. Most are intelligent, reasonable people who can and will use great functionality intelligently if you let them. They may not be a computer geek like you, but they can follow your lead if you know how to lead them through it. (Granted, some users may be idiots, but it's a very small percentage) Don't judge your users by your worst tech support calls. Most users never make them.

Before you create a software installer, you should have a clear sense of what you want to accomplish with the installer. The purpose of an installer is to do its job in a straightforward manner that is convenient for users. It must a) install the right software for the right machine in the right places, b) provide the flexibility your users want to keep them happy, and c) not screw up the users system. An installer may also provide some aesthetic niceties like pictures and sounds, but niceties are secondary and are not the main focus of the installer. In fact, if all goes well, the best installers are the ones your users remember the least. After all, your users want your software, not your software installer.

Preparation is essential to development of a software installer, just as it is to the development of the software it installs. StuffIt InstallerMaker is the product I work with at Aladdin. Over the last year or so it has undergone serious changes. We've listened to a lot of feedback from customers in planning its development. My attitude through the process was to look at each need and ask, "How can we get there from here?" The same approach applies to building a software installer. Before providing the answers, you have to identify the questions. Below are some questions you should ask yourself before building an installer.

What needs to be installed?

This is pretty basic. What are the parts that you need to have installed? Most of the time you will have two classes of items: items that go into a main folder you install somewhere on the user's system and System items. You should create a components list identifying each item to be installed and where it is to be installed. This information is the foundation of your installer.

How will this installer be distributed?
Who will be the end users of this installer?

Your approach to an installer will be quite different, depending on the method of distribution you use and the end user of your installer. If you distribute an installer on CD, you can afford to include parts that may not be essential, but are beneficial for users. If you distribute online, you will want to trim down the installer, by removing non-essential parts. You may also want to consider using different compression methods. InstallerMaker supports a maximum compression method and a faster method for compressing items in your installer. The maximum compression method gives you a much smaller installer, ideal for updaters or other types of installers distributed over the Internet. The faster method provides faster decompression. If you are installing a large number of items from a CD, the faster method may fit better with your needs.

Knowing who will be receiving your installer is just as important as knowing how they will receive it. Different users have different needs. For example, you can not always depend on users having specific OS software installed. If you know the clients of your installer all have Drag & Drop, then you don't need to install it for them. On the other hand, if your product has some cool Drag & Drop enhancements, and some of your users may not have Drag & Drop installed, then you will likely want to license it from Apple and include it in your installer.

You may also have files that are useful only to a small subset of your users, such as users from a particular country. If these files are large or numerous, you may want to consider building different installers for different groups of customers. This allows you to simplify your installers and to avoid confusing your users with choices that don't apply to them.

Once you have determined what to install and where to install, you are ready to address the more precise issues of installing them:

Nothing is more annoying than installing an upgrade only to find that 32 items have been added to your System folder, half of which are extensions for PowerBooks (when you're installing to a desktop Mac) and five more are unnecessary for the OS version on your machine. Be considerate. If the machine doesn't need it, don't install it, unless the user explicitly requests to have it installed.

Another big mistake is to actually downgrade a user's system. Have you ever installed "SuperGadget 2.0" and suddenly found that the latest update to QuickTime, which you spent all that time downloading and installing, has been replaced with an older version deemed "compatible" by the developer? I'll bet your next move was to shout, "#$*@%!"

If the software you are installing requires a specific version of a component that you don't fully own, inform the user and let the user decide whether to downgrade. It's inconsiderate to play God with a user's system. If you do fully own the component, consider whether you really must remove an older component before deleting it. For System level items, you may not have a choice, but for other items keep in mind that your user may want to keep the old version around. Maybe he really likes SuperGadget 1.0. Unless your installer is explicitly provided as an updater, try to leave the user's existing software intact. If you want to avoid confusion, move the old items to a backup folder and name it "Old SuperGadget Folder." This is also a good place to put a copy of the user's original preferences file.

If you provide your users with an uninstaller to remove your software, take special care with System items. If you don't wholly own the component, don't remove it. Just because your installer installs the Text Encoding Converter extension, doesn't mean you can then uninstall it! The user may have several other products that use that extension. If a component you have installed is potentially included in other installers, even other products you fully own, you probably don't want to uninstall that item, because it might break something else.

Most installers have an all inclusive install package known as the "Easy Install." This is great for the user who doesn't know anything or doesn't want to know anything. He wants it simple; click, install, done. Many installers are small enough, in terms of the number and type of items they install, that no other package choices are needed or warranted. Those are the exceptions. Most installers could include package choices other than an Easy Install.

Creating Package Choices

Users really appreciate grouped packages of items to choose from for installation. This allows them some flexibility in choosing what is or isn't to be installed. To create custom install choices for your users, group the items you install into packages that you think your users might appreciate being able to install separately. This is especially valuable if your user ever needs to reinstall a particular component (disk errors happen, files get corrupted). It's really handy to be able to run the installer and grab out just the part you need to replace.

About reinstalling... applications like InstallerMaker allow you to assign conditions to determine whether a given item is installed. Version conditions let you decide what to do if an existing file is present before installing. You could choose to install an item only if it is newer than an existing item on the user's system. That would be wrong! You should always choose to install if the item is the same or newer. This way, if the user needs to reinstall, when something isn't working right, he doesn't have to know which component to remove before running your installer. If you only install when newer, the installer would never reinstall because it finds the same item already installed. The fact that an item of the same version is installed doesn't mean there is no need to reinstall.

Many developers fail to give much thought to providing a decent set of installation packages for users to choose from. Sometimes this is done in the name of "protecting dumb users." Sometimes it's just laziness on the part of the developer. The larger your installer, the more likely it is that your users would benefit if you sat down and worked out some groupings for them to choose from, for installation.

Here are some possible groupings you could use to setup your installation packages:

Easy Install

Installs everything the user needs. If you include FAT components, this package would install them FAT. Easy Install is the package that demands the least from users, however, if you go overboard making decisions for users automatically in this package, more experienced users will be forced to avoid the Easy Install. A balanced package provides some leeway, for the convenience of all users.

Easy Install for your Macintosh

Same as Easy Install, but strips FAT components for the target machine.

Minimum Install

Installs the minimum configuration the user needs to use your software. This may also strip FAT components.

Application Only

If you are installing a main application, give the user the ability to install only the application if desired. You might also include a read me to emphasize other components required by the application, in case the user has not installed other required components.

System Items

This includes anything you install into the user’s System folder. You could break this down into sub-packages of control panels, extensions, shared libraries and whatnot, linking together items that are dependent on one another.

Plug-Ins

If your installer contains plug-ins for your application, or other subsets of files, it’s nice if users have the option to install those items independently from other installations. This is also a good place to offer sub-packages so users may explicitly choose to install individual items from this group.

Documentation and other Support Files

This package would include your online manual, “Read Me’s” and other support files. You might want to include sub-packages so a user can choose to only install your “Read Me”, only install your “What’s New” document, or only install the manual.

Goodies

Maybe you have some extras you’ve thrown in for your users. Placing them here would give you some credit for the niceties you’ve added for them.

If you care about your users, spend some time setting up packages. They will really appreciate it. Yes, some users may trip themselves up playing with custom options, because they don't have a clue. When they call, just tell them to stick with the Easy Install. The majority of your users should not suffer because some lack an average sense of how to use their computers.

Safeguards are the things you do to your installer that users think very little about, but which concern you greatly. This can range from an obsessive drive for control over the installation process, to simply providing key bits of information to users, which enable them to make good decisions on their own, about installation. As the software provider, you don't want your users to get bit during installation. Your users are just as anxious not to get bit. There's a fine line between protection and domineering. Making the right decisions here will save you hours of tech support.

Here are some safeguards that are generally considered to be lame practice:

• Installer won't let users override minimum system requirements

If I want to install a CFM-68K application on my PowerMac, that's my business! At least provide a custom install option to install the files into a special "not for this system" folder.

• Installer only provides automatic installation choices when multiple reasonable choices exist

I might have a reason for having three copies of Netscape on my Mac. Don't just install a plug in without asking which copy to use it with.

• Installer automatically removes or makes incompatible all old components

There are plenty of installers that do not need to upset old files. If you haven't used SuperGadget 2.0 yet, you may want to go back to 1.0. It isn't too much to ask for reasonable preservation of some old files, particularly files that cannot be reinstalled because they are custom files created using 1.0.

• Installer forces a restart or calls for a restart when nothing that was installed needs one
• Installer needlessly quits all running applications
• Installer installs a main folder, which could be installed anywhere, but provides no choice to the user as to where to install it, instead it always installs to the root folder of the startup disk or another fixed location
• Installer modifies settings in files it doesn't own without permission

This list could go on an on. The point is that presumptuous installers are a bane to users. Don't inflict these behaviors on your users without providing alternatives to avoid them.

Here are some responsible and considerate safeguards:

• Don't advise users to boot with Extensions Off unless they really need to do that. In most cases, there is no reason to do this, unless your installer is hampered by virus protection software in some way
• Only quit all applications if absolutely necessary
• Provide helpful alerts that inform a user, before performing actions the user may want to know more about, or may want to cancel from doing

Example: Do you want me to switch your default Web Browser for you?

Example: SuperGadget is best suited for use on Macintosh computers with a monitor whose resolution is at least 640 x 480, which this computer does not have. Install anyway?

Note: This can get out of hand. Don't overdo it with alerts. Keep them down to only what's needed.

• Provide your users with concise descriptions of installation packages available to choose.
• Backup the user’s files when needed, or let the user decide if that’s something he wants to do
• Be careful not to install items into the active System Folder that are incompatible or unneeded
• If your installer downloads files from the Internet, let the user decide whether or not to continue before initiating the connection.
• Include an installation log to let the user know what the installer installed and other actions it may have taken, such as creating aliases, copying or removing files, or moving files to new locations
• Give the user troubleshooting information and contact information in a separate document included with your installer, in case the installer encounters problems or is damaged somehow

There are many more useful safeguards that can be implemented. Choosing the right ones for your installer will benefit both you and your users. You'll have fewer tech support problems and users will appreciate the care you've taken to serve their needs.

When it comes to installers, you can bet there's some tricky issues that will come up in the process. After three years working with InstallerMaker, I still hear about new issues on a regular basis. The demands and desires for installers are as diverse as the demands and desires for software. Most of the problems your installer will face are handled easily, but some issues take a bit more thought. If you find you've painted yourself into a corner, don't give up. Where there's a will, there's a way. Just keep asking, "How can I get there from here?"

Tricky problems become a lot less tricky as you break them down. When you encounter trouble accomplishing a task you have in mind for your installer, step back from it and ask yourself, "What do I really want to accomplish here?" You may be stuck simply because you've locked yourself into one approach to the problem. Look at the features of your installer making program and you will probably find that there are multiple angles available to address the problem.

Gestalt is your friend. Gestalt is a part of the Mac OS that lets you determine just about anything you would want to know about the Macintosh when your installer is running. Need to know if this Mac is running Open Transport? Does it have the Appearance Manager? Does it support QuickTime 4? These are all questions you can determine the answers to using Gestalt.

In InstallerMaker, multiple custom Gestalt conditions can be specified for individual archive items, installation packages, or even the whole installer. There are predefined conditions for many common system traits, like checking whether the machine is a PowerMac or has a 68K processor. You don't need to create custom Gestalt conditions for those. You use custom Gestalt conditions for special needs your installer may have which are not covered through standard conditions.

Use Gestalt selectors to identify specific information about the Mac on which your installer is running. Gestalt selectors are four character codes used to indicate the particular feature you want to know about on the system. In InstallerMaker, you can choose from a popup menu listing most of the available Gestalt selectors. Gestalt selectors can be set up and registered with the operating system by any program, so this is not a complete list. There are always more selectors. This list is drawn from selectors documented by Apple in the system header Gestalt.h. Jean-Pierre Curcio's freeware application Gestalt.Appl is a very helpful tool for gleaning information about Gestalts. You can find it online, or in the files shipped with InstallerMaker.

Once you have found the right selector, you can use it to make installation decisions in your installer, based on the results returned when querying Gestalt for the selector. In some cases, you may only need to check for the existence of the selector. Often, when a feature is not supported on a given Mac, the selector will not exist. For example, the 'otan' selector, for Open Transport, does not exist on Macs without Open Transport installed. (This would require that the proper extensions are loaded, however, as is the case for many system extensions that register with Gestalt.)

If this, then that, else the other thing.

No doubt, you will encounter the above situation at some point, if you get to build many installers. Some installation decisions aren't as simple as, "only install this on 68K Macs" or "install this only on Power Macs." Sometimes the decisions are "if there's a copy of Bleep 2000 installed then... else "move this, delete that, and copy those." InstallerMaker provides this functionality in the form of Install When conditions.

Suppose that you have a set of components you've created called, "Bleep 2000 Plug-ins." Now, maybe you also have a similar set of components for working with a different application your users may want to use instead of Bleep 2000. You call these components "Zoop Plug-ins." You could simply provide separate packages and let the user choose which to install, but ideally you'd like to have an Easy Install that handles that decision for users.

This is a classic "if, then, else" situation. There are a number of ways to deal with situations like these, some are easy, some take a little more thought.

InstallerMaker supports a number of tasks, which you can implement to help deal with problems like these, along with Install When conditions. Tasks are available to find items on a user's system, copy items, move items, delete, rename, or alias items. There are also tasks for downloading files, launching applications or opening documents or folders, displaying alerts, displaying pictures, and playing sounds. These provide the oomph you need to conquer complex needs.

MBED Word.Picture.8@Picture Captions:Tasks in InstallerMaker

Install When conditions in InstallerMaker let you impose a condition about whether an item is installed or a task is executed according to the success or failure of a previous task or find operation. You could, for instance, install a succession of items only if "Bleep 2000" is found on the user's system. Or, you could always install and just place the items into a folder where the user can access them later, when "Bleep 2000" is not present, or move them all to the "Bleep 2000 Plug-ins" folder if it is present.

Another important feature of InstallerMaker and other installer making applications is the ability to set the installation destination of items being installed to a location to be found at run-time, such as "where is Bleep 2000?"

InstallerMaker is optimized to perform disk-based searches for items based on the item's file type and creator type. If you want really fast searching of a user's drives, this is the ideal way to go. Additionally, you can reduce the effort your installer has to make by using the same search criteria whenever possible. When multiple searches are specified which contain the same search criteria, they are treated as one search at run-time.

All archive items in InstallerMaker archives can be set to use a Destination of "Find." The search criteria you specify becomes the location where the item is to be installed. When the Find fails, the item is not installed. Using Install When conditions, you can configure your installer to take other actions based on whether the Find succeeded or not, like displaying alerts, installing alternate files, or executing specific tasks.

Find is also used in file and folder based tasks, like Move tasks that allow you to move files or folders on a user's system from one place to another. All such tasks include a source location field for specifying where the installer should look for the item on which it is to act.

If the source item is not found, the task fails. You have default error handling options, such as aborting installation, reporting the error and continuing, or you can ignore the error and continue. You may also choose to preserve the success/fail status flag so that Install When conditions are not effected. The Find task type exists explicitly for setting the Install When status.

File and folder based tasks have both a Source Location field and a Source Name field. The source name field is left blank when the source location is the source item to be acted on, but if the source item is an item within the specified source location, the source name field is used to identify that item by name. You may also enter a full or partial path into the source name field. If the path is a partial path it will be resolved relative to the source location setting. If the path is a full path, the source location setting is ignored.

Display Alert tasks can also be used to set the Install When flag status to success or fail, based on the user's button selection from the alert. This allows you to give users some say in run-time decisions that may be important to them.

In some cases, while you are working out run-time decisions, you may find it handy to use the Temporary Items folder destination to put things. This folder is not visible to users and provides you with a workspace you can use during installation. Move tasks can be used to move items to other destinations, or you can use Delete tasks to remove items if they are no longer needed.

Where is it?
How many "its" are there installed?
How do I decide which "it" to use?

OK, you're still looking for Bleep 2000 on your user's system, only, "Surprise!" There's three copies installed! Now what?

Well, your user may just have a cluttered machine, or your user may have good reasons for having more than one copy. This is a good time to let the user choose the install destination.

This process is not too difficult. Find can be configured to prompt the user if multiple copies are present. At run-time, the user will be prompted by a display showing the copies of "Bleep 2000" found and where they are located. The user can choose whatever is best for them.

Updater chaining is what you need. This is pretty easy too. You can create updaters in InstallerMaker using the different versions of Acme Widget. Each updater is made by comparing an older version to a newer version. If you have nine different older versions, you'll need nine updaters. To get your users from 1.0 to 2.0, you'll create updaters using each successive version. First 1.0 to 1.1, followed by 1.1 to 1.2 and so on. In this case, you would probably be better off just installing version 2.0, but if your needs were more real-world, updaters could make your installer a lot smaller.

Once you have your updaters, you need to set the install destination to Find, specifying the criteria to locate Acme Widget (using type and creator is the most efficient method). In addition, for each updater, set the Find to look at the version of Acme Widget found. The first updater would only update the oldest version. If the copy installed is newer, that updater would not execute. Updaters following would only operate on the specific version each was created to update. In the end, only the updates needed are executed. You can use a Display Alert task in conjunction with an Install When condition to post an alert if no eligible copies of Acme Widget are found for updating.

Linking Installations

It is not uncommon for a software provider to have multiple installers for different components. The installer for the Mac OS integrates more than one installer into a single installation process for users. This is easy to do when you are in control of the various installers. Launch tasks can be used to run one installer following another. It gets much trickier when you need to run software installers that you did not create and cannot modify. It is difficult to launch them in order of need, and some installers call for a restart following installation. You don't want your user to have restart several times when only one restart is really necessary.

StuffIt Installer Linker[TM] is a nifty little application, included with InstallerMaker, that allows you to manage multiple installers and suppress restarting until the entire installation process completes. This utility will help you to manage this problem.

Installer making programs are powerful, useful tools, but you may have in mind some things for your installer that go beyond what they provide. If you like to register software before your user installs it, and want them to enter in a registration code and such, you will likely want to create some custom code for this purpose. InstallerMaker provides example code for product serialization, which can be used generically, but you'll probably want something a little more proprietary. If so, you will need to create an installer extension.

Installer extensions are code resources that execute during the operation of an installer. Custom code can be executed at just about any point during an installation, run prior to installation, or run following installation. These can be extremely effective, providing you with a lot of control over installation and allowing you to inject your own tricks into the process.

InstallerMaker supports code hooks that execute prior to installation, during package selection, before and after (and in some cases in the middle of) installing an item or executing a task, following installation, and at quit. Some extensions allow you to change installer settings while it is running. Some implement custom install conditions. You can also pass information between your code extensions using refCon parameters. Just about any place you would like to get a hand into, you can through custom code extensions.

After dealing with all of the technical issues your software installer will face, you'll find there's more than enough opportunity to slip in the pieces your marketing and legal people want in place before shipping. Standard installer features like startup pictures, startup text, software license agreement text, and custom progress dialogs are ideally suited for these needs. Your installer's startup text is also a good place to convey useful tidbits to your users prior to installation. Note, however, most users click past those screens with the speed of the space shuttle. If you want users to actually read them, you'll have to give them some visual flair, such as 24 pt bold text in red that reads, "Warning: Failure to read this document could result in acne, sharp intestinal pains, or death!"

In my experience, most installers I've seen simply use the default installation progress. This is perfectly fine for installation. It's nice and functional. But, if you have marketing or PR goals in mind, this is a place worth taking advantage of, because it is shown to the user throughout installation. All you need is a custom picture. Modify a couple of rectangle specifications in ResEdit, and you're on your way. A custom progress screen can really shape the feel of your installer and personalize it for your company or organization.

InstallerMaker also supports tasks that allow you to display picture banners during installation and/or play sounds. These can be very meaningful marketing opportunities. They can also provide bits of instruction or useful information you want to ensure your users to see or hear during installation.

Appearance

Now that your test people, marketing people, and lawyers are happy, you can think about some of the extras that make things pretty for users. In the Mac world, we go to a lot more trouble than our Windows counterparts to make things nice for users. For instance, setting folder views and icon positions is foreign to PC users, but Mac users have come to expect it.

InstallerMaker stores icon positions and other Finder data at the time an item is stuffed into an installer archive. To achieve the optimum appearance, try to stuff all of your items under the same version of the OS, and when you replace existing items in your archive, make sure that the new items come from the same folder in the Finder as you stuffed previously in your archive. If you replace a folder outright in the Finder, then you should replace it outright in your archive, or you may get inconsistent settings.

Root level archive items, destined to be installed into the same folder at install time, should also be stuffed from the same folder in the Finder. If they come from different folders, you will get mixed icon position results. If your installer creates a user-specified folder, be sure and configure the installer's settings for that folder so the size and view match the folder on your machine. InstallerMaker lets you specify the folder in the Finder to match, and at build time writes the folder's current settings into the installer.

Uninstallers

Uninstallers are another nice feature. In general, most users won't use your uninstaller unless you install System items. You probably don't want users to remove your software, but this is a decent feature to provide for those who require it.

Internet Support

Internet support provides a means of live contact between you and your users, allowing you to provide extra value to them, which they may not otherwise receive. Today's installers can easily be setup to link to a server and download the latest updates of your software, or some extra goodies your users might like. InstallerMaker's "NetInstall IMid" extension is useful for checking versions of files on a server before downloading them. Your users might also like having options to download demos of your other products.

Just ensure that your users are ready and willing to go online before logging on for them.

Online Registration

Gathering information about the users of your software is important. No longer are you limited to getting users to mail in a registration card though, registering online is now the easiest and fastest way for users to register. InstallerMaker provides support for registering on the web, via email, or by traditional methods like standard postal mail and FAX.

Aliases

You can install aliases for the convenience of your users, especially if your users may not know how to create them. Personally, I object to having new aliases installed on my desktop after an installation, but I imagine it is helpful for many users.

Automatic Application Launching

Your installer can automatically launch your application following installation.

Troubleshooting Help

You may be able to determine things about the user's system during installation that would be valuable to point out to your user. If your installer notices that incompatible extensions are present on the system, it doesn't hurt to point this out via an alert.

Consideration

Consideration is what niceties are all about. Niceties are not the core purpose of your installer, but a little thoughtfulness can be very good for both you and your users.

Well, you've made it to here. I hope you have gathered some new thoughts about installers that help you in the future. If you encounter a problem that you can't find the answer to, nag for it. You'd be surprised how many features are added into InstallerMaker because one person made a compelling case for it. Even if you don't have a compelling case, you can at least count on the squeaky wheel getting the grease! Keep asking for what you want.

You can download a fully functional copy of InstallerMaker from the Aladdin web site at: http://www.aladdinsys.com. For more information about InstallerMaker contact Aladdin Developer Sales dev.sales@aladdinsys.com or Aladdin Developer Technical Support dev.support@aladdinsys.com.

Eric Long is the lead software engineer for Aladdin Systems' StuffIt InstallerMaker application. He has been at Aladdin for three years, functioning as the InstallerMaker engineering lead for every version from v4.1 to present.