From: utzoo!decvax!ucbvax!works Newsgroups: fa.works Title: WORKS Digest V2 #73 Article-I.D.: ucbvax.8273 Posted: Thu Aug 12 22:21:24 1982 Received: Sun Aug 15 03:43:52 1982 >From PLEASANT@RUTGERS Thu Aug 12 22:07:08 1982 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 BlackSubject: 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 ******************* -------