[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Installer UI advices

From: Frederico Muñoz
Subject: Re: Installer UI advices
Date: Fri, 11 Mar 2005 18:56:52 +0100


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 <address@hidden> 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,


reply via email to

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