From: barrett@iastate.edu (Marc N. Barrett)
Subject: Re: Advocacy? What do you want for the Amiga?
Organization: Iowa State University, Ames, IA
Date: Tue, 12 Jan 1993 08:50:00 GMT

In article <1itb81INN3ts@uwm.edu> bloc1469@ee.ee.uwm.edu (Gregory R Block) writes:
>In article <1993Jan11.105552.13510@qdpii.comp.qdpi.oz.au> davidme@qdpii.comp.qdpi.oz.au (David Meiklejohn) writes:
>>Thanks for the support (I'm the typical Amigoid referred to above  :-).
>
>EEK!  Marc's quote was supposed to be in there somewhere.  Damn.
>Basically, he said something to the effect of you having the vision of
>a bat for not wanting a hardwired works package that would cripple
>productivity under a multitasking OS.

   Which I never said, of course.  Conveniently losing my quote so that you
can put words in my mouth.  

   Ideally, the individual programs in a 'works' package should multitask
very well.  There is no particular reason why the programs would not have to
multitask.  The only people who would believe that a 'works' package would
have to disable multitasking to function are the same people who do not want
the Amiga to become easier to work with because it would result in increased
sales to 'the wrong people', and end the elitest niche that Amigoids have
digged the Amiga into now.

   ARexx could be provided by the software as an extra, but it would not be
the default means of linking the programs, because ARexx is too difficult to
work with by first-time users.  The best method of linking the programs
would be through an improved clipboard, with the methods of using the clipboard
being exactly the same in all of the programs in the package.  

   This is also a reason why trying to assemble existing applications into
a works package would not suffice.  The user interface's of existing Amiga
programs has been far from standardized, and this would result in having 
programs in the package that did not look or work at all alike.  Further, the
clipboard support in existing programs is either limited or non-existant,
resulting in programs in the package that could not trade data easily.


>>Yes, I tried to say this in my earlier post.  It shouldn't be necessary for
>>the user to learn ARexx (although it's not hard, especially since, once you've
>>learnt the macro language of one app, you've learnt them all).  What I'd like
>
>_THIS_ is the big thing to remember.  Rather than learning a dozen
>macro languages, you learn the SYSTEM macro language and apply it to
>all applications under the system that support it.

   You still have to learn a macro language to send a picture from a drawing
program to a word processor.  It might be fine for you, but requiring it
for everybody would sacrifice sales, which would in turn would diminish the
software support available to you.  Which would't be fine with you, I
assume.  The end result is, you should embrace anything that makes the Amiga
easier and more productive to first-time users, because you would eventually
benefit.

>
>>to see is, for example, if you've imported a picture into a document, the
>>word processor should allow the user to select the picture, then select "edit"
>>in a menu.  This would copy the image into the clipboard, load a paint program,
>>instruct it to load the image in the clipboard, allow the user to edit it,
>>then transfer back to the clipboard on exit.  All the user should need to know
>>is the name of their preferred paint program, which would be recorded in
>>preferences setting for the wp.  All we need are standardised Arexx commands
>>for load, save, etc.  That, and better clipboard support.

>
>Apps need to support better clipboard support, DEFINITELY.
>
>>This is the crux of the matter.  It's why I told Marc to try thinking like an
>>Amigan.  Building up from smaller, single-purpose modules is a different way
>>of thinking, or paradigm, from throwing every possible feature into one huge
>>application.  People can either see the advantage of a more modular approach,
>>or they can't.

   This is fine in best-case situations, where everything is setup just
right.  But ARexx is far too prone to problems.  For instance, what if the
ARexx support isn't setup right on a user's system?  Many files have to be
in the right place and the right lines have to be in the user's startup-
sequence for ARexx to work.  The idea of breaking everything in modules 
is also prone to problems.  In your description above, what if the user's 
preferred paint program did not support ARexx?  What if it did not support
the clipboard?  What if the pre-written scripts packaged with the package
did not support the paint program?  The ARexx scripts to make everything
foolproof would have to be very long, so what about the speed problem with
ARexx?  (ARexx is an interpreter, and has limits in terms of speed)

   The crux of that matter is that this approach is a lot like a house of
cards.  It can stand on its own and work right if everything is perfect,
but lots of things can go wrong.  Expert users could easily make it work
and get alot done with it, but it would not do for users not all that
familiar with the Amiga.  For beginning users, it would be better if the
seperate programs in the 'works' package were written to support ARexx
as an option, but not to depend on ARexx for the programs to work with
each other.

---
| Marc Barrett -MB-  |  email: barrett@iastate.edu
--------------------------------------------------------------------
"No, I just think that a computer grafted on top of another computer
is a kludge.  It has nothing to do with the AGA chipset." -- me