Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!uwmcsd1!marque!gryphon!keithd From: keithd@gryphon.COM (Keith Doyle) Newsgroups: comp.sys.amiga.tech Subject: Amiga Roadblocks to User Friendliness Message-ID: <9407@gryphon.COM> Date: 8 Dec 88 18:01:05 GMT Reply-To: keithd@gryphon.COM (Keith Doyle) Organization: Trailing Edge Technology, Redondo Beach, CA Lines: 118 At the risk of starting another round of heated controversy over the "correct" way to package programs, I've run into some new difficulties in trying to package a program to be as clean and easy-to-use as we dream of. Not a demo contest entry, it would seem even more important that it adhere to such standards, even though the problems I've been experiencing are not specifically in conflict with the BADGE rules. 1. You apparently cannot do (easily) the equivalent of a an AmigaDOS path xxx REMOVE So, if you find it useful for a disk to add a command directory to the current path for some reason, that disk's icon will not go away once you remove it from the drive. Why would you want to do such a thing? I can envision one scenario, where you have a product that supplies several new CLI commands, and you have an icon that you can click on (after having booted from any WB disk) that does a path add, and gives you a NewCLI all ready for you to try out your new commands. One potential solution would be to do something like a "path >ram:foo" and later do a "path reset" followed by the appropriate number of "path xxx add"s reconstructing the users original environment. Doable, but messy. Further, if a developer would like to construct an auto-install program that adds these new commands to the users C: directory, we have the problem that likely as not, the novice is using a completely packed WB floppy disk that has no room for added commands. Apparently Commodore has encountered this problem and resolved it with questions like "would you like to delete fonts?" or "would you like to delete narrator/translator?" and various stuff like that. It would seem to be clear that a "make room on the WB disk" could be a general utility that many developers could make use of when installing certain types of new capabilities into a users native environment. A lot of novice users have figured out how to use a few basic CLI commands, but have no conception of how the C: directory works, and are completely unsure of what they need or don't need on their boot disk. And the worst problem. Those of you who have installed programs under MSDOS are presumably familiar with various INSTALL.BAT programs that do auto installs on hard disks, many of which actually modify the AUTOEXEC.BAT or CONFIG.SYS to add necessary boot-time configurations for the new package. A similar scenario on the Amiga might be a click-on icon that installs a package on a hard disk. Let's say this package needs an Assign and a path xxx add added to the startup-sequence, and the package is being installed in DH1:. Now lets investigate what the GVP hardcard builds as a boot sequence when you click on *their* auto-install icon. I pick the GVP system because that's what I've got. DF0:s/startup-sequence looks about like this: mount dh0: binddrivers dh0:c/execute dh0:GVPScripts/HDstartup-continue Somewhere buried in HDstartup-continue is the mount for DH1:. Thus, an ASSIGN foo: DH1:somedirectory is not doable until sometime after this mount DH1: command. How could an auto-install program address this situation? 1. Somehow determine if we have an autoboot rom or not. 2. if autoboot, start with DH0:s/startup-sequence 3. otherwise start with DF0:s/startup-sequence 4. chase startup sequence looking for execute commands, and 5. nest into subscripts looking for ???? What. What do we look for? LoadWB? EndCLI? The end of the script? Then backup up and insert our ASSIGN and PATH commands? Do we really want to even be modifying a script like this? (though I presume there would be lots of *WARNING* messages letting you know what it is about to do "Are You Sure" "Are You Sure You're Sure" "I Don't Think You're REALLY Sure, Do You?" 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. 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? 2. chase startup script chains looking for something typical and adding in the commands automatically after ultra-warning operator? 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