[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Installer UI advices

From: M. Uli Kusterer
Subject: Re: Installer UI advices
Date: Thu, 10 Mar 2005 17:51:17 +0100

At 13:56 Uhr +0100 10.03.2005, Frederico Muñoz wrote:
This mail is to ask advise on the UI design and even the UI
structure. So, although I welcome any feedback, this is really what I
need feedback right now. General questions on why we need package
management, if it would be better to simply use rpm/deb, etc, are of
course debatable, but I would really like to put those on hold for a


I think the main question is: Do people like installers? Most people don't. The installer is simply a means to get the software that you *really* want onto your computer. As such, I think the best way to write a good installer is to write one that minimizes the time you spend using it.

NeXT's installer falls flat on the face in this regard: 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 a 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 ideal interaction model:

Use a streamlined version of Apple's "wizard" style. 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 that can be changed later at install time).

Improve upon Apple by letting advanced users directly click one of these 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 a second page that lists all files that are installed, 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 beginners.

This additional page would probably not merely list all files in the package, but also allow doing things like only install certain parts 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.

Another option would be to get un-installation integrated into the file manager (GWorkspace, right now): 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.

Of course, if the author of GWorkspace is hip with this, we could even come up with a protocol to mark certain files as "auto-unpack". Of course this has to be designed carefully not to be an invitation to virus writers, but what we could do is have a shortcut to installation: When a user drags a package onto a hard disk, they're told: "This is a package. Want to copy it as a package, or install the files on it on this drive?". 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. Maybe a good compromise would be to only have it work this way when a package is dragged on a "Library" folder.
M. Uli Kusterer
       "The Witnesses of TeachText are everywhere..."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]