Re: Installer UI advices

[M. Uli Kusterer]

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.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
       "The Witnesses of TeachText are everywhere..."
                   http://www.zathras.de