| |
Simon Guest  mentions 10 tips he'd like everyone who creates an installer take into account. I have to agree with his list. Here's a paraphrased version of his list with a few comments of my own...
- Include prerequisites in installer
If your app requires something else, at a minimum, create an extra installer that bootstraps the prereqs. This is handled by .NET and I know I've seen a lot of Java apps include the JRE, so that's good. I still end up seeing this rule violated every once in a while, tho. One instance is when a Visual Studio add-on required another add-on. The one in question should've checked for its prereqs and installed them if they weren't there. The task isn't that hard.
- Don't require a restart unless it's absolutely mandatory
I have seen a lot of apps that don't really need a reboot, but I've also seen the ones that do. What I'd like to see is a note for more information on why the installer needs a reboot and/or what will happen if you don't. Not rebooting can cause consequences. I'd like to know what those are, so I know whether or not I should really stop what I'm doing just to reboot.
- Avoid unnecessary animation and menus
I don't know that I've seen any violations in this area that often, but I can definitely understand how over-use might be an annoyance.
- Limit options
Installers need to be simple. The best installers are the ones that don't need a lot of thought put into the actual installation process. Sometimes options are necessary, but what I'd like to see is different automated installs. For instance, give me an option for a typical, complete, and custom install. Also, when you do give these options, try to describe what's included in each so users aren't guessing what the difference between typical and complete is.
- Ensure uninstaller removes everything
This used to be a huge problem a few years ago. The biggest thing I'd have to say is, don't use the registry. I admit that the registry is required sometimes, but not always. Be judiscious when using it or any other system-wide resources and when you do, be sure that your uninstaller knows about them so it can remove everything. There's nothing worse than having to manually clean out the remnants of uninstalled programs... ok, maybe there is.
- Make necessary permissions known
I'm one of the many people who runs as admin, so I don't see this too often; but I have worked for organizations that don't allow admin priveleges to get out. When a user doesn't have the necessary privileges, tell them. If your installer doesn't, you're risking a install errors, which could essentially leave the system in a half-installed state, which could corrupt further installations or even the system, depending on what your installer does.
- Add ability to close necessary applications
This is pretty simple. If you need apps closed prior to install, give an option to do it for the user. The only thing I have to add is, if it's possible to bring an app back to its previous state, do so. One example is a browser add-on. The installer should see if the browser is open, save as much state information as possible (even if it's only the URL), install the product, and return the user to the state s/he was at prior to installation. If I found an installer that did this, I'd be very happy. I usually do this manually to get around it.
- Display accurate time remaining
This is pretty simple. As a user, I want to know how long the process is going to take. Figure in average network and disk access time, where applicable. Don't use the current time because that's probably not going to be consistent. Don't tell me about a percentage of files, because some files are larger than others. Be smart and determine the best installation metrics for your process. Where possible, group actions in steps and show the user where they are in that whole process.
- Automate unpacking and clean up after yourself
This is another big one for me. There aren't too many installers that do this, but it does happen. There's no reason an "installer" should unpack files to a directory and quit. At least run the installation. Oracle's .NET data provider does this, for instance. And when the installation is complete, remove the files you created. Simon also mentions that the system %TEMP% directory should be used. I whole-heartedly agree. I don't like temp files clogging up my directory structure any more than they have to.
- Is an installer really necessary?
I have to say that this is probably the biggest one for me, personally. If an app doesn't require system resources and/or is going into one directory, give me an option to not use an installer. Personally, I like to keep my apps which don't need to be installed into the system separate from the others. These are typically more portable, which allows me to take them from one computer to another without any repercussions. These tend to be small apps that I can't live without -- in part because of their portability.
I'm sure, with some thought, we could all come up with our own 10 installer annoyances; but I think Simon came up with a good list to start with.
Ratings
|
|
|
|