installer

2 entries have been tagged with installer.

Installation and Uninstallation on MacOS X

Soeren found an article on easier deinstallation on O’Reilly. The general idea (for the pointy-haired bosses among you who don’t have time to read it) is that every application would get an additional .plist file in its bundle containing the paths of files (like its prefs file) that can be safely deleted along with the application to clean up support files, like the ones in ~/Library/Application Support.

Problems of this approach

My one regular reader may not be surprised to hear that I don’t think the paths idea is a robust enough approach. For one, it would break when the user renames a hard disk. Secondly, some support files’ paths (e.g. Photoshop’s swap files) could be configurable, and then the .plist-info would need to be modified. And it’d be even messier if several users could provide different places to keep these files.

Putting support files in the app bundle itself, as some commenter suggested, has similar problems, especially if the software is on a server and shared between hundreds of users. It’d circumvent users’ disk quota and make permissions for an app bundle unnecessarily complex.

Alternative solution

My suggestion would be to simply add some sort of metadata to such support files and then use the Spotlight index to get rid of such files. Whether it’s done using access control lists, an xattr that simply says: kIsSupportFileOwnedBy = de.zathras.talkingmoose, or they define an OS9-style creator code in your Info.plist that says that all files with this creator are deletable support files, I don’t really care.

If all apps were required to give their support files such attributes, one could even have hard disk clean-up apps that can quickly find any orphaned files, like it was possible on Classic MacOS with creator codes (e.g. FileBuddy checked for files with unknown creators and offered to delete them). It should also be supported by NSDocument without too much work … NSDocument‘s bad support for creator and typecodes is the main reason for bad creator support, along with an ambiguous policy on Apple’s part and the discontinuation of the type/creator registry on their homepage ages ago.

Maybe it should even be a list of owning apps’ bundle IDs in an xattr. That would allow extending this to other kinds of files. E.g. a shared Framework could be auto-deleted when all apps that own it have gone.

Of course, Finder should generally ask whether the admin wants to delete all support files for all users who’ve used this app. After all, they may want to remove the global copy of the app and give two users who still need it local copies when an app is phased out. In that case, they’d want to be able to keep those users’ files.

Other installation/uninstallation improvements

While I’m at it, here’s an idea for making all applications drop-installable, even when they need an installer/uninstaller: Apple could support install and uninstall executables (which could be any of applications, shell scripts or .pkg files) that reside in an application’s bundle in a standardised location:

Users simply copy over the app, and when they first launch it, the Finder runs the installer in it, deploying all needed files. When you delete it, Finder finds the uninstaller and offers to run that.

The best installer is one you don't use

Do you like installers? Do you like using them? Most people don’t. Installers are mainly conceived as a necessary evil between us and the application programs we want to use. True, compared to having to manually copy dozens of files and setting up .ini files or .plists, they’re actually more evil than Evil, but still, they don’t directly help us get work done, and thus they’re still in the annoyance category, even if only by a narrow margin.

Consequently, I think the best way to write a good installer is to not use one at all. Where that doesn’t work, write one that minimizes the time you spend using it.

The topic of installer UI just came up on the GNUstep mailing list, and here are my thoughts about this, compared to the two obvious candidates as inspiration for a GNUstep installer: The traditional NeXT installer, and Apple’s current Installer.app.

NeXT’s installer falls flat on the face regarding minimizing interaction: It has so many settings and windows and different pages that it looks like someone had way too much fun playing with packages.

Apple’s installer doesn’t do that, by dropping a lot of functionality. Which is one way to solve it, I guess, but not really ideal. In addition, its rigid structure forces users to go through three or four pages for most applications, when leading them right to the choose disk page and then having them click Install would have sufficed for half of them.

So, here’s my first stab at a better interaction model:

[A single-page installer mock-up screenshot]

Use a streamlined version of Apple’s "wizard"-style installer. Make sure that you have a list of pages on the left so the user can see what they’ve already done and what still lies ahead of them (not necessarily as a list box, just as a list of words. It shouldn’t have enough pages to merit a scroller. If it does, you’re doing too many settings at install time that should rather be changed later while it’s running).

Improve upon Apple by having as few required pages as possible, and letting advanced users directly click one of the items in the list to go to that page (well, except "finished", of course). Also, have a menu item to turn on a geek mode. That latter mode would show some additional labels for text boxes that e.g. tell users that the setting they’re entering corresponds to the FROBNITZ_THE_XYZZY-option or whatever, and maybe inserts an additional page into the wizard that lists all files that are installed, how they are, and what they’ll do. This should be an option that is global for the entire app, so admins can just turn it on, but off by default so as to not confuse people who prefer other uses for their time.

[A multi-page installer mock-up screenshot]

This additional page would probably not merely list all files in the package, but also allow doing things like turn on/off certain entries to only install certain files or whatever geeks love to do. ;-)

Uninstalling would be comparatively hidden. Most users don’t need to uninstall software. The case in which they do is usually when it’s buggy or the installer didn’t work. So, when you launch an installer and its files are already (partially?) installed, it would ask at startup what to do, uninstall or install on another disk. A menu item sounds sensible, too, so people who know better than the installer that there are still some files to be uninstalled can force this behavior.

Another option would be to get un-installation integrated into the file system explorer (Finder, GWorkspace, whatever): Certain user-visible files like applications, plugins and frameworks would contain an additional Info.plist key that contains a package identifier, which connects it to a particular receipt for an installed package. When the user tries to delete one of these files, GWorkspace would tell the user that this file is part of a package and should be uninstalled with its consorts, giving the user the “expert” option of only deleting this file, or alternatively offering to run the uninstaller right away, or abort.

One could even mark certain files as auto-unpack. Of course this has to be designed carefully not to be an invitation to virus writers, but one could have a shortcut to installation: When a user drags a package onto a hard disk, they’re told that this is a package that they can just copy, or activate by installing it, with buttons to do the latter. In this case, the package would be installed with sensible defaults and no additional user interaction required.

However, this latter option would need to be done very carefully, or users will accidentally install stuff on a drive when they really only wanted to back up the installer package, thinking it’d somehow be broken if they didn’t install it. Maybe a good compromise would be to only have it work this way when a package is dragged on a system folder (like one of the "Library" folders).

This would help users spend much less time in installers, and would ease software management for users who just want to get their work done, while people who need to have full control over such things or who want to use arcane features or work in security-critical environments would still have the power to mess with their system all they want.

Comments, thoughts, suggestions?