From: utzoo!decvax!ucbvax!works Newsgroups: fa.works Title: WORKS Digest V2 #72 Article-I.D.: ucbvax.8254 Posted: Wed Aug 11 01:23:14 1982 Received: Fri Aug 13 05:17:48 1982 >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 MankinsSubject: 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 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 ******************* -------