flee@shire.cs.psu.edu (Felix Lee) (12/18/89)
Tim Maroney <tim@toad.com> wrote: > I have *never* seen a non-techno-jock user who could keep the mouse > buttons straight. Multi-button mice are brain-damaged. The problem with multi-button mice is confusion of buttons. My prime example is the game "xmille". You click the left button on a card to discard it, the right button to play it. Or is it the other way around? Each button is used about equally often. You sometimes have to discard cards for a long time, so when you finally get a card you can play, you naturally discard it. An IBM PC version of mille that uses the right and left arrows is about as bad. Poor design. A partial fix is to use visual cues. Label the buttons on the screen somewhere, like labelling function keys. But then, many users don't read and/or understand what the computer tells them. ("What does 'missing semicolon' mean?" "It means you're missing a semicolon." "Oh.") This is the success of iconic systems. The problem may be just lack of consistency; every application seems to want to use the mouse buttons in a different way. If, say, the right button always moved windows around, there may be less confusion. Maybe if the buttons operate in different contexts, say, the left button belongs to the application, and the right button belongs to the window manager. Probably not; "window manager" is a fuzzy concept. One thing that might be interesting is a mouse with a thumb button. This naturally maps to grabbing and moving things around. Much like the index finger maps naturally to pointing. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee
peter@ficc.uu.net (Peter da Silva) (12/19/89)
> > I have *never* seen a non-techno-jock user who could keep the mouse > > buttons straight. Multi-button mice are brain-damaged. Try it on the Amiga. The two buttons are SELECT and MENU, and are almost universally supported. For some reason paint programs are the exception: and they use the MENU button for ERASE... probably because dPaint did things that wau. > The problem with multi-button mice is confusion of buttons. > The problem may be just lack of consistency; I would venture to say that the problem *is* a lack of consistency. And this relates, of course, to the XWindows "tools, not rules" paranoia. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
mwm@raven.pa.dec.com (Mike (Under Construction) Meyer) (12/19/89)
Tim Maroney <tim@toad.com> wrote: > I have *never* seen a non-techno-jock user who could keep the mouse > buttons straight. Multi-button mice are brain-damaged. You haven't looked hard enough. I've seen at least two cases. Neither used a three-button mouse, though. Both cases have in common that the second button is dedicated to a single thing. First case was a general UI, where the second button is hardwared to "show me a menu". The second case was a paint program, where the second was dedicated to "eraser." I've never seen a real user deal with a three-button mouse without a card hanging off the side of the machine saying what they do. <mike -- -- It's been a hard day's night, Mike Meyer And I been working like a dog. mwm@berkeley.edu It's been a hard day's night, ucbvax!mwm I should be sleeping like a log. mwm@ucbjade.BITNET
aez@Data-IO.COM (Adam Zilinskas) (12/19/89)
In article <1989Dec18.081450.28019@psuvax1.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >Tim Maroney <tim@toad.com> wrote: >> I have *never* seen a non-techno-jock user who could keep the mouse >> buttons straight. Multi-button mice are brain-damaged. > >The problem with multi-button mice is confusion of buttons. My prime > >A partial fix is to use visual cues. Label the buttons on the screen I worked on a project between MIT and Harris-ATD that tried this. It was called Schema (no not the PC-based schematic editor) and we were building CAE applications for the Symbolics Computer. The Symbolics had a three-button mouse and software scannable control keys on the keyboard (control, meta, hyper, super, [shift counted as a double click]). The mouse, keyboard usage was suggested by Buckminster Fuller and Richard Zipple (project leader) called them "Bucky Keys". Always on the bottom of the screen was a line with three sections denoting what the mouse buttons would do if you pressed them. Without pressing any control keys, the mouse help line said something like: " Select Select-more Help" (pressing left mouse key would select anything under the mouse arrow, middle sould addd to the selected items [for grabbing two or more objects], and right was a help menu of all key combinations [more later]) Holding down control the help lin changed to: " Move Rotate Delete" Similar commands would show up for meta, hyper and super. The system also accepted chords like control-hyper, hyper-meta-super .... The effect was that each mouse key would provide 16 functions. Most of our commands to the applications in Schema were mapped into a bucky-key. The control keys were grouped in a line on the keyboard in the lower right and lower left corners. The method of using the system (for a right handed person) was to place the four left finger on the left corner control keys and the right hand controlled the mouse. The system, once learned, was quite efficient as the left hand never moved off the control keys and all commands were a mouse-movement and a click away (the commands were action verbs, the subject of the command was always under the mouse). The only problem was in the learning and mapping of the commands. We spent a great deal of time figuring out the correct placements of commands for all our applications. We placed the often used and common commands like select and move always in the same simple bucky-key pattern, the more esoteric commands were given harder buckey-keys like control-super-hyper middle-mouse-button for "add-simulation probe at point". The less often used commands were hard to remember so one would either strum the left hand through all 16 control key patterns reading the mouse help line or hit the help sequence (right mouse button, no control keys) which gave us the table of all the commands. The ad-hoc rules (never really written down, just memorized) were: 1. obvious and non-destrctive commands (like select, help) were given the simplest sequence (just mouse keys). 2. commands that were reversible (like move, rotate...) were one control key and a mouse button. 3. destructive commands (like delete, cut ...) were on the least used mouse button (right-mouse) and a different control key so they would not be confused with move and copy. 4. Almost all our applications had select, move, copy, delete commands, they were always in the same buckey-key pattern. What I would like to know is if there is anybody else that has used such a mouse-keyboard scheme in a system (we built the system but it did not get into general use). 1. What has been the acceptance of multiple functions on the mouse buttons? Do piano players and chord keyboard users prefer it rather than the Joe User? 2. Is there a better system that minimizes the age-old time wasting problem of find/grab orient the mouse, click, grab and home up on the keyboard, type and repeat? Adam Zilinskas A person who once did more things than figure out how to blow fuses with style. Data I/O corp. P.S. Most of the work was started by Richard Zippel who I last heard was working for Symbolics. If he is on the net, I hope that my explanation of buckey keys agrees with yours.
baum@Apple.COM (Allen J. Baum) (12/19/89)
[] >In article <2253@dataio.Data-IO.COM> aez@dataio.Data-IO.COM () writes: >The Symbolics had a three-button mouse and software scannable control >keys on the keyboard (control, meta, hyper, super, [shift counted as >a double click]). The mouse, keyboard usage was suggested by >Buckminster Fuller and Richard Zipple (project leader) called them >"Bucky Keys". The terminology of "bucky-bits" precedes Symbolics by quite a bit. It originated at Stanford AI Labs in the late 60's, I believe. I can't recall how they got named exactly. Perhaps someone who remembers could set it straight, and possibly cross-post to alt.computer.folklore -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
barmar@Think.COM (12/19/89)
In article <1989Dec18.081450.28019@psuvax1.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >The problem may be just lack of consistency; every application seems >to want to use the mouse buttons in a different way. If, say, the >right button always moved windows around, there may be less confusion. I agree that this is the main problem. On Symbolics Lisp Machines it is relatively easy for UI designers to provide consistency by allowing mouse clicks to be assigned using symbolic names. Instead of binding an operation to "left button", you can bind it to the "select" gesture. The translation table between symbolic gesture names and physical gestures can be customized by the user (so that a user who would prefer menus to be on the middle button with the Shift key held down can get this), and it can also be initialized by the system for different hardware configurations (e.g. single-button vs. multi-button mice). I believe a similar mechanism will be included in CLIM (Common Lisp Interface Manager), a portable, object-oriented UI programming interface being developed for Common Lisp. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
barmar@Think.COM (12/19/89)
In article <2253@dataio.Data-IO.COM> aez@dataio.Data-IO.COM () writes: >In article <1989Dec18.081450.28019@psuvax1.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >>A partial fix is to use visual cues. Label the buttons on the screen >I worked on a project between MIT and Harris-ATD that tried this. It >was called Schema (no not the PC-based schematic editor) and we were >building CAE applications for the Symbolics Computer. Just thought I'd point out that the "mouse documentation line" on the screen is a standard feature of MIT-derived Lisp Machines (including those from Symbolics), not something that was invented for this project. Three years ago Symbolics spruced up the Lisp Machine UIMS, adding the ability to use chord keys with mouse buttons, and that's when they added the feature where the documentation line changes depending on which shift keys are being pressed (they added a second line that lists which shift keys may be used with the mouse in its present context). >The Symbolics had a three-button mouse and software scannable control >keys on the keyboard (control, meta, hyper, super, [shift counted as >a double click]). Please use the present tense when referring to Symbolics workstations. Symbolics is still very much alive. >The system also >accepted chords like control-hyper, hyper-meta-super .... >The effect was that each mouse key would provide 16 functions. Since there are five chord keys (shift, control, meta, super, and hyper), each mouse button could provide 32 functions. Just because shift is equivalent to double click is no reason not to include it as a separate function (it would be wrong to count BOTH shift and double-click, but you included neither). >What I would like to know is if there is anybody else that has used >such a mouse-keyboard scheme in a system (we built the system but it >did not get into general use). Every current Symbolics workstation user has used such a system, since it is used throughout the Symbolics software. >P.S. Most of the work was started by Richard Zippel who I last heard >was working for Symbolics. If he is on the net, I hope that my explanation >of buckey keys agrees with yours. Well, at least I now know where the nickname "bucky keys" for multiple chording keys comes from. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
peter@ficc.uu.net (Peter da Silva) (12/19/89)
> I've never seen a real user deal with a three-button mouse without a card > hanging off the side of the machine saying what they do. Anyone know what the three-button mouse on the Xerox Star does? -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
brad@looking.on.ca (Brad Templeton) (12/19/89)
Hmm. So one button is clearly too few, and two buttons is too many. Interesting dilemma. I'm a touch typist, and not so big on mice, one button mice even less. I can do things with my keyboard very quickly. And I have an unlimited array of commands available to me that I can get at quickly -- because they have names. I don't forget the names of the things I do frequently, and there are hundreds of those. But a mouse is a pain because it takes my hands off the home row, where they are so powerful. A one button mouse is worse because you have to go to the keyboard for any input that isn't just selecting and pointing. Even a trackball isn't good enough. Moving hands on and off the keyboard (as in text editing) slows things down a lot. But people do forget the functions of mouse buttons, largely because they are inconsistent. Perhaps the buttoms should be given names, those names should be put on the mouse, and never deviated from? -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
igb@fulcrum.bt.co.uk (Ian G Batten) (12/19/89)
baum@apple.UUCP (Allen Baum) writes: > > The terminology of "bucky-bits" precedes Symbolics by quite a bit. It > originated at Stanford AI Labs in the late 60's, I believe. I can't > recall how they got named exactly. Perhaps someone who remembers could > set it straight, and possibly cross-post to alt.computer.folklore The ``Hacker's Dictionary'', as I recall, traces the use of extensive shift bits being called ``Bucky Bits'' to Nicklaus Wirth, who suggested them whilst in the US on a sabatical. He was nicknamed ``Bucky'' at the time. ian -- Ian G Batten, BT Fulcrum - igb@fulcrum.bt.co.uk - ...!uunet!ukc!fulcrum!igb
freek@fwi.uva.nl (Freek Wiedijk) (12/19/89)
>> The problem with multi-button mice is confusion of buttons.
The problem is *not* mouse specific. Notice the following "confusions"
I'm always fighting against:
Delete <-> Backspace
Return <-> Enter
and, on the Mac:
Command <-> Control
--
Freek "the Pistol Major" Wiedijk Path: uunet!fwi.uva.nl!freek
#P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)**wayne@dsndata.uucp (Wayne Schlitt) (12/19/89)
Tim Maroney <tim@toad.com> wrote: > I have *never* seen a non-techno-jock user who could keep the mouse > buttons straight. Multi-button mice are brain-damaged. our software package doesnt use a windowing environment, this includes not using dialog boxes, pull down/pop up menu's etc. basically, we use our mouse (actually a digitizing tablet) to locate graphics on the screen, select menu options and answer simple questions. if you think three buttons is a lot, get this: we use a four button mouse. and from seeing _complete_ computer novices use our software, i would say it works quite well. a few things help to make it simple. the meanings of the buttons are as consistent as possible and the current actions are always display on the top of the screen in a "command diamond". the top button always means yes, select, continue, and such. the bottom means no, return, abort and such. the left and right buttons are not used anywhere near as much, but they are fairly consistent. if there are more than four options at a given point, we put a menu up on the screen and people use the mouse to locate the option and then press "select (the top button)". if there are four or fewer options, we try to put the options on the buttons. very few things require the use of the keyboard, and a lot of the keyboard usage requires just the keypad. people that we train find the four button mouse _less_ intimidating than the keyboard (there are just too many buttons on the keyboard...). for experienced people, the four button mouse allows them to be almost "touch typist". they know what the buttons do and can fly through the program as fast as i can fly through emacs. we try to pay close attention to what is the quickest/simplest way to do things. moving the mouse takes time, so does pushing a lot of buttons or trying to find letters on the keyboard. switching from the keyboard to the mouse takes a lot of time. basically, i think that a well designed user interface can use a multi-button mouse quite effectively. it _can_ be made easy to use, easy to learn _and_ quick for the experienced user. it just takes a little bit of effort and experience when you create the user interface. -wayne
) (12/19/89)
flee@shire.cs.psu.edu (Felix Lee) writes: >The problem with multi-button mice is confusion of buttons. No kidding! Three buttons, all being used inconsistently (i.e. using a DECWindows window manager with Xterm) is a lot of trouble/learning. >The problem may be just lack of consistency; every application seems >to want to use the mouse buttons in a different way. If, say, the >right button always moved windows around, there may be less confusion. The Commodore Amiga does this. The right button is always used to get the menu (or at least always should be; some ported games go around this). The left button is used to select an activate objects. It is *much* less confusing because the right button pretty much is used for menus alone. I still lean towards a one-button mouse, though. >One thing that might be interesting is a mouse with a thumb button. >This naturally maps to grabbing and moving things around. Much like >the index finger maps naturally to pointing. Yes, this would be a big improvement (although two left-handers should be able to get a left-handed mouse). However, I think your point about consistent use of the buttons still holds here. My preference is a one button mouse. One simply cannot get confused with which button to press! And I have never had any problems with single/double-clicking confusion. >Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Data Processing Section (608)262-4485 lishka@uwslh.uucp "... This week, Shane and Rebecca meet some squirrelly country boys. Steve and Kayla grow further apart, while Cal and Kim come closer to finding Arthur. Justin and Adrienne declare war." -- from TV Guide's "Soap Opera Guide"
ck@voa3.UUCP (Chris Kern) (12/20/89)
In article <7351@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Anyone know what the three-button mouse on the Xerox Star does? The mouse on the Xerox 6085 (the box, successor to the Star) under ViewPoint (the office automation application, successor to Star) has two buttons. The left button is a selector. The right button is basically a modifier. For example, to select a section of text within a file, you would click on the start of the selection with the left button, then click on the end of the selection with the right button. (There are various "accelerators" that allow you to select lexical chunks of text by multiple clicking.) In recent releases of ViewPoint, the right button is employed instead of the left button to signify that the user wants an operation to be performed in the background rather than the foreground. For example, to move a file from your workstation to a file server in the foreground, you would (1) select the file icon with the left mouse button, (2) press a dedicated "move" special function key to the left of the alphanumeric keyboard, and then (3) click on the file service icon (or open window) with the left mouse button. To perform the same operation in the background, you would use the right mouse button in step 3. I guess you could say the right button is overloaded, since the foreground-background dichotomy doesn't really fit within the select- modify model that is used for other operations with the mouse. In practice, our ViewPoint users (we have approximately 1300 of them) don't seem to be confused by the second mouse button or the way Xerox has chosen to use it. There seems to be little psychological interference between the left- and right-button functions, and one develops a sort of kinesthetic sense about the mouse. You just never think about it. I suspect this is a reflection of good design -- in other words, I imagine it would be possible to design a two-button mouse that would be difficult to use -- but perhaps it is just that people adapt to any mechanism that they need to use throughout their work day. -- Chris Kern Voice of America, Washington, D.C. ...uunet!voa3!ck +1 202-485-7020
pds@quintus.UUCP (Peter Schachte) (12/20/89)
In article <7339@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> The problem with multi-button mice is confusion of buttons. >> The problem may be just lack of consistency; >I would venture to say that the problem *is* a lack of consistency. And >this relates, of course, to the XWindows "tools, not rules" paranoia. I think that's right. The really sad thing is that they needn't give up their "'tools, not rules' paranoia" to fix the problem. All that is needed is for programs to be written in terms of user events rather than in terms of mouse button presses and key presses. If, for example, a program was looking for a "selection" user event instead of a left mouse button press event, then users could remap selection to be whatever event they want it to be, and all programs would behave consistently. And you wouldn't have programs like xcal that can't be exited without a 3-button mouse (because you have to hit the "on" button with the right mouse button to exit). Oh, well. Maybe X12 will fix this. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
folta@tove.umd.edu (Wayne Folta) (12/20/89)
>... And I have never had any problems with single/double-clicking confusion.
At least on the Mac, you never *have* to double-click. As far as I know,
double-clicking is a shortcut for clicking to select, followed by selecting
"Open". Thus, you never have to get double-clicking straight... :-)
--
Wayne Folta (folta@cs.umd.edu 128.8.128.8)ian@mva.cs.liv.ac.uk (12/20/89)
In article <1989Dec18.081450.28019@psuvax1.cs.psu.edu>, flee@shire.cs.psu.edu (Felix Lee) writes: > The problem with multi-button mice is confusion of buttons. My prime > example is the game "xmille". You click the left button on a card to > discard it, the right button to play it. Or is it the other way > around? Each button is used about equally often. You sometimes have > to discard cards for a long time, so when you finally get a card you > can play, you naturally discard it. An IBM PC version of mille that > uses the right and left arrows is about as bad. Poor design. > This is a case of using the mouse when it is not necessary. A sensible way of doing this would be to have the `d' and `p' keys from the keyboard. I feel that having a mouse available frequently causes the keyboard to be ignored when it is the more suited to a certain job. When I use drawing packages on the Mac, I tend to use a full screen mode. When I need to change from say a pencil to a rubber, I have to call up the tools palette, select the rubber and then hide the palette once more. A far simpler way to do this would be to press the `r' key (or `e' key). > The problem may be just lack of consistency; every application seems > to want to use the mouse buttons in a different way. If, say, the > right button always moved windows around, there may be less confusion. > But the single button on the Mac mouse causes similar problems when you try and do something with a modifier; now was it command, shift, control or all of them? Anyway, how can anyone scroll a window using a one button mouse? (:-) Ian ---
wb8foz@mthvax.cs.miami.edu (David Lesher) (12/21/89)
I remember a Byte new product announcement, trumpeting an all new 88 button mouse. Of course it was the 4th issue of the year.... -- A host is a host & from coast to coast...wb8foz@mthvax.cs.miami.edu no one will talk to a host that's close..............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
david@ics.ics.COM (David B. Lewis) (12/21/89)
(Sorry about the follow-ups; bad news software makes inclusion difficult.) (And I can't think as clearly using poor software...) RE: the displayijng of mouse-functions on the screen as they change. AT&T uses this device in the DMD terminals, and it works well. RE: the confusion of Delete with Backspace. That's why we have xmodmap. RE: processing in terms of user-events. Check out what AT&T does with its SELECT/ADJUST/MENU assignments to the mouse-buttons. RE: X12 fixing problems with mouse-assignments. X11 does just fine in empowering the user. Complain not to the X Consortium but to the people who design the user-interface toolkits and applications. David B. Lewis david@ics.com david%ics.UUCP@bu.edu ...!uunet!ics.com!david "That's the thing about people who think they hate computers. What they really hate is lousy programmers." -- Larry Niven and Jerry Pournell in 'Oath of Fealty'
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (12/21/89)
In article <1989Dec20.231509.10823@ICS.COM> david@ics.ics.COM (David B. Lewis) writes: | RE: the displayijng of mouse-functions on the screen as they change. | AT&T uses this device in the DMD terminals, and it works well. Yes, it's done by others on function keys, as well. HP labels the function keys with two lines of text just above them. Evans & Sutherland have a small LED (sic) 12x2 display over the function keys on some of their stuff. I have seen experimental keyboards which had a display right in the keytop. The intent was to allow (a) QWERTY and Dvorak layouts without cap changing, and (b) to let people turn the whole kb into function keys with labels, if that was appropriate. I believe the process was very expensive at the time, but what isn't, when it's new? Human interface question: using the above technology, would it be useful to have labels right on the keys themselves? I have the feeling that most people have their eyes on the keyboard, some have their eyes on the screen, but NOBODY is looking at the mouse, and you would have to lift or shift your fingers to see the labels, anyway. Perhaps the people who can't remember what key to press would not mind shifting their eyes? -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
malloy@nprdc.arpa (Sean Malloy) (12/22/89)
In article <1318@umigw.MIAMI.EDU> wb8foz@mthvax.cs.miami.edu (David Lesher) writes: >I remember a Byte new product announcement, >trumpeting an all new 88 button mouse. >Of course it was the 4th issue of the year.... But then there's the PowerMouse, that 28 (?) button 'hand phaser' with two 'mouse buttons', a full numeric keypad, all 10 IBM function keys, and some others. Technology missing the point. Sean Malloy | "I am here by the will of Navy Personnel Research & Development Center | the people and will not San Diego, CA 92152-6800 | leave until I get my malloy@nprdc.navy.mil | raincoat back"
garym@cognos.UUCP (Gary Murphy) (12/22/89)
In article <WEENING.89Dec19085547@Gang-of-Four.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU (Joe Weening) writes: >In article <37371@apple.Apple.COM> baum@Apple.COM (Allen J. Baum) writes: > > >In article <2253@dataio.Data-IO.COM> aez@dataio.Data-IO.COM () writes: > >The Symbolics had a three-button mouse and software scannable control > >keys on the keyboard (control, meta, hyper, super, [shift counted as > >a double click]). The mouse, keyboard usage was suggested by > >Buckminster Fuller and Richard Zipple (project leader) called them > >"Bucky Keys". This is a bit askew from the original thread, but this reference caught my eye - does anyone have further references about R.B.Fuller's involvement with Symbolics? I don't remember any mention of Symbolics in his own writings, but it wouldn't be the first time he'd neglected to take credit. The only specific reference to a computer I can think of is the when he helped the Auto Workers Union calculate the benefits of an unprecedented wage increase (sometime in the '50's ?) using one of the first publicly available machines (GM gave them the money, and made a huge profit!). -- Gary Murphy decvax!utzoo!dciem!nrcaer!cognos!garym (garym%cognos.uucp@uunet.uu.net) (613) 738-1338 x5537 Cognos Inc. P.O. Box 9707 Ottawa K1G 3N3 "There are many things which do not concern the process" - Joan of Arc
emoffatt@cognos.UUCP (Eric Moffatt) (12/22/89)
In article <461@uwslh.UUCP> lishka@uwslh.UUCP (Not an illusion!) writes: >flee@shire.cs.psu.edu (Felix Lee) writes: > >>The problem with multi-button mice is confusion of buttons. > >No kidding! Three buttons, all being used inconsistently (i.e. using >a DECWindows window manager with Xterm) is a lot of trouble/learning. > >>The problem may be just lack of consistency; every application seems >>to want to use the mouse buttons in a different way. If, say, the >>right button always moved windows around, there may be less confusion. > The problem is certainly a lack of consistency in how the buttons are managed. A fellow named Bill Buxton gives an interesting example of the complexity that people are capable of...a car ! Every part of the part of the body is used; feet controlling levers, hands controlling any number of levers,wheels and dials on a control console that looks like the inside of the space shuttle (on some cars). All of this action takes place while the user's attention is (supposedly (-:) on the road. Yet with only a couple of weeks actual practice we allow new users to take to the roads, usually without untoward results. Mostly, the reason that this is possible is the consistency between car "interfaces" and that most of us are exposed to this interface throughout our early life, not because of the number of buttons on the dashboard. Admittedly, a car runs only one application :-) but please don't tell me that humans are only capable of handling a single button before becoming hopelessly confused. This is more a matter for interface 'style guide' designers than a question of what we are capable of. Consistency between applications (and hardware) has traditionally been a problem in interface design, note the Sun keyboard thread of some months ago. I've personally been through the hassle of taking an interface designed for use with a four-button tablet and trying to map it to a three button mouse. We're still learning. MORE POWER TO THE MOUSE !!!!! :-) and a very Merry Christmas to all... -- Eric (Pixel Pusher) Moffatt - Cognos Incorporated: 3755 Riverside Drive Voice: (613)738-1440 (Research) FAX: (613)738-0002 P.O. Box 9707 uucp: uunet!mitel!sce!cognos!emoffatt Ottawa, Ontario, arpa/internet: emoffatt%cognos.uucp@uunet.uu.net CANADA K1G 3Z4
amull@Morgan.COM (Andrew P. Mullhaupt) (12/24/89)
In article <63649@looking.on.ca>, brad@looking.on.ca (Brad Templeton) writes: > I'm a touch typist, and not so big on mice, one button mice even less. > > But a mouse is a pain because it takes my hands off the home row, > where they are so powerful. A one button mouse is worse because you have > to go to the keyboard for any input that isn't just selecting and pointing. > Even a trackball isn't good enough. Moving hands on and off the keyboard > (as in text editing) slows things down a lot. > Me too. I had a Sun 4 on my desk for six months and if it wasn't for that deeply stupid performance hit for NOT using suntools, I would never have used 'em. As it was, I just made it pop up one big window with real big type, and I left my mouse in my mail basket under who knows what for the duration. The worst thing about that stupid setup was the optical mouse which needed that little shiny surface and would complain if you had it rotated. Utter junk. I'm much happier with SCO UNIX and its multiscreens. I'd like to have more than one window on the screen once in a while, but it isn't often enough for me to bother to find out how to do it. We're going to shift to all X-based stuff in the near future. Oh well. I'll probably be able to circumvet that stupid rat, but I really can't see why I'll have to take any time to bother. The real irony is that the guy we have writing the graphics and X parts of our applications is even more home-position dependent than I am. He needs to always use EMACS primarily because he doesn't even have to use cursor keys, (which I like, if they're in a little triangle just to the right of the main keys). Later, Andrew Mullhaupt
michael@dduck.ctt.bellcore.com (Michael Muller) (01/02/90)
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.comchas@cadlab.UUCP (Charles White) (01/09/90)
> Anyway, how can anyone scroll a window using a one button mouse? (:-)
That was a joke?? Why on earth would anyone implement a scrollbar that
used more then one button?
Chas
chas@cadlab.dewjh+@andrew.cmu.edu (Fred Hansen) (01/11/90)
Excerpts from netnews.comp.cog-eng: 9-Jan-90 Re: Multi-button mice (Re:
.. Charles White@cadlab.UUC (193)
> Why on earth would anyone implement a scrollbar that used more then one button?
Because a click on one button does a page down operation toward the tail
end of the document and a click on the other button does a page up
operation to move toward the top of the document.
In my case, at least, I do not always want to scroll forward; sometimes
I want to back up. And I would like to be able to scroll forward
sometimes by a little bit and sometimes by a lot.
On my favorite editor a click on the left button scrolls forward by the
distance between the top of the window and the place where I click. A
click on the right button goes the other direction. As a result, I can
leave the mouse in one place and move about the document.
(I have a real problem with scroll bars which reverse direction just
because the elevator image has moved past the mouse. All of a sudden
the clicks I was using to move toward the tail end of the document are
now moving me in the other direction.)
Fred Hansenrudolf@satchmo (Jim Rudolf) (01/11/90)
In article <cZesptu00VsPQ2TvYm@andrew.cmu.edu> wjh+@andrew.cmu.edu (Fred Hansen) writes: >> Why on earth would anyone implement a scrollbar that used more then one button? > >On my favorite editor a click on the left button scrolls forward by the >distance between the top of the window and the place where I click. A >click on the right button goes the other direction. As a result, I can >leave the mouse in one place and move about the document. Sure, this is a convenient setup to have, but what do you suggest for folks like me who only use those types of editors occasionally and who for the life of us cannot remember which button scrolls which way? Short of labelling the buttons, I don't know of any way to intuitively assoc- iate a button with a scrolling direction. >(I have a real problem with scroll bars which reverse direction just >because the elevator image has moved past the mouse. All of a sudden >the clicks I was using to move toward the tail end of the document are >now moving me in the other direction.) I agree that if you keep the cursor in the same place, the scrolling behavior shouldn't change. How about if you place the cursor at the bottom of the scrollbar so that when the elevator reaches the bottom and you click on it, nothing happens (similar to the Mac Finder)? Jim Rudolf rudolf@oce.orst.edu (Addresses in header are bogus) Oregon State University
michael@dduck.ctt.bellcore.com (Michael Muller) (01/11/90)
In article <14783@orstcs.CS.ORST.EDU> rudolf@satchmo.UUCP (Jim Rudolf) writes: >In article <cZesptu00VsPQ2TvYm@andrew.cmu.edu> wjh+@andrew.cmu.edu >(Fred Hansen) writes: >>On my favorite editor a click on the left button scrolls forward by the >>distance between the top of the window and the place where I click. A >>click on the right button goes the other direction. As a result, I can >>leave the mouse in one place and move about the document. > >Sure, this is a convenient setup to have, but what do you suggest for >folks like me who only use those types of editors occasionally and who >for the life of us cannot remember which button scrolls which way? Short >of labelling the buttons, I don't know of any way to intuitively assoc- >iate a button with a scrolling direction. In our multifunctional cursor work, we would not assume that we could figure out the "correct" or "intuitive" association of buttons with scrolling directions. Instead, we'd put icons indicating scrolling directions unambiguously in the cursor image (but only when the cursor was in the scroll bar area). These might look like this (as before, please pardon my character rendition of a graphical cursor): /\ ///\\\ /////\\\\\ +----+----+----+ | | | | | /\ | \/ | P | (P might mean "move Proportionately ...") | | | | +----+----+----+ (We'd also permit the user to rearrange the button functions according to her or his preferences.) This approach could also permit clear cuing of a double-click protocol, as well -- perhaps /\ ///\\\ /////\\\\\ +----+----+----+ | | | | | /\ | \/ | B | (Single clicks -- line-oriented scrolling) | | | | (B = Beginning of Text) ++----+----+----++ || | | || || /\ | \/ | E || (Double clicks -- page-oriented scrolling) || /\ | \/ | || (E = End of Text) || | | || |+----+----+----+| ++--------------++ But this would only make sense when the cursor was in the scrolling area. At other times -- e.g., when the cursor was in (one of the) work pane(s) of the application -- its button functions would be related to the domain of of that pane, and the button-specific icons would change to represent those (user-selected?) domain functionalities. Style note: I've drawn these cursor templates with the hot spot at the top, as in most of our work. But for scroll bar use, we might prefer a more "modern" styled, side-pointing cursor shape, with the hot spot at the upper right -- for example -----/ ----/| +--+--+|| | | ||| +--+--+|| | | | +--+--+ Hmn, this _really_ looks much better in a graphic rendition; lets try ...... ...... ......... . . ... ......... . . . ....... Michael Muller Bellcore 444 Hoes Lane Piscataway, N.J. 08854 US ..!bellcore!ctt!michael (201) 699 4892 michael@bellcore.com Michael Muller Bellcore 444 Hoes Lane Piscataway, N.J. 08854 US ..!bellcore!ctt!michael (201) 699 4892 michael@bellcore.com
acm@grendal.Sun.COM (Andrew MacRae) (01/12/90)
In article <cZesptu00VsPQ2TvYm@andrew.cmu.edu> wjh+@andrew.cmu.edu (Fred Hansen) writes: >Excerpts from netnews.comp.cog-eng: 9-Jan-90 Re: Multi-button mice (Re: >.. Charles White@cadlab.UUC (193) > >> Why on earth would anyone implement a scrollbar that used more then one button? > >Because a click on one button does a page down operation toward the tail >end of the document and a click on the other button does a page up >operation to move toward the top of the document. > In addition, it is very usefull to be able to click the middle button and 'zap' to the reletive position in the file.
lubofsky@aerospace.aero.org (Nick Lubofsky) (01/13/90)
>Because a click on one button does a page down operation toward the tail >end of the document and a click on the other button does a page up >operation to move toward the top of the document. > >Fred Hansen I find nothing more frustrating than scrollbars that use more than one button. I can never remember which button is which. Steve Jobs is right; there should be only ONE button on a mouse. ____________________________________________________________________________ Nicholas Lubofsky | Internet:lubofsky@aerospace.aero.org | The Aerospace (213) 336-5454 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Corporation VoiceMailbox 3064 | Life is precious, Love is so rare... | Los Angeles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~