WORKS Digest V2 #73
ucbvax!works
Works Digest Friday, 13 August 1982 Volume 2 : Issue 73
Today's Topics:
Queries - Positioning Device Hookups,
Response to Queries - Pointer Device Report,
Display Resolution - Paper on anti-Aliasing,
Hardware - Mouse Controllers,
Menu Systems - Recall vs Recognition &
Intelligent Menu Syntax & Is it Worth it?
----------------------------------------------------------------------
Date: 10 Aug 82 11:03:12-PDT (Tue)
From: decvax!wivax!ss at Ucb-C70
Subject: Positioning Dev. Hookup?
Cursor positioning devices interest me, but I don't know how they
attach to a system/terminal. Would anyone enlighten me? Is it
attached to a terminal, or a tty-port, or directly to a bus? For
example, if I wanted to use a cursor-positioning-device with my vt100
attached to my unix system, how would it be hooked up?
Thanks, in advance
Sid Shapiro -- decvax!wivax!ss -- Wang Institute -- (617)649-9731
------------------------------
Date: 10 Aug 82 22:13:09-PDT (Tue)
From: decvax!pur-ee!purdue!cak at Ucb-C70
Subject: Re: pointer device report request
I seem to recall that there was an invited lecture by Allen Newell of
CMU at this year's Computer Science Conference (in Indianapolis) in
which he talked about research they (or someone else) performed
showing that the mouse was the lower bound for a pointing device; you
can't get better than one.
Sorry, but I don't have a more specific reference.
Chris Kent, Purdue CS
------------------------------
Date: 10 Aug 82 18:04:11-PDT (Tue)
From: decvax!duke!unc!smb at Ucb-C70
Subject: Paper on anti-aliasing
William Leler -- the author of the paper on "the Cheap 4000 line
display" -- is now at the University of North Carolina. His mailing
address is:
duke!unc!wm (uucp)
wm.unc@udel-relay (ARPA)
He's out of town at the moment, but is checking in to read his mail.
------------------------------
Date: 11 August 1982 0758-EDT (Wednesday)
From: Alan.Lesgold at CMU-10A (N981AL60)
Subject: mouse controllers
A friend of mine, Dick Wolf, has been building a variety of mouse
controllers for smaller microcomputer systems (e.g., ibm pc, apple,
s-100 bus). These allow attachment of the Hawley mouse to systems
otherwise unable to use them. In development are controllers with
greater intelligence, more modes of operation, and standard
interfacing (e.g., rs232). For information, contact Random Access,
Inc., 246 Highland Road, Pittsburgh, PA 15235.
------------------------------
Date: 11-Aug-82 12:01AM-EDT (Wed)
From: John Black <Black at YALE>
Subject: Menu systems
People have been talking as if menus were necessarily good
things, except that they might sometimes slow down expert users. I
submit that menus can also lead to worse performance than merely
allowing users to generate commands. This relates to an issue in
cognitive psychology called recognition failure of recallable words.
Menu systems rely heavily on recognition memory: i.e., you have to
look at the list of commands on a menu and recognize the appropriate
one. Without a menu, on the other hand, the user has to recall the
appropriate command.
Well, for a while psychologists thought that recognition was
always better than recall (i.e., that menu systems were better), but
then cases were found where people could recall something learned
earlier while failing to recognize it. This somewhat paradoxical
behavior occurs when the context in which a person is trying to
recognize something emphasizes a different perspective than that in
which the material was learned. Let me give an example using a
fictional text editor. Suppose this editor uses the standard sort of
terminology -- namely, insert, delete, replace, etc. Now, if a user
wanted to add a letter on the end of a word (e.g., make the word
plural), then he or she would probably have little trouble recalling
"insert" as the correct command. However, suppose the user was
confronted with the following menu:
insert
delete
replace
append
preface
Now the user might well fail to recognize the correct command --
probably even erroneously choosing "append." But surprise, append and
preface refer to adding lines to the end and beginning of a file. The
problem here is that the presence of append and preface on this menu
emphasize the meaning of insert as putting something in the middle
rather than as adding anything. Thus unless one is very careful it is
easy to design menus that users will find confusing in this way --
particularly, novice users that the menus are supposed to be so
helpful for. This example is simple, but the potential confusions are
not always so easy to see.
------------------------------
Date: 11 Aug 1982 22:31-EST
From: cak at Purdue
Subject: Menu Systems
I have good things to say about my past experience with menu systems,
but the application I was involved with was a little bit different
from what we've been discussing.
About 5 years ago, I worked on a menu-based system of applications to
help engineers to do their jobs better. The applications were
typically either database access routines (find the drawing number for
machine foo at plant bar that does grog) or calculations such as belt
length or a desk calculator -- they were all fill in the blanks, and
the computer fills some more in for you.
The applications were arranged in a tree-like structure; menus at
internal nodes, applications at the leaves. The system started you at
some level, usually within a menu. At this point, you could choose an
item on the menu by typing the number that appeared next to it, or
could go directly to any application or menu by typing in its name.
This was key to satisfying more experienced users. Once they knew
what they were doing, they could move around the tree very easily
(getting up a level was one keystroke). They didn't have to go down
the tree one level at a time, if they didn't want to.
Of course, these types of applications are different from typical
programming tasks. I'm not convinced that an analogous system can be
developed. Filling in the blanks for simple commands like "delete
this file" is a pain, once you know how to do it.
For example, National Semiconductor builds a microprocessor
development workstation called the Starplex; it provides menu front
ends for all the system commands, but has a command line processor as
well. If you type the command with no arguments, you get the menu.
That's pretty nice; we were able to sit down and use it right away,
without the manuals. Unfortunately, the command line syntax is so
cryptic that you end up using the menus all the time -- which is
unfortunate. (Actually, the only thing really nice about the Starplex
is the menu system; the rest is pretty painful. Microprocessor
companies are very much behind the current state of the software and
workstation art.)
Cheers,
chris
------------------------------
Date: 11 Aug 82 9:50:19-PDT (Wed)
From: decvax!harpo!ihps3!ihldt!ll1!jmr1 at Ucb-C70
Subject: RE: menus and commands
The system that you described regarding a menu driven system that
allowed the experienced user capability to by-pass the tedious
stepping through the menus sounds pretty nice....except...I wonder is
it really worth all the overhead it would cost to make it as flexible
as you say.
I'm one that believes in menus (what I like to refer to as intelligent
menus) to interface to users who should not be expected to understand
or learn commands and all their options (menus are ideal for use in
application systems), but......they do take-up a lot of overhead...
My feeling is that if it can be avoided menus should only be used as
interfaces to certain complex programs or tasks that require a lot of
options.
John Reese
ATT Long Lines
Chicago
------------------------------
End of WorkS Digest
*******************
-------