[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:48:26 +0100

At 10:42 Uhr -0600 11.03.2005, Jesse Ross wrote:
I guess the way I was looking at it is that the app itself contains a
wizard-like installer within it. Thus, you still drag and drop the app,
but when you first launch it, it runs an installer and does all the
required script running, lib placement, etc that a pkg installer would do.
Every time afterward, double clicking on that same icon runs the

Yeah, I think you already mentioned that MS-Office for Mac does it that way. If the installer was a library which looks at an installer.plist file in the app bundle, it could easily install all sorts of support files for an app in the right place upon first launch (or maybe symlinks to them, to avoid unnecessary copying?).

My biggest problem with packages is that if it installs a user
app, there is no immediate way of knowing where that app is (other than
reading output, which no one does) and it takes control away from the user
in letting them organize their apps and files how they want to.

Yeah, if the user could just drag the app in, and installation would happen on first launch, that problem would be solved.

I think something like Installer.app is probably best for installing
shared libs or non-GUI executables (CLI tools, server tools, etc),
although there is still a question of where stuff ends up.

OTOH, in MacOS 9 you had "system extensions" which you dropped in the system folder and they automatically "found their way" into the right folders. So, you could just have certain kinds of extension bundles that are themselves routed to a particular subfolder of Library, and can also contain an installer.plist which would then let them install support files in /usr/bin or /Frameworks or whatever. All you'd have to do is drop these system extension bundles on "Library" to install them.

 > (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.)

Agreed -- it's a sequential process, it should have a sequential interface.

Warning! It's not really a sequentiality that should be exposed to the user. Sequences are good for guiding users, and they make it easy *for the programmer* to ensure the user has visited and set up all pages, because when he reaches the last page with the install button, you know he's seen all previous pages.

However, if you have a large number of pages, sequentiality can actually be annoying. We'd be back in the age of command-lines and modes, where you're asked two dozen questions in a row without being able to see the end, judge how long it'll take or skip ahead when you know the defaults are okay. And when you screw up and you only realize it two pages later, it shouldn't reset all your settings. If installation really *was* sequential, this wouldn't annoy us, but it isn't sequential, and so it *is* annoying.

Moreover, if the user doesn't understand the current page, they may not be able to continue, even though seeing the next page may make it clear to them how the previous page was meant. E.g. if you're setting up a blog and it first asks you for the "site URL" and then for the "blog URL", you may first think "the blog is my web site" and enter the URL for the blog. Then when you see the caption "blog URL", you may realize they meant the hostname, and you'll have to go back. Now, if there was some validation done of the site URL, you may get an error without knowing why, and you'll have no way to realize your mistake because you'd never see the "blog URL" caption...

 ... not a very good example, I hope I managed to bring across what I meant:

Installation is rarely sequential, only simple installations are. Usually, drag installation should suffice, with maybe additional installation and access to the "Preferences" window upon first launch.

Come to think of it, if you're providing an installer for a shared lib or a non-GUI executable like Apache, you could just make it the "support tool" inside the package of an Apache Config File Editor.app, or a PrefPane, and thus include the GUI for it right away.
M. Uli Kusterer
       "The Witnesses of TeachText are everywhere..."

reply via email to

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