From mimsy!oddjob!ncar!ames!husc6!cs.utexas.edu!ut-sally!gaigan!petree Sun Jul 24 21:40:43 EDT 1988 Article 541 of comp.cog-eng: Path: mimsy!oddjob!ncar!ames!husc6!cs.utexas.edu!ut-sally!gaigan!petree >From: petree@gaigan.cs.utexas.edu (Mitch Petree) Newsgroups: comp.cog-eng,comp.windows.misc Subject: Re: Using kinesthetic memory for human interfaces Summary: prefer last item chosen as default Message-ID: <12273@ut-sally.UUCP> Date: 3 Jul 88 21:11:35 GMT References: <3535@pdn.uucp> <5034@watcgl.waterloo.edu> Sender: news@ut-sally.UUCP Lines: 38 Xref: mimsy comp.cog-eng:541 comp.windows.misc:583 In article <5034@watcgl.waterloo.edu>, lrbartram@watcgl.waterloo.edu (lyn bartram) writes: > In article (Skip Montanaro) writes: > >Suntools remembers the last item selected in a menu and makes it the default > >the next time the menu is popped up. The bullseye could represent this > >dynamic default, not just a static default. It is easier to implement in > >some sense as well, since you don't have to decide ahead of time what the > > >default should be (and guess wrong most of the time). > I would think that in many cases the default position should be a "no op"/ > no selection on e, to permit a user to invoke the menu without being committed > to a decision. ... > does SunTools make the last menu item selected the default - by leaving > the positions of the items on the menu the same and placing the cursor on the > particular item, or by shuffling the items and having the default always in > the same place? Both approaches could be difficult in a radial selection menu. > If direction is the selection mechanism, then changing the cursor position > counteracts it; and shuffling the position of menu items conflicts with the > principle of using kinesthetic memory. > lyn bartram 1) I prefer SunTools method of using the last item chosen in a menu as the default next time the menu is called up. I have found that locality of reference applies in these situations (my experience only). 2) SunTools implements this by keeping the items in the same order and placing the cursor on the correct item. 3) This may be harder to do on a pie menu. I am not sure how pie menus work. What kind of selector do you use? Is it a knob that is turned or do you just have a pie shape and move the cursor into a slice? I can't see using a mouse to get direction except for direction of movement, whereas it sounds like you are talking about a static direction, i.e., the direction it is "looking". Just having the pie shape would be great because on the average you have to move a smaller distance to get to your selection. 4) I think the dead spot should be just that, a dead spot, like the title bar in a menu group. It could identify the menu group or be empty but would not invoke any function. -mitch petree (Univ. Texas @ Austin, Elec. & Comp. Engr.) From mimsy!oddjob!uwvax!rutgers!rochester!pt.cs.cmu.edu!ius3.ius.cs.cmu.edu!ralphw Sun Jul 24 21:41:29 EDT 1988 Article 542 of comp.cog-eng: Path: mimsy!oddjob!uwvax!rutgers!rochester!pt.cs.cmu.edu!ius3.ius.cs.cmu.edu!ralphw >From: ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) Newsgroups: comp.cog-eng Subject: Re: Pie submenus (again) Message-ID: <2156@pt.cs.cmu.edu> Date: 4 Jul 88 20:45:19 GMT References: <2147@pt.cs.cmu.edu> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 27 [let's try that again, this time with all the text...] For pie submenus, dealing with overlapping items might be a suitable use of color, if two or more appropriately non-interfering colors (as always, user-selectable with 'reasonable' defaults). If the distances between menus and submenus are small enough, it may be OK to use the 'stack of cards' approach, although this is the my personal most hated aspect of the user interface in the Andrew applications I use. You could also warp the mouse to the center of the submenu. submenu 2 / / 6\1/2 -- -- 5/4\3 Just remember to provide a good 'undo' for those whose 'muscle memory' forgets what to do over a long holiday break. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA From mimsy!haven!uflorida!ukma!psuvm.bitnet!cunyvm!byuvax!fordjm Mon Sep 12 10:18:34 EDT 1988 Article 610 of comp.cog-eng: Path: mimsy!haven!uflorida!ukma!psuvm.bitnet!cunyvm!byuvax!fordjm >From: fordjm@byuvax.bitnet Newsgroups: comp.cog-eng Subject: Educational Software Evaluation Methods? Message-ID: <239fordjm@byuvax.bitnet> Date: 4 Sep 88 23:35:32 GMT Lines: 24 I am preparing to conduct a formal evaluation of a piece of educational software that I have been working on. One thing I would like to do as part of this evaluation is to have the program keep a "LOG" file which records each student decision, the elapsed time between decsions, whether an option is chosen using the menu, window buttons, command keys, etc. (this is a Mac application), as well as various other types of information about the changing state of the program. Has anyone had experience doing this kind of tracking? Are there any particular things I should watch out for or be sure to include? I am also gathering posttest data on the students' mastery of the objectives addressed by the software (pretesting is not feasible) and I am observing each of their sessions. Are there any other particularly good evaluation methods for educational software that I should try? I am particularly interested in methods used to evaluate intelligent tutoring systems and other education-oriented AI applications. Please e-mail responses and I will summarize and post. John M. Ford From mimsy!dftsrv!ames!oliveb!bunker!eddie.MIT.EDU!rich Mon Sep 12 10:20:18 EDT 1988 Article 613 of comp.cog-eng: Path: mimsy!dftsrv!ames!oliveb!bunker!eddie.MIT.EDU!rich >From: rich@EDDIE.MIT.EDU (Richard Caloggero) Newsgroups: comp.terminals,comp.periphs,misc.wanted,misc.consumers,misc.misc,comp.edu,comp.misc,comp.org.decus,comp.cog-eng,comp.unix.questions Subject: Braille terminal wanted Keywords: Braille, Blind, Nonvisual, Desperate, Help Message-ID: <090888105451.Handicap.News> Date: 7 Sep 88 19:27:32 GMT Sender: wtm@bunker.UUCP Organization: MIT EE/CS Computer Facility, Cambridge, MA Lines: 66 Xref: mimsy comp.terminals:964 comp.periphs:1250 misc.wanted:4286 misc.consumers:10394 misc.misc:4570 comp.edu:1420 comp.misc:3547 comp.org.decus:327 comp.cog-eng:613 comp.unix.questions:9598 NOTE: This article was sent to misc.handicap and I am posting it on behalf of Richard Caloggero to the other groups. Please be sure that your replies go to Richard (rich@EDDIE.MIT.EDU> and not me. Thanks, Bill McGarry, moderator of misc.handicap [** If this ends up in an inappropriate newsgroup, I sincerely apologize. **] I am a blind computer scientist, and I need information on the existance and availability of braille terminals (I'm not much interested in hard-copy devices). The following is a description of the one I'm currently using. It is, to my knowledge, the only device of its kind which has proven robust enough to withstand *normal* use, and is therefore the only device of its kind generally available today. After reading the description, you'll know why I'm desperately looking for an alternative. * - - - - - - - - - - - - - - - - - - - -* THE VERSABRAILLE II TELESENSORY SYSTEMS, inc. DISPLAY * Description: A soft-copy braille display. Uses piezo-electric crystals to drive small pins through a grid of wholes on the top of the device. * Lines/Page: 1 * Columns/Line: 20 * Comment: It tries to be smart about parsing the output into _words_, and will not break a word unless it is longer than 20 characters. Its still unreasonable though!!!!!! How would you like to read "someone else's" C program, three words at a time!!!!!!? GENERAL CAPABILITIES * Dumb terminal emulation * Software-settable communications parameters * Local intelligence -- maintains simple filesystem in local ram and floppy * Cpu: 8-bit something-or-other -- can run programs, but can't generate them locally; must form executable image (cp/m I think) and then nownload * --lots of other useless bells and whistles-- * PRICE: (unreasonable) -- $6,000.00+. * - - - - - - - - - - - - - - - - - - - -* In general, I'm looking for a larger display (doesn't have to be full sized 24x80). I don't realy care how *intelligent* it is; a dumb terminal is fine for me. Please send any responses directly to me at the address below. Also indicate whether you are interested in seeing a summary of my findings (either sent directly to you, or posted to the net). Thanx to all who take the time to read this. If you don't know anything about this stuff, but feel you know someone else who does, please please forward this to them. -- -- Rich (rich@eddie.mit.edu). The circle is open, but unbroken. Merry meet, merry part, and merry meet again. From mimsy!dftsrv!ukma!gatech!hubcap!ncrcae!ncrlnk!rd1632!king Thu Dec 8 21:03:08 EST 1988 Article 674 of comp.cog-eng: Path: mimsy!dftsrv!ukma!gatech!hubcap!ncrcae!ncrlnk!rd1632!king >From: king@rd1632.Dayton.NCR.COM (James King) Newsgroups: comp.cog-eng Subject: Similarity Metrics: Reminding, Retrieval, CBR, etc. Keywords: user interface computers complexity visualization control Message-ID: <577@rd1632.Dayton.NCR.COM> Date: 1 Dec 88 20:36:49 GMT References: <2250@kalliope.rice.edu> Reply-To: king@rd1632.Dayton.NCR.COM (James King) Organization: R&D, NCR Corp., Dayton, Ohio Lines: 64 SIMILARITY ... What does it mean? for ANALOGY What are the measures? for REMINDING Are there generalities or is it domain-specific? for EXEMPLARS ... Etc. Etc. I am performing independent research in the area of Case-Based Reasoning, CBR, and I am working on various metrics for similarity. In general, what ideas do you (the net-world) have about: - What about a new situation reminds you of a prior experience? - OR - How does one situation remind you of another? This is obviously a (too) wide open question and requires some clarity, but I would rather not focus the discussion to a set of examples yet. That is, unless it is more productive to do so. A little more focus might be how does one discriminate and weight features of a new situation (case) in relationship to a large case-base of experiences that may or may not have a bearing on the new situation. Did that provide more focus or fuzziness!? I send this notice out as a preliminary "attention-getter" to provide myself with some input to help form a more formal survey. Once written I hope to send it to a specific set of researchers (consisting mostly of people in the CBR, information retrieval (IR), doc. mngt. areas) and to anyone in netland that requests so. My goals are to: - Produce some consensus of opinion on a view, or approach(es), to similarity and the possibility of codifying it to aid in reminding and retrieval of prior experiences. - ALSO: I wish to propose to Dr. Katz at MITRE that a workshop be held at IJCAI-89 which would address/discuss this area of concern. If anyone is interested in adding support or input please let me know. (We held a lively workshop on CBR at AAAI-88, and I believe a focused workshop in a specific area that would benefit CBR researchers as well as IR, AI, etc. is important.) If anyone is interested in responding to any of this: - I will watch the "nets" for replies - Email to: j.a.king@dayton.ncr.com - Call: (513)-445-1090 before 4:30 (EST) (317)-478-5910 after 6:00 - Mail: NCR Corp. 1700 S. Patterson WHQ-5E Dayton, OH 45479 After listening, talking to people, etc. for the next couple weeks I will write up the survey (anyone can help form the survey) over Christmas and send it out the first week in January. By February-March (15th?) I will hopefully be able to publish preliminary results (to the net, respondents, etc.). I am fairly familiar with the discussions of similarity by Kolodner, Schank, Rissland, Porter and others in the CBR field - also from the IR field, Fox, Croft, Salton, etc. I have built one CBR system and two applications where the similarity metric was determined from the experts. BUT ... I am open to anyone's suggestions on reference works for understanding similarity metrics, methodologies, etc. Thank you for your time. Jim King From mimsy!dftsrv!ukma!cwjcc!gatech!ncsuvx!lll-winken!uunet!mcvax!ukc!strath-cs!glasgow!jack Mon Jan 2 00:34:04 EST 1989 Article 788 of comp.cog-eng: Path: mimsy!dftsrv!ukma!cwjcc!gatech!ncsuvx!lll-winken!uunet!mcvax!ukc!strath-cs!glasgow!jack >From: jack@cs.glasgow.ac.uk (Jack Campin) Newsgroups: comp.cog-eng Subject: Re: Voice Interface Message-ID: <2179@crete.cs.glasgow.ac.uk> Date: 30 Dec 88 17:43:42 GMT References: <7015@ems.Ems.MN.ORG> Reply-To: jack@cs.glasgow.ac.uk (Jack Campin) Organization: COMANDOS Project, Glesga Yoonie, Unthank Lines: 29 Summary: Expires: Sender: Followup-To: Keywords: One idea I have long been curious about in this area: has anyone tried to do an acoustic "window" manager? Spatial location can be faked by shifting the phase of the output between the left and right ears; differently pitched voices could be used to provide a second dimension, so mouse or trackball movements would map onto a "screen" with maybe twenty "windows", like: soprano soprano soprano soprano soprano FAR FAR alto alto alto alto alto LEFT RIGHT tenor tenor tenor tenor tenor bass bass bass bass bass Perhaps reinforce the phase separation by using synthesizers with different accents, too? It's not obvious what the best way to indicate focus is in this scheme - maybe by adding a tone when not focused on any one window, which would stop when you clicked to select the window you wanted? Such a tone could encode spatial information itself - cavernous echoes when in big directories? "cd /flute/bagpipes/breaking_glass"? Comments from any blind programmers out there? How much can we reasonably ask trained human ears to do? -- ARPA: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk USENET: jack@glasgow.uucp JANET:jack@uk.ac.glasgow.cs useBANGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack Mail: Jack Campin, Computing Science Dept., Glasgow Univ., 17 Lilybank Gardens, Glasgow G12 8QQ, SCOTLAND work 041 339 8855 x 6045; home 041 556 1878 From mimsy!tank!uwvax!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!weh Thu Jan 5 04:27:22 EST 1989 Article 802 of comp.cog-eng: Path: mimsy!tank!uwvax!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!weh >From: weh@sei.cmu.edu (Bill Hefley) Newsgroups: comp.cog-eng Subject: Re: replacing the desktop metaphor (Why any metaphor?) Summary: Dual Mode Interfaces can work! Message-ID: <8092@aw.sei.cmu.edu> Date: 2 Jan 89 16:29:39 GMT References: <850@mtfmi.att.com> <673@cogsci.ucsd.EDU> <1489@umbc3.UMD.EDU> <22616@pbhya.PacBell.COM> <66401@ti-csl.CSNET> <4510@xenna.Encore.COM> <4455@Portia.Stanford.EDU> Sender: netnews@sei.cmu.edu Reply-To: weh@bu.sei.cmu.edu.UUCP (Bill Hefley) Organization: Carnegie-Mellon University, SEI, Pgh, Pa Lines: 50 In article <4455@Portia.Stanford.EDU> rdsesq@Jessica.stanford.edu (Rob Snevely) writes: >The issue is not ease of use, the issue is how effectively a person can >use a program as a tool to make his/her life or job better or easier. Agreed! >So I propose both, >why cant we have a word processor that has two interfaces. A "user-friendly" >pull down menu -- dialog based interface for new users. and a command >oriented interface for advanced users. This would allow those users who >want or need a command oriented interface access to it while allowing >new or intermediate users to have the point and click. Also since the >menu interface would be around all the time, it would help to eliminate >the problems of going from on to the other cause they are interchangable. A couple of years ago, I led a team of folks developing a window-based user interface (roughly 1000 x 800 pixel resolution, on a 16" high by 10" wide monochrome display) for a process control application. We found that a hierarchical menu structure, closely coupled with a command line interface, was very straight-forward for our target user population to deal with -- both novice and more experienced operators. To reinforce the coupling of the dual modes (as well as an training aid), the command line displayed the equivalent of each menu selection. We incorporated a fixed-function key that allowed backtracking. The single shortfall (in our minds) was that we had to add an extra acknowledge action at the end of every command to ensure that the operator was ready to execute (and did not want to backtrack). By the way, other software packages with similar capability that I've seen also have had to do this (see the Search dialog in Pro-Cite's bibliography package for the Mac, as an example.) For a picture of our interface, see Marken's paper (pp. 1026-1030) in the Proceedings of the 1988 Human Factors Society Annual Meeting. The two windows are refered to as "Menu Viewport" and "Directive" in his Figure 1. ____ ______ _____ _____===== Bill Hefley / __ \ | _____| |_ _| _____========= Software Engrg Institute | |__|_| | |__ | | _____============= Carnegie Mellon _\___ \ | __| | | _____================= Pittsburgh, PA 15213 | |__| | | |____ _| |_ _____============= (412) 268-7793 \____/ |______| |_____| _____========= ARPA: weh@sei.cmu.edu -----===== BITNET: weh%sei.cmu.edu CSNET: weh%sei.cmu.edu@ relay.cs.net C a r n e g i e M e l l o n U n i v e r s i t y +---------------------------- Disclaimer -------------------------------+ | The views expressed herein are my own and do not necessarily reflect | | those of my employer. | +-----------------------------------------------------------------------+ From mimsy!dftsrv!ames!pasteur!ucbvax!decwrl!decvax!tektronix!sequent!mntgfx!msellers Fri Jan 6 23:44:27 EST 1989 Article 829 of comp.cog-eng: Path: mimsy!dftsrv!ames!pasteur!ucbvax!decwrl!decvax!tektronix!sequent!mntgfx!msellers >From: msellers@mntgfx.mentor.com (Mike Sellers) Newsgroups: comp.cog-eng Subject: A real-world user interface example (was: Re: replacing the desktop ...) Summary: menus, commands, aliases, etc.; not a plug -- just one case in point Message-ID: <1989Jan5.224743.8165@mntgfx.mentor.com> Date: 6 Jan 89 06:47:40 GMT References: <850@mtfmi.att.com> <673@cogsci.ucsd.EDU> <1489@umbc3.UMD.EDU> <8092@aw.sei.cmu.edu> Organization: Mentor Graphics Corporation, Beaverton Oregon Lines: 110 In article <8092@aw.sei.cmu.edu>, weh@sei.cmu.edu (Bill Hefley) writes: > In article <4455@Portia.Stanford.EDU> rdsesq@Jessica.stanford.edu > (Rob Snevely) writes: > >The issue is not ease of use, the issue is how effectively a person can > >use a program as a tool to make his/her life or job better or easier. > > Agreed! Yes. It is often not easy to make a user interface that allows for users that may be completely expert, completely novice, or some of both depending on the task that also does not get in their way or increase their "cognitive load" (which I define as the extra attention spent on thinking about using a tool instead of just using it). Couple this with users who may be anywhere from novice to expert in their native task domain but who may also have a very different level of computer usage expertise, and you can get into some very tricky situations. (On top of all this, of course, is the fact that the company I work for is selling their products for money, so we can't just say "oooops! well they sure didn't like that one -- let's try again next year." :-) Sometimes I sure wish we could, but then I guess that's what grad school is for...) >> So I propose both, >> why cant we have a word processor that has two interfaces. A "user-friendly" >> pull down menu -- dialog based interface for new users. and a command >> oriented interface for advanced users. This would allow those users who >> want or need a command oriented interface access to it while allowing >> new or intermediate users to have the point and click. Also since the >> menu interface would be around all the time, it would help to eliminate >> the problems of going from on to the other cause they are interchangable. > > A couple of years ago, I led a team of folks developing a window-based user > interface (roughly 1000 x 800 pixel resolution, on a 16" high by 10" wide > monochrome display) for a process control application. We found that a > hierarchical menu structure, closely coupled with a command line interface, > was very straight-forward for our target user population to deal with -- > both novice and more experienced operators. To reinforce the coupling of > the dual modes (as well as an training aid), the command line displayed the > equivalent of each menu selection. We incorporated a fixed-function key > that allowed backtracking. The single shortfall (in our minds) was that we > had to add an extra acknowledge action at the end of every command to ensure > that the operator was ready to execute (and did not want to backtrack). > By the way, other software packages with similar capability that I've seen > also have had to do this (see the Search dialog in Pro-Cite's bibliography > package for the Mac, as an example.) > > For a picture of our interface, see Marken's paper (pp. 1026-1030) in the > Proceedings of the 1988 Human Factors Society Annual Meeting. The two > windows are refered to as "Menu Viewport" and "Directive" in his Figure 1. > > ____ ______ _____ _____===== Bill Hefley We have implemented (and have been selling since early '88) a product that uses these ideas and many others. What I find remarkable is that these ideas seem to be somewhat (r)evolutionary, both to other engineers and to our customers (and by the looks of these messages, somewhat to others as well). If there are other good real-world examples of things that have been implemented and are being used, I'd sure like to hear about them (nothing confidential, of course). In my case, briefly, Mentor Graphics Package Station (a 3D Wireframe Editor and Thermal Analysis Tool, etc. -- runs on Apollo workstations) has a user interface where commands may be entered by using a hierarchical menu system, by typing in keyword phrases, by typing in 4-letter acronyms, by using function keys, or by using a tablet menu. These seem to cover all the bases real well (without assuming continuous speech processing), and seem to work well for users at every different level. The "arguments" to any given command are brought up on a "prompt bar" that uses both text and graphic prompts to get the information needed. The user can tab back and forth across these fields as they choose until they are all filled in (some have defaults, and others are dialog box-like things); a carriage-return is used to signal that the user is ready to have the command executed. Also significant is that you can bring up any command while filling out the prompts for any other command -- so the output from one can be the input to another. Commands can be stacked real deep (up to 8 or 10 I think); you have to try this to really understand how much easier it makes execution of complex tasks, since you don't lose the data for one command when executing another. On-line help is available in several different forms; one way is to get help on a specific command, and you can use any of the above methods to choose the command to get help on. The menus are arranged across the top of the screen, and have no more than 9 entries per menu (most have far fewer). Almost all are no more than 2 levels deep, and none are more than four levels deep. The keyword phrases are nearly the full names of the command (usually multiple words), and the acronyms follow a completely consistent set of rules for their generation (I don't happen to like the rule set much myself, but our customers seem to like it a lot -- I think in a case like this almost *any* consistency is better than none!). Users can also rename commands as they choose, and make up their own using our macro language. In my mind one of the few things lacking in this scheme is a set of rules for trying to find a command by what the user has typed in, even if incorrectly. We checked into this (using Soundex or something similar), but it turned out to be pretty much overkill. The reports we get back indicate users of other systems have cut training time (to where they can navigate and use the system with a high degree of confidence) by as much as an order of magnitude over some other systems. Anyway, that's my real-world example. The product was highlighted in several industry magazines last spring; I can provide more info if you're interested. Disclaimer: This information is factual to the best of my knowledge, but is solely my opinion and not that of Mentor Graphics or anyone else. -- Mike Sellers ...!tektronix!sequent!mntgfx!msellers Mentor Graphics Corp. msellers@mntgfx.MENTOR.COM Electronic Packaging and Analysis Division "If we pull this off, we'll eat like kings!" From mimsy!haven!purdue!decwrl!hplabs!hp-sdd!ncr-sd!ncrlnk!rd1632!king Fri Jan 13 03:20:46 EST 1989 Article 872 of comp.cog-eng: Path: mimsy!haven!purdue!decwrl!hplabs!hp-sdd!ncr-sd!ncrlnk!rd1632!king >From: king@rd1632.Dayton.NCR.COM (James King) Newsgroups: comp.cog-eng Subject: Second SIMILARRITY METRICS Posting Message-ID: <595@rd1632.Dayton.NCR.COM> Date: 12 Jan 89 15:56:14 GMT Reply-To: king@rd1632.Dayton.NCR.COM (James King) Organization: R&D, NCR Corp., Dayton, Ohio Lines: 64 *** SECOND POSTING ON SIMILARITY METRICS *** About a month ago I posted a request for information, and interest, in the area of "similarity metrics". I am posting a second call for information now with the hope of furthering my base of understanding, and also to develop a base for the semi-formal survey I will be sending all respondents (this will be out in a week or so). I have received feedback from about thirty people. Most of the respondents have described their interests in this area, and many have provided abstractions of their methods for measuring similarity. This is very encouraging and I hope it continues. The survey will also be sent to a sizeable number of researchers that I know of already. My hope is to make this a cross-discipline study that provides insight from the Case-Based Reasoning, Analogical Reasoning, EBL, Information Retrieval, Behavioral Studies, Machine Learning, Child Psychology, etc. fields. At present a proposal for holding a workshop on this topic at IJCAI has been decided against. The topic may be presented as a panel discussion at a focused Case-Based Reasoning Workshop this year. --------------------- Original (edited) posting follows ------------------- SIMILARITY ... What does it mean? for ANALOGY What are the measures? for REMINDING Are there generalities or is it domain-specific? for EXEMPLARS ... Eliciation strategies, cues, weights, features, etc. I am performing independent research in the area of Case-Based Reasoning, CBR, and I am working on various metrics for similarity. In general, what ideas do you (the net-world) have about: - What about a new situation reminds you of a prior experience? - OR - How does one situation remind you of another? A little more focus might be how does one discriminate and weigh features of a new situation (case) in relationship to a large case-base of experiences that may or may not have a bearing on the new situation. Did that provide more focus or fuzziness!? This notice is sent out as a preliminary "attention-getter" to provide myself with some input to help form a more formal survey. Once written I hope to send it to a specific set of researchers (consisting mostly of people in the CBR, information retrieval (IR), doc. mngt. areas) and to anyone in netland that requests so. If anyone is interested in responding to any of this: - I will watch the "nets" for replies - Email to: j.a.king@dayton.ncr.com - Call: (513)-445-1090 before 4:30 (EST) (317)-478-5910 after 6:00 - Mail: NCR Corp. 1700 S. Patterson WHQ-5E Dayton, OH 45479 The survey will be finished and sent in the next week or two, so please let me know of your interest and what YOU might like to get out of such a study. Thank you for your time. Jim King From mimsy!tank!ncar!ames!ucsd!sdcsvax!ucsdhub!sdsu!munin!ucselx.uucp!maxc0186 Sat May 20 00:57:19 EDT 1989 Article 1133 of comp.cog-eng: Path: mimsy!tank!ncar!ames!ucsd!sdcsvax!ucsdhub!sdsu!munin!ucselx.uucp!maxc0186 >From: maxc0186@ucselx.uucp Newsgroups: comp.society.futures,comp.cog-eng Subject: The Ultimate User Interface Message-ID: <3782@munin.UUCP> Date: 18 May 89 21:53:38 GMT Sender: news@munin.UUCP Reply-To: maxc0186@ucselx.uucp () Organization: San Diego State University Lines: 47 Xref: mimsy comp.society.futures:1404 comp.cog-eng:1133 The Way of the Disk Seeker As he sat staring at the video screen, his brain waves synchronizing with the screen's refresh rate, he struggled with the koan that the Master Control Program had presented to him just days before. He hadn't moved from his contoured chair with its adjustable backrest since the words appeared on his screen. "What is the number obtained on a divide by zero?" He knew that koans had no explainable answer and the answer was not the important thing but still he had doubts. He could see the flicker interval increasing, or so it seemed, until the screen just drew a blank. Then it dawned on him that he couldn't remember his name or where he was. Without even willing it, his hands made their way to the keyboard and began typing the word "whoami". It was as if he'd become a peripheral device for some unconscious power. He wasn't really typing - 'It' was. He sensed the scanning electron beam projecting itself beyond the phosphor behind the glass to the back of his eyeballs, to his brain, probing the source of his thoughts, etching the System's reply in gray matter. "To name a name is to delimit a 'thing'". He didn't have to read the words. He wasn't sure if they really were words. He could feel his impulse response racing to infinity in what seemed like an eternity. He saw the poles and zeros shifting in the s-plane as the singularity engulfed him. All distinctions between mind and body, hardware and software, user and system disappeared as he became one with the System. As he slowly settled into the steady state, a delicious smile crept on his lips. All at once he knew. He had reached Cyberspace. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The purpose of a fish trap is to catch fish, and when the fish are caught, the trap is forgotten. The purpose of a rabbit snare is to catch rabbits. When the rabbits are caught, the snare is forgotten. The purpose of words is to convey ideas. When the ideas are grasped, the words are forgotten. Where can I find a man who has forgotten words? He is the one I would like to talk to." -Chuang Tzu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= MOS: Message Oriented Systems The medium is the message; You are the object. Or is it the other way around? From mimsy!cvl!haven!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!ukc!mucs!alan Sat Jun 10 06:18:22 EDT 1989 Article 1177 of comp.cog-eng: Path: mimsy!cvl!haven!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!ukc!mucs!alan >From: alan@ux.cs.man.ac.uk (Alan Wills) Newsgroups: sci.psychology,comp.cog-eng Subject: Re: navigating through menus with colour Message-ID: <6295@ux.cs.man.ac.uk> Date: 8 Jun 89 15:21:26 GMT Organization: Dept. of Computer Science, University of Manchester, UK. Lines: 35 Xref: mimsy sci.psychology:2200 comp.cog-eng:1177 In-reply-to: perlman@tut.cis.ohio-state.edu's message of 6 Jun 89 04:51:49 GMT In article <572@hfserver.hfnet.bt.co.uk> davet@hfserver.hfnet.bt.co.uk (David Travis) writes: >Options are recalled by their approximate >spatial position in the menu. One way of making the most of this is to make your menu octagonal. The menu appears centred on the cursor; you select by wiping outwards in the appropriate direction. So it looks rather like this (but I can only draw a hexagonal one in ascii!): /----------\ / \ item1 / \ / i6 \____ /i2 \ ------____ ----- \ / \i3 / \ / i4 \ / \----------/ The centre is a "next 8 options" button, for when there are more than 8 items in the menu (so when you get used to a particular menu, you know to click twice for a particular item); but a better practice is to nest menus and cascade them. After a while, users get fast at the sequence of clicks and wipes needed for a familiar item: the system has to be able to cope with users going through them quickly. Lon Barfield at Manchester invented this. I think there's a local report on it, which I can look out for anyone interested. Alan Wills 061-275 6135 Dept of Computer Science University of Manchester M13 9PL -- Alan Wills +44-61-273 7121 x5699 From mimsy!brillig.umd.edu!don Fri Sep 29 21:39:15 EDT 1989 Article 1364 of comp.cog-eng: Path: mimsy!brillig.umd.edu!don >From: don@brillig.umd.edu (Don Hopkins) Newsgroups: comp.cog-eng Subject: Re: Menu Interaction Techniques Summary: "touch typing" with pie menus Keywords: mouse ahead, pie menus Message-ID: <19812@mimsy.UUCP> Date: 26 Sep 89 23:22:46 GMT References: <2722@trantor.harris-atd.com> <16179@brunix.UUCP> Sender: nobody@mimsy.UUCP Reply-To: don@brillig.umd.edu.UUCP (Don Hopkins) Organization: U of Maryland, Dept. of Computer Science, Lines: 150 In article <16179@brunix.UUCP> jhc@iris.brown.edu (James H. Coombs) writes: >In article <2722@trantor.harris-atd.com> chuck@melmac.harris-atd.com >(Chuck Musciano) writes: > >> I contended that each menu usage would require a visual >> search and explicit select action, making it harder to use. > >I have seen no research on this, so I will offer an observation. I >frequently find that I select the wrong item or no item at all when >I attempt to select from a menu without focusing my vision on the >desired item. I have not experienced the equivalent of touch typing >with menu selection. D. A. Norman is right on target: menus are >optimized for selection but pessimized for performance. > >--Jim > "Mouse ahead" (the mouse equivalent of "touch typing") works very well with pie menus. Since each pie menu item is in a different direction from the cursor, you can make a menu selection very quickly without looking at the menu, if you know which direction it's in. Linear menus require your visual attention, because they depend on the distance you move the cursor, and you can't tell that for sure without looking. Pie menus just depend on the direction of movement, with the added advantage that you can move the cursor out further in whatever direction to get more angular precision (pie slices are much wider on the outside of the pie than in the middle). I found that mousing ahead into familiar pie menus was so easy, that I implemented "mouse ahead display supression", where the display of menu is supressed if you complete a selection fast enough. This feature really speeds up interaction with commonly used menus, such as the menu of window managment functions. If you know the direction of the item you want, then there is no need to see the menu, and it really slows down interaction for the computer to pop it up, paint it, and pop it right back down, after you've already completed the selection. I use pie menus regularly, and I can make menu selections reliably and quickly from a reasonably sized pie menu (8 items is /very/ reasonable), even with my eyes closed. Pie menu interaction is very gestural, and the layout of the items in a pie menu can be designed to take good advantage of muscle memory. Of course, muscle memory only helps you with static menus. When the number of items in a pie menu change, the direction you have to move the cursor to select each item changes. I agree with Chuck, especially in the case of pie menus, that muscle memory really helps speed up interaction with static menus, but muscle memory works against you with dynamic menus. Enclosed is a blurb about pie menus. If you would like to try them out first hand (the only way to really know what they're like), I'd be glad to send you the PostScript source code that implements them for the NeWS window system, along with a window manager designed to take advantage of pie menus. My implementation is in the public domain, and freely redistributable. The idea is not patented or proprietary, and I encourage you to implement them for your favorite toolkit; just send me some mail, and I'll share with you what I've learned. -Don Directional Selection is Easy as Pie Menus! Don Hopkins University of Maryland Human Computer Interaction Lab College Park, MD 20742 (301) 454-1517 Simple Simon popped a Pie Men- u upon the screen; With directional selection, all is peachy keen! The choices of a Pie Menu are positioned in a circle around the cursor, instead of in a linear row or column. The choice regions are shaped like the slices of a pie. The cursor begins in the center of the menu, in an inactive region that makes no selection. The target areas are all adjacent to the cursor, but in a different directions. Cursor direction defines the choice. The distance from the menu center to the cursor, because it's independent of the direction, may serve to modify the choice. The further away from the Pie Menu center the cursor is, the more precise the control of the selection is, as the Pie slice widens with distance. With familiar menus, choices can be made without even seeing the menu, because it's the direction, not the distance, that's important. "Mousing ahead" with Pie Menus is very easy and reliable. Experienced users can make selections quickly enough that it is not actually necessary to display the menu on the screen, if the mouse clicks that would determine the selection are already in the input queue. The circular arrangement of Pie Menu items is quite appropriate for certain tasks, such as inputing hours, minutes, seconds, angles, and directions. Choices may be placed in intuitive, mnemonic directions, with opposite choices across from each other, orthogonal pairs at right angles, and other appropriate arrangements. Pie menus have been implemented for uwm, a window manager for X-Windows version 10, for the SunView window system, and for NeWS, Sun's extensible PostScript window system. Don Hopkins did the uwm and NeWS implementations, and Mark Weiser did the SunView implementation. Jack Callahan has shown Pie Menus to be faster and more reliable than linear menus, in a controlled experiment using subjects with little or no mouse experience. Three types of eight-item menu task groupings were used: Pie tasks (North, NE, East, etc...), linear tasks (First, Second, Third, etc...), and unclassified tasks (Center, Bold, Italic, etc...). Subjects were presented menus in both linear and Pie formats, and told to make a certain selection from each. They were able to make selections 15% faster, with fewer errors, for all three task groupings, using Pie Menus. Ben Shneiderman gave advice on the design of the experiment, and Don Hopkins implemented it in Forth and C, on top of the X-Windows uwm. The disadvantage of Pie Menus is that they generally take up more area on the screen than linear menus. However, the extra area does participate in the selection. The wedge-shaped choice regions do not have to end at the edge of the menu window -- they may extend out to the screen edge, so that the menu window only needs to be big enough to hold the choice labels. Proper handling of pop-up Pie Menus near the screen edge is important. The menu should idealy be centered at the point where the cursor was when the mouse button was pressed. If the menu must be moved a certain amount from its ideal location, so that it fits entirely on the screen, then the cursor should be "warped" by that same amount. Pie Menus encompass most uses of linear menus, while introducing many more, because of their extra dimension. They can be used with various types of input devices, such as mice, touch pads, graphics tablets, joysticks, light pens, arrow keypads, and eye motion sensors. They provide a practical, intuitive, efficient way of making selections that is quick and easy to learn. And best of all, they are not proprietary, patented, or restricted in any way, so take a look and feel free! References: Pies: Implementation, Evaluation, and Application of Circular Menus By Don Hopkins, Jack Callahan, and Mark Weiser (Paper in preparation. Draft available from authors.) A Comparitive Analysis of Pie Menu Performance. By Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman. Proc. CHI'88 conference, Washington D.C.: available from ACM, NY. A Pie Menu Cookbook: Techniques for the Design of Circular Menus By Don Hopkins (Paper in preparation. Draft available from author.) From mimsy!tank!ncar!ames!uakari.primate.wisc.edu!ginosko!uunet!pyrdc!lighthouse!rock Fri Sep 29 21:42:30 EDT 1989 Article 1365 of comp.cog-eng: Path: mimsy!tank!ncar!ames!uakari.primate.wisc.edu!ginosko!uunet!pyrdc!lighthouse!rock >From: rock@lighthouse.com (Roger Rock Rosner) Newsgroups: comp.cog-eng Subject: Re: Menu Interaction Techniques Message-ID: <1989Sep27.192121.2537@lighthouse.com> Date: 27 Sep 89 19:21:21 GMT References: <2722@trantor.harris-atd.com> <16179@brunix.UUCP> <19812@mimsy.UUCP> Organization: Lighthouse Design, Ltd. Lines: 25 In-reply-to: don@brillig.umd.edu's message of 26 Sep 89 23:22:46 GMT In article <19812@mimsy.UUCP>, don@brillig.umd.edu (Don Hopkins) writes: >Proper handling of pop-up Pie Menus near the screen edge is important. >The menu should idealy be centered at the point where the cursor was >when the mouse button was pressed. If the menu must be moved a certain >amount from its ideal location, so that it fits entirely on the screen, >then the cursor should be "warped" by that same amount. I am quite excited about this idea of Pie Menus, but I must disagree with the above point. Admittedly I have no background in this subject, but I (and, it seems, Apple and NeXT) consider "warping" the mouse an egregious user interface sin. Optimizing for "muscle memory" would seem to preclude automatically relocating the mouse (although partially obscured Pie Menus are probably not so great either). Roger Rosner Lighthouse Design, Ltd. Usenet: ...!uunet!lighthouse!rock Internet: rock@lighthouse.com US mail: 7100 Edgevale Street Chevy Chase, MD 20815-5906 Phone: 301-907-4621 From mimsy!tank!ncar!ames!pacbell!pbhyg!ria Fri Sep 29 21:44:30 EDT 1989 Article 1367 of comp.cog-eng: Path: mimsy!tank!ncar!ames!pacbell!pbhyg!ria >From: ria@PacBell.COM (Richard I Anderson) Newsgroups: comp.cog-eng Subject: Re: Menu Interaction Techniques Message-ID: <1788@pbhyg.PacBell.COM> Date: 27 Sep 89 18:13:35 GMT References: <2722@trantor.harris-atd.com> Reply-To: ria@PacBell.COM (Richard I Anderson) Organization: Pacific * Bell, San Ramon, CA Lines: 87 In article <2722@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: > > I am currently in the midst of a quandary involving two different >menu interaction techniques, and I was wondering if there is anything in the >literature regarding either of the following two hypotheses. > > I have been of the opinion that menus used in an interface should remain >"static": the position and contents of the menu should not change over the >course of using the interface. ... A relevant study is reported in: Mitchell, J. & Shneiderman, B. (April, 1989) Dynamic versus static menus: An exploratory comparison. SIGCHI Bulletin, 20 (4), 33-37. This study did NOT investigate menus that changed in accordance with context, but it did look at menus that changed versus menus that did not. Ablex is publishing a book by Kent Norman entitled, "The psychology of menu selection..."; I would hope that it addresses the issues of concern to you. I collected some somewhat relevant data via usability testing I did early this year. Menu item position did not change in accordance with context, but cursor placement within the menu did. The initial "qualitative" analysis suggested that this change prompted user confusion. However, subsequent examination of the tapes and preliminary quantitative analyses suggest that the detected confusion may have actually been due to design weaknesses encountered earlier and that the changing cursor placement was significantly beneficial. Jonathon Grudin has a nice discussion about such menus in: Grudin, J. (January, 1989) The case against user interface consistency (Technical Report Number ACA-HI-002-89) Austin, TX: Microelectronics and Computer Technology Corporation. In article <2722@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes: > ... I was under the impression that menu usage >becomes an instance of "gesturing" or "stroking" and the cognitive loading >is moved into the "muscle memory" of the user. In article <618@cs.yale.edu> engelson@cs.yale.edu (Sean Engelson) writes: >Supposedly there's been some research that's shown that pie-menus >(menus with selections in wedges around a circle) allow muscular >memory to take over. My experience with pie-menus under NeWS bore >this out ... Aah - muscle memory again. Don Norman talked about muscle/motor memory the last time this topic surfaced here. I happened to have saved his words: >From: norman@sdics.ucsd.EDU (Donald A. Norman) Newsgroups: comp.cog-eng Subject: Re: A Dvorak keyboard experiment Date: 24 Jun 88 17:10:56 GMT Organization: UC San Diego Institute for Cognitive Science ... Do not get too excited about the advantages of "motor memory." Nothing special about "motor." The same phenomenon works with anything that is over-learned, over-practiced. Such skills become automated and, thereby, sub-conscious. These skills can be done with minimal interference to other ongoing tasks, with little or no conscious attention, and with great precision and speed. And once a skill reaches this level of automation, it is very difficult to change. PIE MENUS: I suspect that pie-menus are good things, but not because they are motor. Rather, they are good because items appear in a consistent place and it is easy for a single movement to select them. Regular pop-up or pull-down menus may be consistent, but visual attention is needed to find the desired target. Of course, pie menus only work with a limited number of entries (so that the selection stroke does not require high angular precision). I predict that if you add too many entries, they will require visual attention just like regular menus. Don Norman R. I. Anderson Human Factors Consultant Pacific Bell 2600 Camino Ramon, Room 2E850 (415)823-3715 San Ramon, CA 94583 ria@pbhyg.PacBell.COM From mimsy!tank!ncar!ames!lll-winken!uunet!mcsun!cernvax!pan!aratar!chac Fri Sep 29 21:45:25 EDT 1989 Article 1369 of comp.cog-eng: Path: mimsy!tank!ncar!ames!lll-winken!uunet!mcsun!cernvax!pan!aratar!chac >From: chac@aratar.UUCP (Chuck Clanton) Newsgroups: comp.cog-eng Subject: Re: Menu Interaction Techniques Message-ID: <344@aratar.UUCP> Date: 28 Sep 89 07:48:18 GMT References: <2722@trantor.harris-atd.com> <16179@brunix.UUCP> Reply-To: chac@aratar.UUCP (Chuck Clanton) Organization: Adasoft AG, Solothurn, Switzerland Lines: 27 In article <16179@brunix.UUCP> jhc@iris.brown.edu (James H. Coombs) writes: >I have not experienced the equivalent of touch typing >with menu selection. D. A. Norman is right on target: menus are >optimized for selection but pessimized for performance. this is my experience as well. on frequently used menus and slow machines, i can get the cursor (and my eyes) close to the right item before it appears but i still must see the item and correct before clicking on it. i have a very small amount of experience with pie menus and wonder if they are better. people who use have used them extensively speak of using "muscle memory" to "navigate" through the pie menus they are familiar with. it seems to me that the ergonomics of a linear array of menu items resembles that of a control panel composed of a row of identical switches. it is easy to make mistakes without careful visual verification of a choice. but a keyboard is just a long row of identical switches too. it is different only so long as the hands stay on the home row such that the keys are distinguished by position relative to a given fingers home position. whenever i move my hands to the mouse, i have exactly the same problem that i have with menu item selection--i must focus my attention on the keyboard to insure that i recover the correct hand position. so, it certainly seems like a reasonable hypothesis that pie menus with items in differing directions relative to the starting position might provide more of the performance and selection characteristics of "touch typing" and be less like the linear array of switches of normal menus. From mimsy!haven!aplcen!uakari.primate.wisc.edu!ames!ucsd!cogsci!norman Tue Dec 26 07:59:31 EST 1989 Article 1518 of comp.cog-eng: Path: mimsy!haven!aplcen!uakari.primate.wisc.edu!ames!ucsd!cogsci!norman >From: norman@cogsci.EDU (Donald A Norman-UCSD Cog Sci Dept) Newsgroups: comp.cog-eng Subject: Of Mice and Autos Message-ID: <60@cogsci.EDU> Date: 24 Dec 89 16:55:46 GMT References: <172@comcon.UUCP> <7326@ficc.uu.net> <9320@hoptoad.uucp> <1989Dec18.081450.28019@psuvax1.cs.psu.edu> <461@uwslh.UUCP> <7787@cognos.UUCP> Reply-To: norman@cogsci (Donald A Norman-UCSD Cog Sci Dept) Followup-To: comp.cog-eng Organization: UC San Diego Department of Cognitive Science Lines: 117 This note is inspired by the repeating of Bill Buxton's observations of the complexity of the auto interface, but with what I thought was exactly the wrong conclusion (that the complexity of autos is easily learned and OK, so why should we be so concerned about a few buttons on a mouse). Let's not get carried away with the apparent ease of use of automobiles and other household goods. People have severe problems with them. The auto works only because: 1. The critical control number about 6 (gas pedal, brake, steering, shift lever, and lights. Plus knowing where to insert the key and how to start the car.) (Manual transmission adds one more, but remember why we have automatics -- many people never comfortably manage to synchronize brake, gas, clutch, gear lever and turning, signalling, and driving). 2. The other controls DO cause great confusion and difficulty. Many people complain to me (because I collect these things) that they make errors and are <> frustrated by failure to find the horns, turn signals, windshield wipers (and washers), or to figure out how to work the (electric) windows, radios, heater, air conditioner, etc. Especially at high speed while driving. And I haven't even touched upon the cruise control yet. 3. With the computer, we need to use the minor controls and functions repeatedly and as part of the actions toward our goal. With the auto, all these other items are secondary, and although they do cause frustration, they are not required for the primary goal and so if we do have trouble, we can still go from point A to B, which is the goal. 4. Moreover, it takes a few months to learn to drive a car safely, about a year to feel comfortable. I rent automobiles tens of times a year, and I consider myself lucky if I can learn how to find a decent radio station on the radio. I often can't find the horn and I almost never can learn to set the clock correctly. Driving is so complex that we have special schools to teach it, special license exams, and special police to enforce the procedures. With road signs and markers (you couldn't drive safely without the white line down the middle of the highway). A large industry exists to keep driving within acceptably safe parameters (see item 5), 5. And, unlike computer interfaces, we accept 40,000 + deaths /year (in the US alone), plus hundreds of thousands of injuries. Each year. None of this was Bill Buxton's fault: he was being quoted, and unfairly I think. Buxton also has a nice story about the weirdness and lack of standards of the first automobiles. Go to a car museum and look. And for your holiday amusement, I append his story. ---------------------------------------------------------------------- Here is a note I got from Thomas Erickson (of Apple), on Bill Buxton's observations on early auto interfaces (written while Bill was in Cambridge, England, working for Xerox EuroParc -- he is now at Toronto). Unindented material is from Erickson: indented from Buxton: Date: Tue, 3 Jan 89 11:04:20 PST >From: Tom Erickson Subject: auto quote Interface Design, 1884-1904. Bill Buxton writes: On a number of occasions, I've heard speakers compare the operation of computers unfavorably to that of automobiles. "Why," they ask, "can't we design computers like cars, where one can move from one to the other, despite different manufacturers, and still be able to drive?" The line of argument usually proceeds along lines like, "What if cars were designed the way computer user interfaces are? What if the clutch was on the right foot and the accelerator on the left?" etc., leaving visions of death, destruction and all kinds of havoc on the highway, and by implication, on the computer-way. Buxton then goes on to describe his attendance at the finish of the London-Brighton [antique] car race, and his discovery that early automobiles (1884-1904) were designed much like current user interfaces. The programme of the race provides more detail: "The driver of an early Lanchester, for example,steers it by laying his right arm along a side-lever, while his right hand flashes from vapour regulator (mixture control) to petrol pump to compound gear trigger, between two engine governor levers and two gear levers, one of which is always a brake. His left foot operates the accelerator and his right foot is merely used to blow the horn, by stamping hard on a floor-mounted rubber bulb. By contrast, the Locomobile steam car has a transverse steering lever which is gripped in the left hand. The right hand operates the throttle lever, the link-motion control lever, the water-feed bypass lever, and all the mysterious stopcocks associated with steam power. Like the Lanchester, the early Delahaye had an accelerator pedal on the left, but you pressed it to slow down and released it to go faster; not much chance of catching that one if you happened to fall out. On the popular little Dion Bouton, the left pedal is not only a decelerator but also a transmission brake, and the right pedal (operated with the heel) engages the reverse. The Brotherhood-Crocker had a flanged accelerator pedal, because it was controlled by swiveling the foot from side to side, instead of up and down. And Denmarks pioneering car, the remarkable Hammel, turned left when the steering wheel was turned to the right, and vice-versa, so your Hammel driver wore an earnest, rather worried expression at all times." This sheds some light on why early market researchers predicted that the American demand for cars would peak at one million because of a limitation in the number of available chauffeurs. End of quoted section ---------------------------------------------------------------------- I am glad that we don't make computers as complex as the modern auto. Don Norman INTERNET: dnorman@ucsd.edu Department of Cognitive Science D-015 BITNET: dnorman@ucsd University of California, San Diego AppleLink: d.norman La Jolla, California 92093 USA FAX: (619) 534-1128 From mimsy!tank!ncar!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!dduck!michael Fri Jan 5 20:09:22 EST 1990 Article 1522 of comp.cog-eng: Path: mimsy!tank!ncar!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!dduck!michael >From: michael@dduck.ctt.bellcore.com (Michael Muller) Newsgroups: comp.misc,comp.cog-eng Subject: Re: Multi-button mice Message-ID: <18712@bellcore.bellcore.com> Date: 2 Jan 90 01:25:11 GMT References: <172@comcon.UUCP> <7326@ficc.uu.net> <9320@hoptoad.uucp> <1989Dec18.081450.28019@psuvax1.cs.psu.edu> <2253@dataio.Data-IO.COM> Sender: news@bellcore.bellcore.com Reply-To: michael@dduck.UUCP (Michael Muller) Organization: Bellcore, Piscataway, NJ Lines: 107 Xref: mimsy comp.misc:8266 comp.cog-eng:1522 We took a somewhat different approach: we put tiny icons in the image of the cursor/pointer, and moved them around when the pointer moved. The shape of the resulting image was spatially related to the button locations on the mouse. The notion was that this would serve as a constant reminder to the user of what was associated with each button. For a two-button mouse, the cursor image looked something like this (assume a decent bit-mapped representation, please!): ^ ||| ||||| +---+---+ |LLL|RRR| where |LLL|RRR| "LLL" is the icon region for the left button |LLL|RRR| "RRR" is the icon region for the left button +---+---+ A three-button mouse, with single-click and double-click protocols, would have a cursor something like this: ^ ||| ||||||| +---+---+---+ |lll|mmm|rrr| |lll|mmm|rrr| (single-click icons) |lll|mmm|rrr| ++---+---+---++ ||LLL|MMM|RRR|| ||LLL|MMM|RRR|| (double-click icons) ||LLL|MMM|RRR|| ++---+---+---++ +-------------+ As the cursor image grew larger with greater functionality (we had one for chords, too), we resorted to a time-delay pop-up arrangement in which the cursor's _pointer_ was always visible, but the reminder icons would pop up near the pointer only when the had not moved the pointer for some criterial delay interval. (always (pop up after visible) criterial delay) _ |\ ........... \ ........... \ ........... ........... ........... ........... ........... ........... We considered making the criterion for the delay into an adaptive parameter in a user modeling scheme -- i.e., short for novices or right after a mistake, longer for experts or people who seemed to know what they were doing. But we never had a chance to go that far. This work was reported in the CHI'88 and Graphics Interface '88 Proceedings. KMS uses a similar approach, involving letters within a cursor shape -- e.g., /|\ | +--+--+ |C M D| |O O E| |P V L| |Y E | +--+--+ The major difference between the KMS technique and ours was this: KMS provided a fixed set of pre-chosen function-to-button assignments, whereas we permitted users to tailor their own assignments. That is, our users could put any tool's icon in any of the slots in the cursor image. KMS loaded an _entire_ cursor image at one time, with pre- assigned locations for each of the tools in that image. I don't know how a comparison of the two techniques would have turned out: Direct comparisons were difficult, because the functionality that was accessed by the two systems (KMS and ours) was quite different (and in any event, Bellcore doesn't publish comparative analyses as a general rule). Other related work is reviewed in the two papers. We also provided a _cycle_ operation, whereby users could load a sequence of operations into one (or more buttons), and then use a second button to cycle through that sequence (e.g., edit-compile-link-debug as a sequence, or edit-spellcheck-format-print as another). We never got a chance to test the usability of our project. In general, responses to it lay along a continuum, each of whose two end-points was clearly enunciated by at least one reviewer: "A technique which adds clarity intelligibility to the interface, while minimizing cognitive load." "Just another way to garbage up the cursor." Michael Muller Bellcore 444 Hoes Lane Piscataway, N.J. 08854 US ..!bellcore!ctt!michael (201) 699 4892 michael@bellcore.com I am not a spokesperson for my employer, but sometimes I wish I were. Michael Muller Bellcore 444 Hoes Lane Piscataway, N.J. 08854 US ..!bellcore!ctt!michael (201) 699 4892 michael@bellcore.com From mimsy!haven!rutgers!cs.utexas.edu!uunet!gwusun!foley Fri Jan 5 20:10:37 EST 1990 Article 1524 of comp.cog-eng: Path: mimsy!haven!rutgers!cs.utexas.edu!uunet!gwusun!foley >From: foley@gwusun.gwu.edu (Jim Foley) Newsgroups: comp.cog-eng Subject: Assistantship in Human-Computer Interaction Keywords: Assistantship, Research, Human-Computer Interaction, NRL, GWU Message-ID: <1552@acsun.gwusun.gwu.edu> Date: 3 Jan 90 17:08:30 GMT Organization: The George Washington University, Washington DC Lines: 76 NRL/GWU JOINT RESEARCH ASSISTANTSHIP PROGRAM The Electrical Engineering and Computer Science Department at The George Washington University and the Human-Computer Interaction Laboratory at the Naval Research Laboratory are pleased to announce a Joint Research Assistantshis of these assistantships will be affiliated with the HCI Laboratory while enrolled in the graduate program at GWU. They will be full-time students at GW related to their course and thesis work, and participate in the activities of the Computer Graphics and User Interface Research Group at GWU. The Human Computer Interaction Laboratory conducts research and development in techniques and methods pertinent to the design of user interfaces for computer systems. The approach is interdisciplinary and the staff is drawn from the fields of computer science, psychology, and electrical engineering. Current project areas include: new modes of human-computer communication such as eye movements, gesture input, speech recognition, and auditory icons, concepts and designs for the next generation of user interface management systems, incorporating continuous, high-bandwidth input, theory and empirical study of graphical direct manipulation interfaces, visualization and control of scientific computations, low bandwidth communication systems including synthesized speech, characterization of human performance and individual differences under dual-task workloads. The HCI Laboratory has excellent facilities for research in graphics and human-computer interaction. An experiment suite is under construction, which will provide extensive capabilities for conducting and observing experiments, including video monitoring and recording of subjects. Other equipment includes: ASL eye tracker, VPL Datagloves, Polhemus trackers, Emu audio sampler, DECtalk speech synthesizer, SSI and Kurzweil speech recognizers, BARCO large screen displays. Silicon Graphics, NeXT, Masscomp,Sun-3, Sun-4, Sun-386i, and Macintosh workstations. Cray, Connection Machine, and BBN Butterfly supercomputers are also available at NRL. Computer facilities at GWU include many Sun-3, HP 360 SRX, Macintosh, and PS/2 workstations, and several HP 370 AI and 835 Turbo SRX graphics workstations. There is also an Alliant FX/8 super mini and an HP 835 time-sharing system. Beyond the core GWU Computer Science courses, the student's program of studies will draw on two user interface design courses and three graphics courses, with possible minor areas of study including psychology, graphic design, expert systems, and educational theory. The yearly stipend is approximately $13,000 plus tuition for MS students and $14,000 plus tuition for D.Sc. students. Award winners will spend part-time at NRL during the academic year and full time during the summer. NRL is located within Washington, D.C., approximately 15 minutes' drive from the GWU campus. For application and information material please contact James Foley, Department of EE&CS, The George Washington University, Washington, DC 20052, foley@seas.gwu.edu. Applications are due February 15, 1990. Applicants must be U.S. citizens. GWU and NRL are equal-opportunity employers. From mimsy!tank!ncar!mailrus!umich!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!dewey.soe.berkeley.edu!thom Fri May 4 10:22:30 EDT 1990 Article 1651 of comp.cog-eng: Path: mimsy!tank!ncar!mailrus!umich!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!dewey.soe.berkeley.edu!thom >From: thom@dewey.soe.berkeley.edu (Thom Gillespie) Newsgroups: comp.cog-eng Subject: aesthetics of the interface Message-ID: <35968@ucbvax.BERKELEY.EDU> Date: 3 May 90 01:54:08 GMT Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: thom@dewey.soe.berkeley.edu.UUCP (Thom Gillespie) Organization: School of Education, UC-Berkeley Lines: 35 References: Does anyone know of anyone who has looked at interfaces as an aesthetic experience which influences success? I ask this question after reading Mark Chignells article in SIGCHI , April 1990. I think that aesthetics fits in Chignell's taxonomy but I can't figure out where. I also think that aesthetics may be a very important element but that it is overlooked by technical designers for 2 reasons: the skill is lacking in the interface designer and it may be impossible to 'quantify' the aesthetic experience other than to ask did you like it or was it pretty. A lot of interface evaluation work seems to be aimed at what it is possible to quantify rather than what should be examined -- this isn't limited to interface design and evaluation. Buildings aren't (supposedly) built in downtown San Francisco unless they pass an an aesthetic review. Shouldn't computer interfaces be held accountable in a like manner? And, How? Can a word processor be aesthetically pleasing and not be of sound design? Can you design an unaesthetic version of PacMan? I don't mean one which doesn't have sound, graphics, animation, just plain old ugly -- this might be difficult given might be difficult given the state of post-modernism. I guess part of my question is 'Are there interface designers who are artists'. This thought was also reflected in Paul Heckel's 'Elements of Friendly Software Design' where he pointed out that the original movies were all done by tech- nologists because it was considered a technical field and he suggests that this evolution will occur in interface design. As far as I can see the artist is only called in to provided graphic design at a late date and only as a last resort and they never have the veto power a director has in the movies. The division between what is cognitive and affective is firmly entrenched in society and still reflected in this discussion group by having it named cognitive engineering as opposed to affective engineering -- no I'm not trying for yet another discussion group. I'm just thinking outloud and in public. Thanks. --Thom Gillespie --Thom Gillespie From mimsy!nems!ark1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!news Fri May 4 10:25:23 EDT 1990 Article 1652 of comp.cog-eng: Path: mimsy!nems!ark1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!news >From: ianf@draken.nada.kth.se (Ian Feldman) Newsgroups: comp.cog-eng Subject: Re: aesthetics of the interface Message-ID: <1990May3.070018.29867@kth.se> Date: 3 May 90 07:00:18 GMT References: <35968@ucbvax.BERKELEY.EDU> Reply-To: ianf@nada.kth.se (Ian Feldman) Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 72 In article <35968@ucbvax.BERKELEY.EDU> thom@dewey.soe.berkeley.edu.UUCP (Thom Gillespie) writes: > [.....] I also think that aesthetics > may be a very important element but that it is overlooked by > technical designers for 2 reasons: the skill is lacking in the > interface designer and it may be impossible to 'quantify' the > aesthetic experience other than to ask did you like it or was > it pretty. A lot of interface evaluation work seems to be > aimed at what it is possible to quantify rather than what > should be examined -- this isn't limited to interface design > and evaluation. You said it -- the belief that only quantifiable qualities may apply rules allover. This is sometimes termed as the "Einstein complex" (or syndrome) in humanistic sciences -- after WWII and the atom bomb when large grants were made available to the ballistics/ mathematics/ physics and engineering sciences there has been a marked turn in the way that the cognitive science projects justify their existence. Basically, they try to prove their worth with numbers, since these at least are "hard" data, less prone to misinterpretation and down- grading by public-accounting-minded administrators than mere logic/ philosophic statements. Also we are living in the Western society where a "worth-enhancing" engineer has for the past 500 years always had greater status than, say, a monk transcribing verses by hand, who's merely trying to achieve an esthetic (and pious) "non-productive" manuscript. Thus an artist's contribution to any given engineering/ manufacturing goal is always viewed (by engineers but also by "popular consesus") as something less worthy of respect and definitely not worthy the status of equal-resources during some project's design/ prototyping stage. Usually the artist gets called in at the last possible moment, to provide an esthetically-pleasing shell to what's basically esthetically misguided in the first place. That's the best scenario; the worst ones' end results are all around us. > Can a word processor be aesthetically pleasing and not be of sound > design? Can you design an unaesthetic version of PacMan? Aren't they all anyway? The word processors, I mean, also the PacMans. Most of today's widely spread software has been designed by the techies, giving us what is economically, technologically and "pragmatically" feasible, rather than what's esthetically pleasing. And as long as the computer-based tools will be viewed purely in terms of efficiency and accountability then we'll probably not see any products that are designed to provide as much aesthetic gratification as the "productivity-enhancing" features of its other parts. [......] > The division between what is cognitive and affective is firmly > entrenched in society and still reflected in this discussion group > by having it named cognitive engineering as opposed to affective > engineering -- no I'm not trying for yet another discussion group. > I'm just thinking outloud and in public. > --Thom Gillespie Still, not thinking of the esthetic aspects of what we're producing affects us all..... did you, Thom, think about that your near-80 character lines of the original post (that I had to reformat by hand) may not look very pleasing to the eye on aan 80-chaacter vt100 screen, when included in a letter with just a ">" and a space in front of them? In that state they were also much harder to read and comprehend, than if they were shorter, laid out nicely and delimited by plenty of consequently-applied white space around it. Just asking rhetoric questions out loud.... ;-)) --Ian Feldman / ianf@nada.kth.se || uunet!nada.kth.se!ianf / The "I had the bug narrowed down to a subrutine and then I lost all interest" hacker From mimsy!haven!aplcen!samsung!umich!srvr1!cicada.engin.umich.edu!zarnuk Fri May 4 10:26:33 EDT 1990 Article 1653 of comp.cog-eng: Path: mimsy!haven!aplcen!samsung!umich!srvr1!cicada.engin.umich.edu!zarnuk >From: zarnuk@caen.engin.umich.edu (Paul Steven Mccarthy) Newsgroups: comp.cog-eng Subject: Re: aesthetics of the interface Message-ID: <1990May4.075831.1008@caen.engin.umich.edu> Date: 4 May 90 07:58:31 GMT References: <35968@ucbvax.BERKELEY.EDU> <1990May3.070018.29867@kth.se> Sender: news@caen.engin.umich.edu (CAEN Netnews) Organization: University of Michigan, Ann Arbor Lines: 31 Just to pipe in a word on the side of the "techies" here... Have you ever tried to present an aesthetically pleasing and yet functional interface on a 25x80 grid of cells, where you may not even be lucky enough to have any line-drawing characters available? On MacIntoshes, or large (expensive) graphics work- stations many more options are available, but the bread and butter of the industry is still tied to the old 25x80 grid (generally without any assumptions about color if you want to maintain portability). Give it a little more time, folks. Your concerns and complaints are certainly warranted, but the price-tags on the hardware necessary for wide-spread "beautiful" applications is still a little out-of-reach for most small to medium sized organizations. >From my standpoint as a system developer, I see immediate benefits from quantitative studies of user-interface complexity. This is the only way that I can demonstrate to upper management that it does, indeed, pay off in the long run to develop systems that have consistent, understandable user-interfaces. This is also the only way that I can hope to get programmers who have been trained in the bare-bones basics about what is "friendly" vs. what is "hostile". Aesthetics will come, have no fear, but we aren't quite there just yet. I remember a quote that was attributed to Henry Ford during the early days of the automobile: "You can have any color you'd like -- as long as it's black". Cars have come quite a ways since then, computer systems will too. ---Paul... From mimsy!haven!aplcen!uunet!mcsun!hp4nl!dnlunx!spex1!margot Fri May 4 10:27:17 EDT 1990 Article 1654 of comp.cog-eng: Path: mimsy!haven!aplcen!uunet!mcsun!hp4nl!dnlunx!spex1!margot >From: margot@spex1.uucp (Margot Lagendijk) Newsgroups: comp.cog-eng Subject: >aesthetics of the interface (RE) Message-ID: <1204@dnlunx.pttrnl.nl> Date: 3 May 90 07:02:49 GMT Sender: news@dnlunx.pttrnl.nl Distribution: comp Lines: 24 Thom Gillespie asked "are there interface designers who are artist" Well if you think that designing an interface is an art, than interface designers are artists:-) He also refers to buildings that have to pass an aesthetic review and wonders if this could work with computer interfaces. It could be wise to have something like that but, as i remember from my computer science course, 'if the interface looks nice and beautiful it will probably not be nice to work with' (or something to that extent). In "Applying cognitive psychology to user-interface design" by Gardiner and Christie, they say "The use and popularity of colour is increasing all the time. Unfortunately, at present, it is often used excessively and inappropriately,..." They also say "A feature (such as colour) only really works when it is distinctive if it is rare or unique in that particular context". I think that artist (in any form possible) should not be held back will they are creating things. With computer interfaces you must keep the user and the way (s)he works in mind. That will limit the artist too much in his/her work. As for the comparison with buildings: aren't the outsides reviewedi? The outsides are important for the eye, but not for the actual work that people do. With computer interfaces both need to be considered. Margot Lagendijk margot@spex.nl From mimsy!haven!aplcen!samsung!cs.utexas.edu!halley!san@cs.utexas.edu Fri May 4 21:32:27 EDT 1990 Article 1657 of comp.cog-eng: Path: mimsy!haven!aplcen!samsung!cs.utexas.edu!halley!san@cs.utexas.edu >From: halley!san@cs.utexas.edu (Steve Sanderson) Newsgroups: comp.cog-eng Subject: Re: >aesthetics of the interface (RE) Message-ID: <870@halley.UUCP> Date: 4 May 90 23:25:19 GMT References: <1204@dnlunx.pttrnl.nl> Sender: news@halley.UUCP Distribution: comp Lines: 33 In article <1204@dnlunx.pttrnl.nl>, margot@spex1.uucp (Margot Lagendijk) writes: ... > I think that artist (in any form possible) should not be held back will they > are creating things. With computer interfaces you must keep the user and the > way (s)he works in mind. That will limit the artist too much in his/her work. ... I read the above as implying that the creative act of an artist is uni-directional, i.e. that the artist produces the art but is not affected by the cultural context in which it is produced, and that feedback to the artist would limit the artists creativity. My experience with artists leads me to believe that their act of creation keeps many considerations in mind, except that they are not "kept in mind" rather they are kept somewhere deeper, at a more intuitive level. I see artists, as with any other member of a (cultural) system, as being intimately interconnected and influenced by the system. This interconnection is not usually stated as explicitly as it is in the engineering field, as in a software requirements document. Given the above, it seems that to utilize an artist in the design of human-machine interfaces would require that the artists be a member of the community of users and developers. I believe that this would result in the artist being influenced at an intuitive level by the cultural context, which could result in aesthetically pleasing and functional interfaces. Steve Sanderson Tandem Computers halley!san@cs.utexas.edu From mimsy!dftsrv!ames!ucsd!swrinde!cs.utexas.edu!halley!san@cs.utexas.edu Sun May 13 22:54:02 EDT 1990 Article 1664 of comp.cog-eng: Path: mimsy!dftsrv!ames!ucsd!swrinde!cs.utexas.edu!halley!san@cs.utexas.edu >From: halley!san@cs.utexas.edu (Steve Sanderson) Newsgroups: comp.cog-eng Subject: Re: >aesthetics of the interface (RE) Message-ID: <871@halley.UUCP> Date: 7 May 90 16:17:22 GMT References: <1990May5.133246.6584@uwslh.slh.wisc.edu> <1204@dnlunx.pttrnl.nl> <36024@ucbvax.BERKELEY.EDU> Sender: news@halley.UUCP Distribution: comp Lines: 23 In article <1990May5.133246.6584@uwslh.slh.wisc.edu>, lishka@uwslh.slh.wisc.edu (Chris Lishka (coming to you live via satellite!) ) writes: ... > The best advice I ever picked up about conveying information to a > reader (especially with a page of text) is that the most succesful > designs will be the least obtrusive. In other words, if the *design* > of the page is so flashy that it distracts the reader from the > content of the text, then the person who did the page layout has > failed. Good designs should make it easy to derive the content of the > text. ... Interesting enough, I've been taught the following about art: If, when looking at a piece of art (or listening I suppose), you begin to wonder about the mechanics, the methods or the details of its creation, then the piece has failed as art. Without trying to engender a discussion on what constitutes "art", I interpret these ideas as saying that if the medium attracts the attention, then the message gets lost. Steve Sanderson halley!san@cs.utexas.edu From mimsy!haven!ames!ncar!boulder!uswat!jima Wed May 16 02:59:03 EDT 1990 Article 1680 of comp.cog-eng: Path: mimsy!haven!ames!ncar!boulder!uswat!jima >From: jima@uswat.uswest.com (Jim Alexander) Newsgroups: comp.cog-eng Subject: CHI'91 Call for Videos Message-ID: <7970@uswat.UUCP> Date: 15 May 90 17:16:21 GMT Sender: news@uswat.UUCP Organization: US WEST Advanced Technologies, CO, USA Lines: 60 CHI'91 Video Program Call for submissions >From the general CHI'91 Call for Participation ... "The annual CHI Conference on Human Factors in Computing Systems is the leading forum for bringing together the wide variety of people concerned with the different aspects of human interaction with computing systems: analysts, engineers, applied researchers, basic researchers, managers, teachers, and students. And, the CHI community expresses interest in all phases of technology development and use: research, requirements analysis, innovation, exploratory development, design, prototyping, full-scale development, deployment, usage and social impact. The CHI conference activities and the publications that come from it provide a number of vehicles for communicating the latest thinking on these issues." One of the primary vehicles for communicating the "latest thinking" at CHI is the technical video track. We encourage you to begin working on a video now for CHI'91. Videos should be submitted by October 1, 1990. Technical videos are a remarkably effective tool for communicating new and important ideas to the CHI community. Because of this, videos will play a major role at the CHI'91 conference. In addition to the traditional CHI video program, CHI'91 videos will be included in the technical sessions and the video proceedings which will be for sale at the conference. For this program we need videos with both important new ideas and good production quality. If you have something exciting, we encourage you to submit a video showing your work. Submit one tape in 1/2 inch VHS or 3/4 inch U-matic format. Include a cover sheet with the title, names and addresses of the authors (mail, telephone and electronic mail address), affiliations, the topic area(s) from the general CHI'91 call, a 100 word abstract, and the length of the tape. All submissions received by will be considered for inclusion in the main CHI program. Late submissions may be considered for other uses at CHI'91. Send all video submissions to: James H. Alexander CHI'91 Video Chair Phone: (303) 740-1561 U S WEST Advanced Technologies E-Mail: jima@uswest.com 6200 S. Quebec Street #320 Englewood, Colorado 80111 In order to help people create better videos we have developed a set of guidelines. Please write for a copy of the CHI video guidelines. Questions via mail or e-mail will be gladly answered. CHI'91 will be April 28 through May 2, 1991 in New Orleans. If you have any general questions about the CHI conference or are interested in contributing to the conference in a media other than video, please contact the CHI'91 Executive Administrator and ask for the general Call for Participation: June Davis Phone: (301) 269-6801 Conference and Logistics Consultants 13 Annapolis Street Annapolis, MD 21401