Re: Installer UI advices

[Frederico Muñoz]

Hi,

I've been invulgary time pressed today so I can't reply to all the 
mails the way I would like.


On 2005-03-11 17:29:57 +0000 Nicolas Roard <nicolas.roard@gmail.com> 
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. 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.

I must be missing something here. If the application is an app bundle 
- if it doesn't depend on anything else and has only one top directory 
that is totally relocatable - an installer isn't needed (unless 
someone prefers to present extra information to the user). This far I 
follow your line of thought, and I fully agree.

I don't know, however, what this has to do with apps that are not app 
bundles and must be installed in certain places, or need files 
installed in several different locations, need license agreement, etc. 
That "running the installer the first time you run the app" is the 
thing that I don't understand. If it is a package, "running" it would 
launch the installer, and it would be installed. I don't know what is 
so different from more or less inclusing an installer in every package 
(actually, I can only see dowsides with this approach). I haven't used 
Office/X so I don't know what you are refering to.


> 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 ?

Again, I'm lost. If they don't need an installer, then why would they 
use any framework? If they are fully self contained, they don't need 
an installer. Also, "what's needed for managing installation" is 
Installer itself, it isn't a complex thing with several layers. Either 
packages have a reason to exist or appbundles are used. If they are 
packages, they need to be installed, i.e., they need something extra 
because they are not appbundles.

You agree with Jesse -- and so do I -- on the fact that appbundles are 
preferable to packages because they don't need an installer, but then 
you seem to indicate that you want appbundles to interact with an 
installer framework.

BTW, the division between apps and frameworks, libraries, etc  in what 
regards a need for an installer isn't so clearcut. Many apps need to 
install files to different places, i.e. they are not self contained. 
They are apps, just not appbundles

The code I have already makes a distinction between the package format 
and the actuall Installer UI, since each format has a bundle.

I must admit I am very confused.

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

This is why i made the RFC, even though the NeXT UI is better for 
"power users" that want all the info at hand, it's terribly confusing 
when one needs to present options. I also think that sequential is the 
best way, given it is made with both simplicity and ability to easily 
navigate (even the ability to just press "Quick Install" when the app 
contains defaults and doesn't need any kind of compulsory user 
interaction).

Best Regards,

fsmunoz