Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!ames!pasteur!ucbvax!CLOUD9.BERKELEY.EDU!dillon
From: dillon@CLOUD9.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Amiga Roadblocks to User Friendliness
Message-ID: <8812091849.AA02843@cloud9.berkeley.edu>
Date: 9 Dec 88 18:49:58 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 92

:Now, arguments that anyone who has a hard disk should be able to add
:ASSIGN commands to his own startup-script are nice, but far from
:reality.  I talked to a user a couple of days ago, who had a brand
:new Amiga 2000 with HD which was completely installed and setup by his
:local dealer.  He was trying to install packages onto his hard disk simply
:by dragging the visible icons onto the hard disk.  He couldn't drag the
:entire disk icon onto the hard disk (as you would expect ala-MacIntosh)
:because you get a "Can't move icon out of window" error or something like
:that.  We apparently don't have a "move entire disk into a drawer on the
:HD" capability without the CLI.  While some packages perhaps can be
:installed simply by draggin the visible icons, certainly not all can.

	Just a few of the workbench bugs which have to be fixed 
(will be 1.4 I hope).

:So, I proceeded to spend about 1-1/2 hours with this guy explaining to
:him how to use the CLI for the first time (CLI, what's that?) and
:over-the-phone following his startup-sequence maze to a convienient
:place to add the useful ASSIGNS, how to use ED etc.  Fortunately he
:had a GVP harddisk with which I had some familiarity.  After it was
:all over, he said "well that isn't all that hard".  And he's right,
:it isn't all that hard, but it would have been if he had tried to 
:figure it out for himself.
:
:So what's the answer?
:
:1. make sure commercial applications never need boot time configurations
:such as ASSIGN or PATH?  

	Many commercial applications must reference modules within 
themselves, dictionaries, help files, control files, etc..., and
the absolute best way to do this is by assuming they exist in a
custom assign'd place.  For example, the company Foo might have a 
dictionary program which assumes the dictionary can be found in
foodict:

	Thus, the user must add 'assign foodict: whereever' in his
startup script.  How the !@#$ else do you do it?  Assume the dictionary
is in S: or C:??  lovely.  Why don't we just assume the dictionary
is in DF0:?  Think this:...  It is nice to think that installation of
software should be as easy as moving an icon, but the reality is quite
different for many applications.

	Without Assign's, most large commercial programs have little
Flexibility.  It should be obvious from past experience, when programs
made ridiculous assumptions like there had to be a floppy in DF0:, or
the support files for the program were in the current directory or
something like that.  Yick.


>2. chase startup script chains looking for something typical and adding
>in the commands automatically after ultra-warning operator?

	Not possible.  For example, my s:startup-sequence on my HD
executes another startup-sequence conditionaly and then starts a shell
which does most of the system init.  It is not possible to write an
automated program that is able to trace that, and just adding the assign
to s:startup-sequence would not work in my (and many other) cases 
because not only has DHB:C not been added to the path yet, but my four
other partitions haven't even been mounted yet!

	Even a 'stupid-user-intallation' program would have trouble
for the same reasons... that there is no way to tell how that user's
startup-sequence is setup, it would depend on who he bought the drive
from.  And before you say it, tracing out the commands a startup-sequence
does is out of the question too for obvious reasons (if you just think a
little).

	A company might include such an installation program anyway,
but would still have to accompany it with manual installation instructions.

>3. warn user that the Amiga is inherently unfriendly to novice Hard Disk
>users who are unfamiliar with the CLI, so he'd better go out and buy a
>good book, or drag his system back into his dealer and let *him* install
>it?
>
>4. ???? (god I hope there's a 4. and maybe a 5. and 6.)
>
>Keith Doyle
>gryphon!keithd

	The reality is that the user must be smart enough to follow
instructions.  Of course, most installation instruction manuals are really
bad and impossible to follow.  The solution is to fix the manual, and the 
fault is that of the company.  But then again, the user had better not
be too stupid or he'll never understand the product.

	Apple had the right idea with their friendly user interface, but
found out all too quickly that it wasn't so friendly due to the 
unavoidable complexity of the applications run on it.

					-Matt