From: samborn@lynchpin.mtkgc.COM (Kevin Samborn)
Subject: Re: GUIs Considered Harmful
Originator: tchrist@pixel.convex.com
Date: Thu, 20 Aug 1992 20:00:32 GMT
Reply-To: samborn@lynchpin.mtkgc.COM (Kevin Samborn)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.


[forwarded posting]

Tom, I don't have USENET access - I am on the xpert mailing list - so
I cannot follow the guidelines in the Followup-To header.  If you
would like to post my responses (on alt.religion.computers, or
where-ever), go right ahead.

/\/\ On Wed, 19 Aug 1992 19:25:13 GMT, Tom Christiansen said:
   Tom> Of how much ultimate utility is that nifty new spreadsheet,
   Tom> editor, or debugger if I can't dialup from the field and run
   Tom> it on my vt100?

Applications such as these are made better by direct manipulation of
data.  Applications that are "field" operations will reflect that in
there design.  A better critique is when poor design of GUI
applications make the user feel that this is just a text application
in an xterm- "Why can't I take this with me?  Is this SPARC worth
$10000 more than a vt100/laptop?"  GUI applications should take
advantage of the direct manipulation capabilities of the environment,
than either a) the user will not be asking these questions or b) the
remote access capabilities will improve (which they are).

   Tom> Too often a tool that "does windows" is little more than a
   Tom> marketing gimmick to dazzle impressionable users into not
   Tom> noticing that they don't have the real functionality they
   Tom> need.

This is an (unrelated) problem that we need to overcome.  This is much
like using ABS brakes (or computers themselves!) as a solely a
marketing vehicle.  ie. do people really _need_ this tool, or is it a
"like to have".  I think that people honestly like GUI's the same way
that people like sports cars or computers in general.  This is why
people buy a $3000 mac to do desktop publishing, instead of bringing
their resume to the printer for $30.

   Tom> GUI-minded programs seldom lend themselves to being used as
   Tom> components in larger tools.  As such, they do not fit well
   Tom> into the UNIX tool-and-filter philosophy.  Instead of each
   Tom> being a single program that modestly attempts to do one thing
   Tom> well, they are a throwback to the Bad Old Days when each
   Tom> program was a standalone, monolithic monster that didn't
   Tom> interface with anything else.

I have given a lot of thought to this very issue.  I believe that you
are correct in that GUI applications do not fit in with the UNIX
tool-and-filter philosopy.  However, neither does any spreadsheet.
Rather, the spreadsheet is the top-dog/boss application.  It is made
up of many other UNIX tools.  (This is how I rationalize it, anyway
:-))

However, you bring up a very valid gripe: many GUI tools are
monolithic programs.  This is very bad, as you noted.  A much better
approach, in my opinion, is to create tools out of collections of GUI
(and other) tools.  Here is an example that I presented to the
software department in my firm.  We build financial analysis and
reporting tools here, so (for example), there is a need for an
"interest-rate swap entry form screen."  If the designer of this
"screen" builds it correctly, you can use it in many different
reporting packages (Profit+Loss, Auditing, etc.) not via a library,
but via a communication protocol - either using ToolTalk / X /
proprietary / CORBA, etc.  (In fact, on a side note, the selection of
this protocol is the largest thing facing me right now.)  A good
example of this is the file manager program seen in OpenWindows or
Looking Glass, etc.  This program has the capability to transfer a
"file object" to another program.  Following this lead, our "swap
screen" can send a "swap object" to another client.

I do not need to tell you that existing UNIX tools already follow this
lead- witness syslog.  Also, when discussing this very example at
work, I said that this really does not apply just to GUI tools.  For
example, we need some kind of logging- you can bet we will use a perl
logging process in the same fashion.

I think what I am really trying to say is, in a complete user-minded
(as opposed to the tool-building mindset) application we move from the
"filter" approach to the "use a tool as client" approach.

   Tom> It's all well and good to place a GUI wrapper around an
   Tom> existing tool, but to design a new application with only a GUI
   Tom> interface in mind is to forever limit that tool's flexibility.
   Tom> After all, how to you write a shell script that drives an
   Tom> automated xrn session?

In the wonderful world of UIMS-built tools, the GUI application is
itself really a shell script.  I built a UIMS in my former job that
was able to use any interpreted language as a tool builder.  In case
you are wondering, I built examples from Tcl, Python, C (ugh), and,
yes, perl.

   Tom> Providing programmability for the fancy graphics software
   Tom> remains an open problem.  The most effective use of GUIs in
   Tom> UNIX environments is to design the nitty-gritty computational
   Tom> function as a "back end" that can be driven either manually or
   Tom> automatically.

   [ omitted: discussion of why and how to do this ]

In good user interface design, the functional core (or computational
back end) should _definitely_ be separate from the presentation
component.  The method that they communicate should be through a
"Dialog Controller".  This is the interpreted language.  This stands
regardless of whether the end app is on a GUI or vt100.  Read the book
_Developing Software for the User Interface_ by Len Bass (of SEI/CMU)
and Joell Coutaz.

   Tom> But too often software is geared to only one level of
   Tom> expertise.  That which is novice-friendly is too frequently
   Tom> expert-hostile, and vice versa.

This should be customizable.  Not doing so is a sign of laziness in
the programmer (or toolkit designer for that matter).  For example, it
is really, really easy to add accelerators in certain GUI builders,
and very difficult in others.

Also, as I mentioned above, interpreted languages should be used as
the dialog controller.  If done right, then the dialogs themselves can
be extended by the end user- ala emacs-lisp / your mail reader (Plum?)
ie. use the dialog controller as an extension language.

   Tom> Gratuitous distractions from the keyboard only slow down the
   Tom> experienced user.  A precision pointing device that didn't
   Tom> require taking your hands off the keyboard would help.  There
   Tom> are cases where only a GUI makes sense, like a CAD system.
   Tom> Being able to delineate a region or draw a figure with a mouse
   Tom> is probably a reasonable use for it, but selection of a range
   Tom> of possibilities isn't, at least not after you've become
   Tom> familiar with the tool.

There are cases where a GUI makes more sense.  One of my favorite
examples: a scheduling tool where people are marking dates on a time
line.  In the old-style fashion (form entry), the app queries the user
to enter dates until he is done, and the computer marks the dates on
the time line.  He then has to specifically request to move the date
or remove it.  In my (GUI) version, he interacts in the new-style:
direct-manipulation.  Instead of entering the date, he just drags the
marker onto the time line.  Then, he moves the marker how he wants, or
just removes the marker off.

This paradigm is better (in my opinion) because the user is not asking
the computer to do something for him.  Instead, he is doing it for
himself.

Well, food for thought...

kevin samborn
--
kevin samborn
Sakura Global Capital
samborn@mtkgc.com

-- 
    Tom Christiansen      tchrist@convex.com      convex!tchrist
Pereant, inquit, qui ante nos nostra dixerunt.
"Confound those who have said our remarks before us."
                -- Aelius Donatus