works (08/11/82)
>From PLEASANT@RUTGERS Wed Aug 11 00:19:53 1982
Works Digest Wednesday, 11 August 1982 Volume 2 : Issue 72
Today's Topics:
Response to Queries - Pointer Device Report Request & Pixel,
References - Mice-&-Men & Resolution,
Languages - Ada on LISPM,
Display Resolution - Typography,
Menu Systems - Bandwidth Problems
----------------------------------------------------------------------
Date: 9 Aug 1982 17:45:26 EDT (Monday)
From: David Mankins <dm at BBN-RSM>
Subject: re: pointer device report request
To: hampton at acc
Two papers discussing selection of text using various pointer devices
(mouse, velocity joystick, light different flavors of function keys):
CARD:
Card, S.K., English, W.K. and Burr, B.J., "Evaluation of mouse,
rate-controlled isometric joystick, step keys, and text keys for text
selection on a CRT," in \Ergonomics/, 21, 8 (1978), pp. 601-613.
ENGL:
English, W.K., Engelbart, D.C., & Berman, M.L., "Display selection
techniques for text manipulation," \IEEE Transactions on Human Factors
in Electronics, HFE-8/, 1 (March 1976), pp. 5-15.
CARD, in summary (from a human factors tutorial I took at Siggraph):
for time to locate text:
mouse < velocity joystick < text keys < step keys
for errors in locating text:
mouse < text keys < joystick < step keys
learning improvement:
beginner expert
mouse 2.2s 1.3s
joystick 2.2s 1.6s
text keys 3.9s 1.9s
step keys 3.0s 2.3s
"Step keys" are the little arrow keys, up, down, left, right, one
step. "Text keys" are function keys "next word", "next paragraph",
"next page", etc.
ENGL, in summary:
For experienced users:
mouse < light pen < joystick (time)
mouse < light pen < joystick (errors)
For inexperienced users:
(mouse, light pen) < joystick (time)
mouse < light pen < joystick (errors)
The human factors guy didn't know of any studies comparing track balls
to mice, et. al.
------------------------------
Date: 10 Aug 1982 01:08:12-PDT
From: G.dag at Berkeley
Subject: Pixel
Pixel is put out by a company in Andover Mass called Instrumentation
Labs. I remember at one time (Marchish) seeing their system and being
un-impressed. The Unix implementation works rather well, but I did
not see it with many users. At the time, they were producing
relatively few and focusing much time on getting stuff out the door.
I do remember I was somewhat disproportionally upset with their
terminal...I believe it was 80 by 24 or 25 and looked kind of pretty,
but I don't think it had any function keys or any other additional
neat features. That's about all my foggy memory will tell me.
By the way, Pixel is a division of IL, as well as being put out by
them.
Good luck,
David Gewirtz
------------------------------
Date: 9 Aug 1982 1153-EDT
From: WITTMAN at RU-GREEN at RUTGERS
Subject: mice-&-men, resolution
The JULY Mini-Micro Systems magazine has a list of suppliers of
graphics equipment such as track-balls, mice, joysticks, etc - (Page
176, I think).
That issue also says a few words about resolution, more or less off
the cuff. (I believe it occurs in the discussion of 3-D simulation
and how to fool your brain).
Barry
------------------------------
Date: 8 Aug 1982 2316-EDT
From: Mark L. Miller <X.MILLER at MIT-OZ at MIT-AI>
Subject: Ada on LISPM
To: SSteinberg.Softwares at MIT-MULTICS
In reading over old WorkS mail, I noticed that you predicted that
someone would construct an Ada front end for the LISPM (as evidence
that LISPM's are not really limited to LISP at all). Purely as a
matter of information (and not for commercial gain), I thought it
might interest you to know that someone is. Computer*Thought
Corporation plans to have an Ada interpreter (via src-to-src
translation) within a few months, as one module of a larger project.
This would probably not be made available as a separate product unless
there were considerable interest. If interest were extreme, a
compiler and/or micro-code extensions might be developed as well. The
remarks about LISP's "semantic space" do indeed reflect some of the
considerations used in selecting the LISPM for our initial
implementation. (This is not to say that translation from Ada to LISP
is a simple matter!) I hope this contribution to the discussion helps
in understanding the unique benefits of LISPM-style workstations.
Anyone interested in more information about our projects or use of the
LISPM should probably contact me directly (214-424-3511) rather than
the whole list.
Regards, Mark
------------------------------
Date: 9 Aug 1982 08:43:20-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
Subject: Re: Display resolution
Heaven forfend that someone took my comments about typographers as
being slanderous!! The recent discussion about the inherent quality
decay through the reproductive processes forcing resolution are
clearly right. I was just trying to point out what the fundamental
physical limits of ink-on-paper resolution were. My comment about
"100-power magnifiers" intended to imply how demanding they are of
quality, not to ridicule them. As others have discovered, designing
beautiful typography is MUCH harder than you can imagine, and I have
the greatest respect and admiration for the people who make beautiful
fonts appear on the final page.
We have a graphics artists in residence here in CSAM and I will ask
him to submit some comments to this list.
-Mike
------------------------------
Date: 8 Aug 82 12:28:01-PDT (Sun)
From: decvax!utzoo!utcsrgv!utcsstat!wagner at Ucb-C70
Subject: Re: More on Menu Systems
I think the biggest problem with menu systems is display bandwidth
related. The first good menu system I used was SPF on channel
attached 3270s. The menus never got in the way - the data rate of such
a device is roughly half a megabyte per second. Try using the same
system at 4800 baud (i.e. about 500 chars/second - 3 orders of
magnitude slower) - suddenly I understood why the half of the computer
center located remotely couldn't stand SPF.
One of the features that ameliourates the problem a bit is a way of
stepping through common menu sequences without display of intermediate
menus. In SPF, if you remember where you want to go, you can
concatenate menu replies (sort of like UUCP routings - utzoo!decvax
means send to utzoo, having stripped off utzoo so the next guy will
re-read and send to decvax).
IMS is a menu based database system. One of the things you can do to
speed up menu response is run your remote terminal on a micro called a
system/3 (which supports 8 or so terminals and a line back to the
mainframe). In the morning, when IMS wakes up, it sends prototype
menus down the phone lines to all its system/3 sites, who store it
locally on disk or in memory (i don't remember which). Then, when IMS
feels the need to show the user menu X with fillins, menu X is
condensed to 3 characters from the more normal 100 or so, and flash!
up it goes. The fillins, of course, still go up slower. Too bad it
can't huffman encode them.
Enough.
Michael Wagner, UTCS
------------------------------
End of WorkS Digest
*******************
-------