From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: GUIs Considered Harmful
Organization: Mount Holyoke College
Date: Thu, 20 Aug 1992 18:19:57 GMT

In article <Bt90Dq.35y@oryx.com> xcpslf@oryx.com writes:
>In article <1992Aug19.192513.28287@news.eng.convex.com>, Tom Christiansen <tchrist@convex.COM> writes:
>|>                      GUIs Considered Harmful

>How do you implement an editor for seismic data or a drag and drop file
>utility on a vt100?

Huh?  A "drag and drop" file utility _is_ a GUI.  There is nothing you
need to do to files that requires "drag and drop".  Your file utilties
should be command line accessible _and_ GUI accessible, be it via "drag
and drop" or some other goo-ish mechanism.
 
>|> forever limit that tool's flexibility.  After all, how to you write a
>|> shell script that drives an automated xrn session?
>|>
>There are usually ascii versions of commonly used utilities.  Use rn or
>another favorite reader.

We know that.  But the ideal would be a single tool with both types of
user interfaces, but identical underlying functionality.
 
>|> The most effective use of GUIs in UNIX environments is
>|> to design the nitty-gritty computational function as a "back end" that
>|> can be driven either manually or automatically.
>
>Standard programming practice in my book wher it fits.  This fails often
>when it comes to compute intensive applications and those that use huge
>amounts of memory.  The mechanism to transfer the data from a "back end"
>adds too much time to computations.  And as we know, time is money.

I really can't follow what you're saying here... you'll have to
provide some more specific examples.  I'll give you one that directly
contradicts what you're saying... one of the most "compute intensive"
_and_ memory intensive applications I know if is Mathematica.  With
only a few user operations in Mathematica you can tie up a
supercomputer for the next Millenium and use all the storage currently
in the world.  Nonetheless Mathematica completely separates the user
interface from the "engine", and you can even run the two on separate
machines.  (This later statement is, of course, true also for all
X-based applications, but those you can't necessarily run from a vt100
terminal.  Still, the very existence of X disproves your statement,
IMHO.)

>|> The GUI wrapper should be a separable module.  If they're plug-replaceable, 
>|> the application isn't irretrievably wedded to any specific GUI technology, 
>|> such as SunView, NeWS, or even X11 or its children, like Open Look or
>|> Motif.  Sending standard commands down a pipe the way the STDWIN or wafe
>|> packages behave is also a reasonable approach.
>|> 
>Again, the overhead of transfering large amounts of information makes this
>unreasonable.

Again, justify that statement.  Run an interactive X-based graphics
application over an ethernet, then tell me what amounts of "data
transfer" are necessary in your application that this is unreasonable
even if the front and back end are running on the same machine.

>|> This means your program should be runnable both with and without the
>|> GUI present, and accept input from a mouse or under programmed
>|> control.
>|> 
>It depends on exactly what it's doing.  Most programs that merit it should
>have some sort of a batch mode, but this doesn't make sense in some graphical
>applications.

Althought there are graphical applications which really can only be
reasonably driven by a GUI, they usually contain at least parts that
should more directly accessible.  For a simple example, I recently
installed a very feature-laden X-based image viewer called "xv".  This
program can read and write a dozen different popular image formats,
and has a very complete GUI.  But one of the first things I found out
about this program is that there is no way for me to use this it to
convert a directory full of files from one format to another, unless
I'm willing to sit here for an hour clicking the mouse on filenames,
buttons and scrollboxes.  All the functionality is there in the code,
there just isn't any way to get at it -- very frustrating!  In this
particular case the necessary changes to make it more useful in this
regard are minimal, and I will probably implement them and send them
to the author, but you get the idea... it should have been there in
the first place.  The author was thinking GUI, GUI, (pretty) GUI, and
didn't realize that he was severly limiting the usefulness of his
excellent and complete program by not thinking about how his program
could fit into the Unix tool paradigm.

>|> It has been noted that GUIs make simple things simple, and complex ones
>|> impossible.  Certainly it is worthwhile to make simple things simple.
>|> But too often software is geared to only one level of expertise. 
>
>Incorrect.  A well-defined GUI makes simple things simple and speeds up
>specifications for the complex.  

Again, could you elaborate?  What do you mean by "specifications for the
complex?"  There are _some_ complex tasks (as Tom points out) that are
indeed best suited to mouse operation (such object manipulation in CAD
programs or other graphical-based modelers), but many complex operations
do not easily map to a point-and-click paradigm.

>|> Gratuitous distractions from the keyboard only slow down the experienced
>|> user.  A precision pointing device that didn't require taking your hands
>
>In X, we use acceletators of translation tables which in most applications are
>user definable (for the daring).

Well, then, you're doing _something_ right.  ;-)

>It seems that this note is from a person who has used UNIX for a long time.
>It omits the fact that the greatest majority of UNIX users have not and
>never will master the ideas behind UNIX.

But the bottom line is that neither Tom nor I are saying that GUI's
are always bad for everybody (in the contrary... I have been an
advocate of Macintosh personal computers since 1984.  For most casual
personal computing users they are, IMHO, still the most productive
tool available.)  In advanced computing environments on the other
hand, such as are necessary for many professional tasks nowadays, GUIs
become bad when application developers lock you into their user
interface paradigm.

As Tom stated in the beginning of his article, this may be fine on PCs
and Macintoshes, but it just isn't a good idea on more sophisticated
operating systems, be they unix-based or other new workstation OSes,
such as NT.  One reason for that is that modern workstations often
have to integrate into heterogeneous computing environments, and it is
the inflexibility of an application that locks you into a particular
GUI-oriented paradigm that becomes a problem here.  Another reason is
that many GUIs are simply bad... if applications didn't lock you into
a particular GUI, but had replacable front ends, this would be much
less of a problem.

Related to this is also the recent proliferation of different GUIs.
Do I run Motif, or Open Windows, or plain Athena X?  Or do I have to
have them all because my CAD package runs under Motif, but my Desktop
Publishing package runs under Open Windows?  What can I do if I don't
like the OLWM?  Does this mean I have to throw out NeWS as well?  Why
do I have click on the menu in one GUI, but drag it in another?  Which
mouse button does what under which GUI and in what application?

If all applications had nice clean separations between GUI and core
functionality, I would have much more flexibility in putting together
a GUI-oriented work environment that suits _my_ needs, rather than one
that arbitrarily follows the whims of a dozen unrelated programmers (most
of whom usually have _no_ user interface design training) and would 
_still_ be able to get at much of the functionality of my environment
from home or from the field via a terminal and phone line.
--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629