haungs@wivax.UUCP (11/30/83)
All you folks embroiled in this "long names" discussion are missing an
important point about the nature of many current and lots of future
computing machinery. The Unix "command" orientation may have been great
for 300 baud yellow-paper TTY's, and it may be becoming the most standard
thing since Wonder Bread, but I hardly think that its obscure syntax, and
dumb-terminal orientation are the wave of the future.
Some people (myself included) don't know a heck of a lot about Unix, and
don't need to. I use it to read my mail, and do some simple editing, but
that's all. People who use it all the time and/or don't/haven't used
anything else, sometimes don't see that there are *lots* of other ways to
build user interfaces.
Please note that I don't work for any of the following vendors; I'm just
making some observations.
Many systems (Perq, Sun, Lisa, Lilith) use high-resolution bit-map screens
where menus are not only fast, but they are small and precisely to the
point in the current context. I've used the Lisa quite a bit, and am
amazed both at the number of things I can do without ever touching the
keyboard (which is almost never), and also at the number of things I don't
have to remember. I was delighted to discover that I could sit down at the
machine with no documentation or experience whatsoever, and create
documents, graphs and drawings with **NO** help! Not only that, but the
user interface is so remarkably consistent that I could jump from
application to application and use the same "commands" I had already learned
because the menus WERE THE SAME BETWEEN APPLICATIONS! If ever I
didn't remember something, it was there on the menus to remind me.
In addition, the manipulation of objects such as documents and graphs was
direct and immediate. If I wanted to delete a document, I clicked the
mouse and dragged the document over to the garbage can icon, and let go.
To copy it, I just moved it to the floppy icon. This generalized
superbly to 90% of the things I wanted to do.
Since I do work for Wang, the next discussion is slightly biased. I've used
the VS system for more than five years, and have never typed (or forgotten)
a command, because the entire operating system, including utilities and
applications is menu-driven via PF keys. The workstations have a 64K Z80
in them for local processing, so the full 24x80 screen goes up much faster
than you can read or type. In this context, menus are fine even for
experienced users. With the addition of type-ahead, you can type
characters and program-function keys ahead of the system's response. It
becomes a matter of muscle memory after awhile. I don't require short names
because menu navigation is a matter of a single keystroke, and menus are
rarely more than three or four levels deep.
I think the broader issues of interface design, particularly regarding
user mnemonics for casual users, are very important. I hope that with the
advent of powerful desktop machines, the current arcane command languages
will be replaced by direct manipulation of symbolic entities in the
application domain, rendering the whole syntax issue obsolete.
--
Jim Haungs -- {decvax,linus}!wivax!haungs -- Wang Institute
Haungs.Wang-Inst@CSnet-Relay -- (617) 649-9731
Wang Laboratories, Mailstop 1379
1 Industrial Avenue
Lowell, MA 01851 (617) 967-6430smh@mit-eddie.UUCP (Steven M. Haflich) (12/01/83)
Since I do work for Wang, the next discussion is slightly biased. I've used the VS system for more than five years, and have never typed (or forgotten) a command, because the entire operating system, including utilities and applications is menu-driven via PF keys. The salient reason function keys were implementable on the Wang system, I suspect, is that the user interface only runs on one kind of terminal (or perhaps a limited set of similar devices). Look at termcap sometime. The only reason all those entries are there is because someone, somewhere, used each of those devices! Unix is a non-captive general time-sharing system that runs on lots of different hardware and terminals with varying configurations of function keys. Menu systems will likely be standard once high-resolution bitmap displays and mice are also standard. They have existed on Lisp machines, various Xerox machines, and others for many years. I have seen apparently-nice window systems on Unix running on the Blit, on the widely-unannounced Sun II (*), and on Apollo machines. Of course, it will remain difficult to access such capabilities from home at 1200 baud, although I have heard opinions that the Blit can be made to function reasonably. (*) Sun II might or might not someday be a trademark of SMI [:-)]. Steve Haflich, MIT Experimental Music Studio
chris@alberta (12/04/83)
Human beings are amazingly adaptable computing machines. They are able to see the need for, develop, and use effectively, special-purpose modes of communication keyed to the task at hand. Computer command languages and programming languages are examples. A person who uses a computer a lot will in general know what he/she wants to do, and will want a short, concise way of stating it. The beauty of computers is that they can be tuned to vary the conciseness, etc. from user to user. Command languages will not go away - they are simply far too useful. They will undoubtedly change a lot, possibly including aural input, tactile input, maybe even brainwave input, but they will continue to exist and to evolve. My terminal runs at 19,200 baud, which menu supporters would probably consider quite adequate for menu-driven applications. I don't like waiting for it to do anything, and menu's would certainly irritate me because they are not effectively instantaneous (less than 1/100 second). I'm partly biased in this by having used a Courier terminal on an Amdahl, which is rewritten VERY quickly over a coax cable. On such a system, menus would probably be tolerable for applications I don't use much. I also worry about the latest fad - the desktop metaphor. It seems great now, but what relevance will it have in a couple of years to a beginning user who has never used a real desk? (Flat writing surfaces yes, but not an organized desk with drawers, IN and OUT baskets, a properly placed garbage can, etc.) Chris Gray ...uw-beaver!ubc-vision!alberta!chris
dave@rocksvax.UUCP (12/07/83)
Did it ever occur to anyone that non-expert users might not be typists.
Even if you are a typist think of all the typing you do with short
terse commands. All that timing takes time. What about typing
errors? When you have just invested 10 minutes typing things, ala VMS:
backup drb0:[dddd.ssss...]*.*;*/before=10-feb-83
mfa0:[place.fff]/save_set/dens=6250 (On two lines even!!)
hit return and get a message telling you it did not understand 10-feb-83 and
you have to type it all in again, give me a break! That is helping
your poor [non-]expert user!!
Menus are great for things like that, you can get all the options right the
first time. But these solutions are always tied to the single process
mentality so common in most "software for the 60's systems". I can only
do one thing at a time using most of the menus I have used. I have
used and written a few Xerox Alto menu programs, Interlisp-D, Smalltalk
and the Xerox Pilot/Mesa operating systems. What about trying to do
that backup at 4:35 in the morning, do I have to be there to mouse bug
all the buttons on the screen?? Seems that you would have to anticipate
these things in advance and put it in every program, usually in a different
manner for each case. Look at VMS, is the option /ALL, /FULL, /EVERYTHING??.
Make a hardcopy: /PRINT, /HARDCOPY, /FILE=ccc; print ccc. I like kit parts
like unix tools, it even allows people who do not suffer from functional
fix to use a "screwdriver to act as a wire".
Menu/window systems make great typing aids. I usually type VMS commands in our
mail program. The mail program allows me to chat on our net to our machine
and I can "type" things into VMS by pointing at it on the screen with the
mouse. At least I don't have to re-type the whole long line in again.
Except for Smalltalk I have yet to see a menu system that does the
following unix thing:
bletch | bletch1 | bletch2
Maybe someone will write one that allows you to connect the stdin/out of
the window into another window's stdin/out or something like that.
I have written large systems for testing custom VLSI chips that make heavy
use of that form of "programming". Seems that typing "test_em" which
expands all the nitty gritty details of the "plumbing" for me is OK.
Most menus I have seen are of the form:
bletch ; bletch1 ; bletch2
This makes menus losers at are those repetitive tasks that you
sometimes have to perform. Try using a menu based image manipulation
program to process 15 images all the same way. Of course you could
write menu program that asks for a set of files to do these things
with, but how many people thought to do that from the start. The best
thing to do is to have all menu based programs read text commands from
files or allow all menu functions to be run from command lines.
I cherish being able to read news while a compile and a chip is being
tested. A computer should work for you, that is how I think of them.
It can wait longer than me if it needs to, I like my results in as
timely manner as possible.
--
Dave
Arpa: Sewhuk.HENR@PARC-MAXC.ARPA
uucp: {allegra, rochester, ritcv, ritvp, amd70, sunybcs}!rocksvax!daveemjej@uokvax.UUCP (12/11/83)
#R:wivax:-1900100:uokvax:1800010:000:567 uokvax!emjej Dec 9 09:29:00 1983 Re long names as bothersome for non-typists--you have a point, *but* csh, emacs, a tool under VMS whose name I have forgotten, and even the Stiff Upper LISP that runs on a Z-80 CP/M system all have a way to redo a preceding command with optional changes. Heck, even on an Apple you can wander around on the screen, hack a line, and re-enter it. I'd rather have command names and options that have some detectable relationship to their function than something that saves wear and tear on my fingers but whose name I couldn't guess to save my life. James Jones