Re: Installer UI advices

[Robert Slover]

On Mar 16, 2005, at 12:03 PM, Adrian Robert wrote:
> The key here is "given appropriate support" -- not just in practical usability (number of mouse clicks, disposal convenience, etc.), but in connecting with a *metaphor* the user understands.  Disk images rely on the "disk" metaphor, which users know already from other computer experience, though there are some inconsistencies as pointed out, since there is no physical analog to the image.  Archives whose desktop icons look like packages, and act like packages, can rely on the "package" metaphor, which all users are familiar with from the real world (you get a package, you open it, you find your new item inside, sometimes there is assembly required ;-).  On the other hand "archives" in the abstract, such as a zip file, don't have any metaphor to rely on.  Naive users I've talked with always have a hard time "getting" archives.
>
> Thus, the incidentals of the desktop handling of archives, such as what icons are used, behavior on opening, etc., should be paid attention to.  E.g., it is intuitive to open a "package" and get some special interface specific to packages, but it is not intuitive to open one and get a plain disk folder.  At least, not as intuitive as opening a disk and getting a disk folder.  Maybe representing an archive as a manila envelope or something like that would salvage the situation for archives.  StuffIt used a "clamped" (i.e., compressed) folder..

I think this is a fairly good summary, and those involved in the discussion seem to be slowly converging on the agreement that the visual metaphor shouldn't be a disk or a folder, but a "package" -- which seems downright reasonable, however it gets implemented.  I must admit that at first I didn't comprehend Uli's argument against the disk image concept -- I never had the slightest trouble understanding it nor has any Mac user I've met -- but then, the concept is really quite old there.  I cannot remember the first time I met a .smi download, or made my own, but it was a long, long time ago.  Before that there were ram disk utilities.  I know I have an early System 7 hard disk laying around somewhere that still has utilities on it for making both of those things.  I think I even read once that the MacOS had at one time been intended to ship with a ramdisk mounted on the desktop by default, to ease the concept of copying files between two floppies -- copy to ram disk, eject floppy, insert new floppy, copy from ram disk.  The NeXT Workspace "shelf" is a much cleaner way of handling that concept, IMHO.  Regardless I realized, after continuing to follow the thread, that Uli is right and the concept is unnecessary and broken.

I'd like to state one technical opinion -- I don't think .tgz is a good candidate for the underlying implementation.  I think .zip is better, for several reasons.  First, a .tgz must be completely uncompressed before you can list its contents or extract any files.  A .zip stores a catalog and directory tree in an uncompressed form -- this allows the directory structure, files, and their attributes to be enumerated and individual members to be extracted without decompressing the entire thing.  Second, .zip supports filesystem-specific extended attributes -- so it is possible to compress a directory on, say, VMS, ftp it to some other VMS system, uncompress it and have a usable directory hierarchy.  With 'tar'. the record structure (RMS file organization) isn't recorded and you end up with junk on the other side.  I think that issue is fairly important for a cross-platform environment.  Third, a .zip archive allows arbitrary 'cruft' to precede the archive contents -- this is what a self-extracting .zip file is.  I've an application right now on a Solaris system that emails a bunch of reports out -- it concatenates the report archive to the end of a small DOS executable which can unarchive the file and execute an embedded batch file.  The (Windows) users get a .exe that they can double-click on to view the reports, and they don't even need to have anything like WinZip installed.  The exact same thing can be done on *nix, simply by prepending a shell script.  Anyway, I wanted to point those things out.  I'd choose a different extension though, rather than '.zip'.   Something like '.pgz' and '.pg' for the uncompressed directory (I'd prefer .pkz/.pk, but that would probably tick off PKWare).  Visual metaphor would be the familiar tied up brown craft paper/cardboard box.

Lastly, at the risk of boring some folks, I'd like to say something about the Unix file system organization and cryptic naming that someone (I believe it was Jesse) is confused by.  I have a very old (early 80's, I think, first few pages missing so I do not know) AT&T Unix manual.  This is pre-POSIX as far as I can tell, and appears to be a troff dump of man pages.  The man pages seem to have been organized differently then (mnemonic section names of the form xx_yyy rather than numeric section names, where xx is a component or extension and yyy is one of ENV, SYS, LIB, CMD, or DEF).   There's actually a page documenting the filesystem structure FILSYS(BA_ENV).  It draws this diagram:

/
|
+-----+-----+-----+-----+
|     |     |     |     |
bin   dev   etc   tmp   usr
|
+--+--+
|     |
bin   tmp

It states that /bin, /dev, /etc, and /tmp (!!) are for the system's use, and users are not to create files there.  User files are to go under /usr, which I was told, after kvetch'ing about the redundancy of "/usr/users", (by someone who used to work at Bell Labs, for what it is worth) stands for "Unix System Resources" and not "user".   I was also told that /etc stood for "Environment and Text Config".  The manual specifically states that there are only two files defined to go in /etc, namely /etc/passwd and /etc/profile.  The /bin directory holds system executables (if any), and /dev holds devices.  The /tmp directory is for use by executables in /bin.  User-level utilities are to go in /usr/bin and their associated temporary files in /usr/tmp.  In a 'caveats' section,  another diagram similar to this is drawn (branches swapped around because I'd rather copy/paste):

/usr
|
+-----+-----+-----+-----+
|     |     |     |     |
bin   lib   etc   tmp   opt
|
+--+--+
|     |
x     y

This was the recommended structure for applications installed on a system -- which include the "advanced utilities" such as 'vi'.  Those which were installed in /usr/bin were to keep their config files in /usr/etc and their libraries and companion executables in /usr/lib.  Larger add-ons were to create option-specific subdirectories below /usr/opt (represented by /usr/opt/x and /usr/opt/y, above).  On the surface, this is all pretty clean and well organized.

Reality was a bit different though -- a quick flip through the rest of the manual reveals commands scattered all over the place, in opposition to the rules presented above -- for example, /etc/mount, /etc/umount, and their config file, /etc/mnttab, or /usr/lib/acct/fwtmp (format wtmp records).  Obviously, design and implementation rapidly diverged ;-).

I guess the point of all that is, the unix file hierarchy is fairly easy to understand, but hasn't been well adhered to historically.  I've been using it for years, but still get tripped up every once in a while by the few Solaris commands I rarely use that still reside in /etc or /usr/etc, or worse, /usr/lib.  An otherwise simple and elegant design is made needlessly difficult by inconsistency.  The consistency offered by having GNUStep apps be relocatable, completely self-contained .app directories whenever possible would be a big bonus in organization on any system.

Regards,


--Robert