[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: Fri, 11 Mar 2005 21:17:31 +0100

At 10:44 Uhr -0500 11.03.2005, Adrian Robert wrote:
I'm not sure drag/drop install is appropriate for packages. On OS X this is done for .apps that don't need any additional work (by scripts, etc.) or license agreement, and works because of their .dmg disk-image mounting framework.

No. .dmg files are simply another kind of archives. You can do drop-install with apps from zipped archives, or .tgz ones just as well. It has nothing to do with a .dmg. This scheme is only used for apps that don't require additional files.

On GNUstep, someone proposed using zipped .apps (.appz) to do a similar thing and that seems like a good plan when you just have a self-contained app. But the need for delivering in a "package" arises when something that simple can't work -- either you've got files that need to go elsewhere on the disk, dependencies that need to be checked, scripts that need to run, etc.. In that case the user can and should interact with the process more than a simple drag/drop would allow.

Well, I'm not sure about "can" and "should". Most apps with a good installer can pick sensible defaults for most install-time decisions. The case I outlined would still run the installer to perform the actual installation, but it would do so with minimal user interaction. So, drag and drop wouldn't be as powerful as actually running the installer but it would be easier, and would do the right thing for the common case.

Or maybe we could build the installer transparently into GWorkspace? I.e. an installer package would look like it was just an "install folder", which can be browsed like any other folder. All components that can be installed would be shown as little "files" in there. When a user drags one of the items from there onto their hard disk, it'll try to install them there. If there are dependencies that haven't been installed yet, it'd tell the user that the other file needs to be copied, too, and offer to do it. For files that need to go in special folders, it'd also offer to install them in those special folders.

So, for simple install cases that simply consist of installing certain packages or not installing them and satisfying dependencies, drag & drop install should work just fine. For cases where the user has to choose where the files go (e.g. /System/Library/ or /Library/ or ~/Library), the drag destination could be the indicator, otherwise the current user's permissions and a default saved in the installer would decide where the things are installed.

Since these "install folders" aren't real folders, this would even work for web-based installers. You'd have a list of all packages, but just wouldn't download them until the user actually drags them out of the window. It would basically be the equivalent of the package (aka bundle) mechanism. Heck the actual files being installed could even be put into a package folder, and only symlinks to them would get copied to "Frameworks" or "InputMethods" or whatever. When users drag the package to the recycle bin, GWorkspace would realize it's an installer and automatically get rid of the links as well, thus cleanly uninstalling the critter.

Only when the installer really needs to specify additional information *before* installing, then the user would really need to see the wizard.

(And when you do have to do this, the wizard UI seems the most reasonable and efficient way to get through it. It is easier to rush through a wizard and be sure you've at least glanced at everything than to click around a tabbed or other non-sequential interface. The wizard is also well-suited to delivering clear information to the user on what stage of an install process failed.)

Yes, agreed, if you really need to specify information, a Wizard is definitely the more intuitive UI than having arbitrary panes. OTOH, I think the user should still be allowed to freely move between the various steps of installation setup. E.g. if I select drive c: and then realize I want to install on b: instead, just after I've moved to the next page and specified that I want to install the 64-bit versions of all libraries, I should be able to go back. And if I'm a power user, there should be a (not entirely un-intuitive) way to directly go to another page if I know the defaults are okay.

When I install, the installer would give me a warning that I haven't seen all pages, name them even, and tell me that I can use the "back" button to see them. But if I insisted, it would just let me install it that way.

Aid the user, but don't get in the way, and don't be overly talkative. That's how I'd want an installer to be.
M. Uli Kusterer
       "The Witnesses of TeachText are everywhere..."

reply via email to

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