Re: Installer UI advices

[M. Uli Kusterer]

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
> executable.

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