Re: Installer UI advices

[M. Uli Kusterer]

At 13:56 Uhr +0100 10.03.2005, Frederico Muñoz wrote:
> This mail is to ask advise on the UI design and even the UI
> structure. So, although I welcome any feedback, this is really what I
> need feedback right now. General questions on why we need package
> management, if it would be better to simply use rpm/deb, etc, are of
> course debatable, but I would really like to put those on hold for a
> moment.

Frederico,

 I think the main question is: Do people like 
installers? Most people don't. The installer is 
simply a means to get the software that you 
*really* want onto your computer. As such, I 
think the best way to write a good installer is 
to write one that minimizes the time you spend 
using it.

 NeXT's installer falls flat on the face in this 
regard: It has so many settings and windows and 
different "pages" that it looks like someone had 
way too much fun playing with packages.

 Apple's installer doesn't do that, by dropping a 
lot of functionality, which is a way to solve it, 
I guess, but not really ideal. In addition, its 
rigid structure forces users to go through three 
or four pages for most applications, when leading 
them right to the "choose disk" page and then 
having them click "install" would have sufficed 
for half of them.

 So, here's my ideal interaction model:

 Use a streamlined version of Apple's "wizard" 
style. Make sure that you have a list of pages on 
the left so the user can see what they've already 
done and what still lies ahead of them (not 
necessarily as a list box, just as a list of 
words. It shouldn't have enough pages to merit a 
scroller. If it does, you're doing too many 
settings that can be changed later at install 
time).

 Improve upon Apple by letting advanced users 
directly click one of these items in the list to 
go to that page (well, except "finished", of 
course). Also, have a menu item to turn on a 
"geek mode". That latter mode would show some 
additional labels for text boxes that e.g. tell 
users that the setting they're entering 
corresponds to the FROBNITZ_THE_XYZZY-option or 
whatever, and maybe inserts a second page that 
lists all files that are installed, and what 
they'll do. This should be an option that is 
global for the entire app, so admins can just 
turn it on, but off by default so as to not 
confuse beginners.

 This additional page would probably not merely 
list all files in the package, but also allow 
doing things like only install certain parts or 
whatever geeks love to do. ;-)

 Uninstalling would be comparatively hidden. Most 
users don't need to uninstall software. The case 
in which they do is usually when it's buggy or 
the installer didn't work. So, when you launch an 
installer and its files are already (partially?) 
installed, it would ask at startup what to do, 
uninstall or install on another disk.

 Another option would be to get un-installation 
integrated into the file manager (GWorkspace, 
right now): Certain user-visible files like 
applications, plugins and frameworks would 
contain an additional Info.plist key that 
contains a "package identifier", which connects 
it to a particular "receipt" for an installed 
package. When the user tries to delete one of 
these files, GWorkspace would tell the user that 
this file is part of a package and should be 
uninstalled with its consorts, giving the user 
the "expert" option of only deleting this file, 
or alternatively offering to run the uninstaller 
right away, or abort.

 Of course, if the author of GWorkspace is hip 
with this, we could even come up with a protocol 
to mark certain files as "auto-unpack". Of course 
this has to be designed carefully not to be an 
invitation to virus writers, but what we could do 
is have a shortcut to installation: When a user 
drags a package onto a hard disk, they're told: 
"This is a package. Want to copy it as a package, 
or install the files on it on this drive?". In 
this case, the package would be installed with 
sensible defaults and no additional user 
interaction required.

 However, this latter option would need to be 
done very carefully, or users will accidentally 
install stuff on a drive when they really only 
wanted to back up the installer package. Maybe a 
good compromise would be to only have it work 
this way when a package is dragged on a "Library" 
folder.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
       "The Witnesses of TeachText are everywhere..."
                   http://www.zathras.de