Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!vsocci
From: vsocci@netcom.com (Vance Socci)
Subject: Re: Retro-Computing!
Message-ID: <vsocciD6H78H.7nE@netcom.com>
Sender: vsocci@netcom21.netcom.com
Organization: Xenos
X-Newsreader: News Xpress Version 1.0 Beta #2.1
References: <D5yxwn.5BG@sdf.saomai.org> <BILLW.95Mar26154351@glare.cisco.com> <vsocciD6DErH.ADz@netcom.com> <1995Apr3.125308.13794@ivax>
Date: Mon, 3 Apr 1995 17:25:19 GMT
Lines: 132

mwood@indyvax.iupui.edu (Mark H. Wood) wrote:
>In article <vsocciD6DErH.ADz@netcom.com>, vsocci@netcom.com (Vance Socci) writes:
>[deletia]
>> There are many problems with the old style "type in a command" interface which
>> modern GUIs are trying to address.  Granted, most modern GUIs are poor copies
>> of what they could be; anyone who has  used the Xerox Star workstations knows
>> what I mean. (These are the workstations that descended from the Xerox Altos, where
>> graphical user interfacing was pioneered).
>>
>> I won't belabor the current and potential benefits of properly designed GUIs. Nor will
>> I get into my prediction that user interfaces and virtual reality will eventually merge, yielding
>> a strange multidimensional world in which to run your favorite multidimensional programs.
>
>You and all of the cyberpunk authors.
>

The fact that I've gotten myself into this whole issue is ironic; those who
read this newsgroup that know me from back in the late '70s can attest that
no one was more died-in-the-wool, who-needs-stupid-UNIX-user-friendliness-
crap, let-them-eat-assembly-language than I was. My whole world was TOPS10
and PDP-10 assembly language, and anything more modern was either an
interesting toy or worthless to me.

Needless to say, after the PDP-10 rug was pulled from under me, I changed my
mind. Working at Xerox had a lot to do with it. I think you have to work
with a viable graphically based system to see the possibilities.

>> But I will say something about the problems with command line interfaces.
>[history lesson deleted]
>> Why have to recall lists of sometimes obscure commands to do certain operations if the
>> system can present the lists to you? Why have to memorize lists of switches which are not
>> consistent from program to program if the computer can provide a better way?
>
>Because I've got the hardware for it.  My brain (yours, too) has functional
>elements specialized for learning, coding, and decoding linear syntax.  Try
>Broca's and Wernicke's areas for a start.
>

I'd rather use my hardware to think about the task at hand rather than to have to
use it, breaking my concentration, to find out what switch I have to use to
transfer a file in binary rather than ascii mode . . .

>> Sure, man pages are fine, help messages are fine, but if you go through the trouble of
>> typing in a command to see what switch to use, why not let the computer put the list
>> up in an intelligble form and allow it to be selected?
>
>Because after I've done this two or three times, I've *learned* it and I don't
>*need* to look it up again, unless I've been away for a few months.  At this
>point GUIs don't speed my work; they slow it down.  The operation has become
>*language* for me, and a graphical layout doesn't work the way my brain wants
>to now.  (A picture may be worth 1000 words, but how many of you can draw a
>picture of a complex concept involving *action* more quickly than you can get
>the gist of it out in speech?)
>

This may be true of *menu* systems, and I agree that in cases where the GUI is
limited to such its nice to have keyboard equivalents. Freedom for all! I defend
your right to memorize your commonly used keyboard sequences to the death.
Windows and Mac interfaces even allow for this automatically.

However, I haven't seen many *real* imaginative applications of GUI technology
to the old problems. For example: I wrote myself a super-intelligent backup/copy
program once that had fields and radio buttons. If you read down the screen, it
was kind of like a multiple-choice sentence. On the top, you had move/copy/archive/list,
then the source, then a noise-word to, then the destination, then an IF, then a whole
bunch of buttons which specified the conditions which had to be met for each file
to be copied (archive bit, creation date, files differ according to source compare).
You could either enter in the filespecs on the keyboard or click a little file selector
icon to bring up a file selector box.

It was much quicker to run this program than it would be to type in the corresponding
command lines, especially if you have to retype the lines because of typos, etc.
Also, if you wanted to run a list first, then just do it, it was just one button push
different, rather than  having to copy the command and edit it.

>I guess what I'm arguing for is a dual-mode interface.  Someone who uses a
>particular set of controls casually will love a GUI for helping him; someone
>who uses the *same* controls all day every day will *hate* the same GUI for
>getting in the way of his thinking.  OTOH if there's a lot of repetitive data
>entry, just about everybody will like having nice forms into which to drop the
>information.  OTOOH some people think spatially, and some linearly, and we need
>to accommodate both in some fashion.

Agreed - although I still say a properly designed GUI doesn't get in your way.

>
>I note the number of gadgets for MS Windows that will add a supposedly
>Windows-native command interface.  Anybody want to tackle the task of adding
>GUI to the COMND JSYS? or the VMS command compiler?

The way this kind of functionality will probably happen is via the X-Windows
interface, and applications gradually being upgraded to it. I prefer the Windows
style File Manager to the TOPS-10 and UNIX-like DOS file management commands,
although I could imagine a better interface.

The Xerox development environment had the beginnings of a great feature: you could
easily customize your graphical interface from the *outside*; for example, you could
drop a super-search application on ANY window which would implement regular
searches on the data in that window. Imagine if we could drop a little click-on
icon in the File Manager that would let you do wildcard selects more easily?

Another improvement that not many people have is the integration of the
pointing device into the main space of the keyboard. It is a pain having to
move your hand back and forth between the keyboard and the mouse if
you have an application that involves a lot of typing. (It is doubly
ironic that I've gotten into GUIs and subsequent discussions given the
fact that I type at over 100WPM . . . bad typists are generally the ones
who benefit most by having GUIs). I  have a new kind of keyboard
called the "J-Mouse" keyboard, in which the mouse is imbedded in
the J key. To activate the pointing cursor, one just presses the J key
down and wiggles it in the appropriate direction. Its not quite as fast
as a seperate mouse, but it is far more convenient for text editing, for
example, where a lot of the activity is on the keyboard and not pulling
down menus.

I still say that recognition is less mentally taxing than recollection, and
that we should utilize the spatial memory that we have rather than
to argue for our past limitations, and be thereby stuck with them.

Remember" "If the only tool you have is a hammer, everything looks
like a nail".



- Vance

/=======================================\
|    Vance Socci   vsocci@netcom.com	|
| "The worst secrets are those we keep	|
|   from ourselves . . ."		|
| "I am not a number; I am a free man!	|
\=======================================/
