Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!ittvax!wex
From: wex@ittvax.UUCP (Alan Wexelblat)
Newsgroups: net.cog-eng
Subject: Re: User-Friendly Re-Defined Access-Efficient
Message-ID: <976@ittvax.UUCP>
Date: Tue, 30-Aug-83 09:31:13 EDT
Article-I.D.: ittvax.976
Posted: Tue Aug 30 09:31:13 1983
Date-Received: Wed, 31-Aug-83 12:50:05 EDT
References: ulysses.579
Lines: 35

I think Gary Perelman has an excellent set of ideas, but I see two problems
with his multi-functional schema:
1) Cost in programmer time.  There are an awful lot of "hooks" involved in 
   writing code with pop-up menus and many-layered HELP systems.  Mind you,
   I'm not saying that these are bad things in and of themselves, but I'm 
   trying to point out that they'll end up costing the system user a lot
   of $$ in programmers' and debuggers' salaries.  If you automatically 
   design this much complexity into systems, you may end up pricing yourself
   out of most people's markets (look at the Xerox workstations for an excellent
   example:  the Dorado (?) is amazing in terms of its abilities, but it costs
   $140,000!)

2) Cost in machine space/time.  It's true that machines are getting faster
   and faster, and that memory is getting cheaper and cheaper.  But you can
   still easily over-design for the space and speed of the machine that you're
   building on.  Heck, our VAX experiences significant slowdown in the presence
   of three or four TROFF jobs!  If you have a user group using this complex
   multi-functional system, it's entirely possible that you'll end up with a
   too-slow response or a too-large demand on your customer's machine.

Moral:  don't over-generalize.  When you're building a system, get an idea of
the people who will be using it, the equipment they'll be using it on, and
so forth.  Then design in as much 'human factors' as you think necessary.
A shop of UN*X hackers won't care about the same things a brokerage house 
would.  And (this is for you, Laura) don't let the customers tell you how to
build your product!  You're the programmer.  You can listen to their suggestions,
but if you let them dictate HOW you build your system, then you're doing a poor
job.

Yes, I know this really isn't a solution, but I doubt you're going to be able
to concoct a good, general solution.  The best you can do is set up guidelines
which can be loosely followed.  Sorry to pontificate so much.
--Alan Wexelblat
decvax!ittvax!wex
(soon to be decvax!ucbvax!wex.UPenn@UDel-Relay)