Re: Installer UI advices

[Nicolas Roard]

On Fri, 11 Mar 2005 10:42:17 -0600 (CST), Jesse Ross
<jesse@jesseross.com> wrote:
> > On Mar 10, 2005, at 1:35 PM, Jesse Ross wrote:
> >
> >> I personally love the idea of drag and drop to install (or even
> >> trigger an
> >> installer) -- it means we have a single, logical method of
> >> installation and it allows our users the "luxury of ignorance", as ESR
> >> says < http://www.catb.org/~esr/writings/cups-horror.html >. Office X
> >> 2004's installer is really nice too, in that you drag the apps off the
> >> disk  and
> >> drop them on your hard drive, like a regular app. Once you launch the
> >> any
> >> of the apps, it determines whether you have installed any of the
> >> shared libs, and if not, goes through an installation process.
> >
> > 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.  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.
> 
> 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. 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.
> 
> 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.

That's an excellent idea, yes. We have application bundles -- we
should use and push that feature.
At least for normal applications we don't really need an installer ...
and for applications that needs
an installer, it seems to me that what Microsoft does with Office/X --
running an installer the
first time you run the app -- is exactly what we should do.

In that light, it seems to me that Installer.app should be split into
a framework providing what's needed for managing installation, and an
Installer.app that will use this framework for non-applications
(libraries, bundles, etc.) and normal packages (.deb, etc).
Applications that needs an installer phase will then just use the
framework. What do you think ?

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

Agreed too. Even if I'm not fond of it, it seems to me less
error-prone than the non-sequential way.
But perhaps let people jump through steps easily (if that doesn't
prevent the installation of course.. ie let them jump if the steps are
not mandatory..).

-- 
Nicolas Roard