halvers@iraq.UUCP (06/03/88)
In article <5034@june.cs.washington.edu> roper@june.cs.washington.edu (Michael Roper) writes: >John Diamant writes: >> >> Also, moving the mouse sprite over the dialog box is generally considered >> to have poor human factors. > >Could you elaborate? Seems to me to be a pretty good way of doing things. >Especially if the dialog box is modal. > >Mike Roper I think the reference is not to moving the cursor over the box per se, but rather to the concept of the application changing the mouse position independent of user control. Both Sun's and Apple's documentation discourage this, since apparently much of mouse control is tied to kinesthesia ("muscle memory"), which having the cursor bop all over the place interferes with. One example of an interface that does tend to move the cursor around a lot is Interleaf's [WT]PS system. If you drop down into a folder hierarchy, selecting and opening folders/cabinets/drawers/refrigerators/closets, the cursor is moved to the newly opened window. Similarly, closing a window moves the cursor back to the parent window. I still haven't decided if I really like this style: it's convenient, sure, but rather confusing when first encountered ("where did my cursor go? It was down here a second ago!") I suspect this is one of those style issues that needs to very well disciplined to succeed, otherwise it'll just make things less consistent across applications. Anybody heard of any definitive investigation into this? ~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Pete Halverson ARPA: halverson@ge-crd.ARPA GE Corporate R&D Center UUCP: uunet!steinmetz!iraq!halvers Schenectady, NY halvers@iraq.steinmetz.UUCP "You may be a vampire, but you're still my brother!" -- The Lost Boys
ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) (06/05/88)
[on automatic mouse cursor movement] The X windowing system has "warping" which will move the mouse cursor to the middle of the newly activated window. I agree with the sun/apple people that this is VERY distracting (what? where did my mouse cursor go? oh! it's *way* over there!?!). if you had a very small screen it might not be to distracting, but normally I will keep a bunch of windows closed down, then descide to open up all the windows to machine "mist". if I left warping on (I have it turned off as much as possible) I would have to move the mouse all the way back over to the next icon to open it, then all the way back to open the next icon, etc. (i.e., I would have *LOTS* of wasted mouse movement). --ritchey ruff ruffwork@cs.orst.edu -or- tektronix!orstcs!ruffwork
jg@jumbo.dec.com (Jim Gettys) (06/07/88)
In article <4964@orstcs.CS.ORST.EDU> ruffwork@orstcs.CS.ORST.EDU.UUCP (Ritchey Ruff) writes: >[on automatic mouse cursor movement] >The X windowing system has "warping" which will move the mouse cursor >to the middle of the newly activated window. I agree with the sun/apple >people that this is VERY distracting (what? where did my mouse cursor >go. . . . . . . I certainly heartily agree that "warping" the pointer is a VERY bad idea. All the psychologists agree that people find it very distracting. There are few times when it is necessary; unfortunately, there are a few times when it is needed. (Scripts to drive the window system for testing is one example.) And therefore in line with X's mechanism orientation, X provides the capability. So as usual, X provides the length of rope to hang yourself. I don't recommend tying one end to you neck and the other end to a tree branch, which is what XWarpPointer is; use the rope for some worthwhile purpose, and don't kill yourself or others. - Jim Gettys
janssen@titan.UUCP (06/08/88)
While I generally agree that warping the mouse (say to the center of a
newly de-iconified xterm) is usually distracting, it can come in handy.
We have a version of GNU Emacs that supports multiple Emacs-Screens, where
each screen is a single X10 window. The minibuffer is one such E-Screen.
When you ^X^F, you expect the minibuffer to become the selected Emacs
window, which will only happen if the E-Screen of the minibuffer is the
selected X10 window ("real estate" focus management). For some
time we didn't warp the mouse; the user had to type ^X^F, then move the
mouse to the minibuffer, then type in the file name, then move the mouse
back. Truly a pain. Warping the mouse turned out to be a simple and
natural way of solving the problem.
Billraveling@vaxa.isi.edu (Paul Raveling) (06/08/88)
In article <2158@uoregon.uoregon.edu> jqj@drizzle.UUCP (JQ Johnson) writes: >Not all pointing devices are mice. With "absolute" pointing devices >such as tablets, light pens, or touch screens, it is extremely >undesirable to break the 1-1 mapping between absolute physical pointer >position and logical pointer position. Although I'm not averse to >semiautomatic mouse cursor movement (e.g. in response to a mouse click >or menu selection), I worry that such a user interface design makes the >system far less flexible. As Jim Gettys pointed out, it is RARELY appropriate to warp the cursor, but there are a few situations that demand it. Those I've seen tend to involve maintaining a semantic context when associated graphics change. One example is rotating or reflecting symbols in a schematic editor. Semantic context for editing operations tends to be a hierarchy of objects marked by the mouse, such as... Drawing set Specific drawing Area within drawing Symbol (e.g., image of an IC chip) Component of symbol (e.g., label of a pin) If the cursor marks a pin near a corner of a rectangular chip symbol, and the user commands a 90-degree rotation by hitting a function key, leaving the cursor alone drops the bottom two objects of the semantic context. Early experiments while adding rotation in FutureNet's DASH-4 editors showed that this was EXTREMELY annoying -- the user had to chase the object he was editing. The solution that worked well was to warp the cursor to the graphic position that maintains the same low level context. I think the key notion is to do whatever preserves the context -- usually this means NOT warping the cursor. --------------------- Paul Raveling Raveling@vaxa.isi.edu
jimc@iscuva.ISCS.COM (Jim Cathey) (06/09/88)
In article <735@titan.SW.MCC.COM> janssen@titan.SW.MCC.COM (Bill Janssen) writes: >...time we didn't warp the mouse; the user had to type ^X^F, then move the >mouse to the minibuffer, then type in the file name, then move the mouse >back. Truly a pain. Warping the mouse turned out to be a simple and >natural way of solving the problem. This is where having the input focus separate from where the mouse pointer resides comes in handy. The Mac works this way -- you need to do more than just move the mouse to change input focus (clicking is the 'blessed' way). The program could then 'select' the minibuffer window and move input focus to its text-entry field, then restore the original window/focus -- all without disturbing the position of the mouse pointer. (Many Mac programs do this for things like WP search/replace.) I _like_ the separate text-entry winking cursor, with the mouse pointer dis- appearing while you're typing (it re-appears when you move the mouse). I tend to think of that mouse pointer as _mine_, much the same as my finger. I view mouse warping with as much enthusiasm as I would a small man reaching over my shoulder to move my hand for me. Often. At _his_ whim. I suppose it would be a pain if you routinely had to switch input focus a lot, the extra clicking could drive you batty -- but do you really need to do this much? Just curious.
jimc@iscuva.ISCS.COM (Jim Cathey) (06/09/88)
Sorry, forgot the signature. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
aperez@blazer.uucp (Arturo Perez Ext.) (06/10/88)
From article <4964@orstcs.CS.ORST.EDU>, by ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff): > [on automatic mouse cursor movement] > The X windowing system has "warping" which will move the mouse cursor > to the middle of the newly activated window. I agree with the sun/apple > people that this is VERY distracting (what? where did my mouse cursor > go? oh! it's *way* over there!?!). if you had a very small screen > it might not be to distracting, but normally I will keep a bunch > of windows closed down, then descide to open up all the windows to machine > "mist". if I left warping on (I have it turned off as much as possible) > I would have to move the mouse all the way back over to the next icon > to open it, then all the way back to open the next icon, etc. > (i.e., I would have *LOTS* of wasted mouse movement). > > --ritchey ruff ruffwork@cs.orst.edu -or- tektronix!orstcs!ruffwork This may be distracting but it is also very useful. The way that I use warping follows the following scenario. I like to open windows to various machines (using X's network features), iconify them and line them up along one side of the screen. Now, when these windows are "opened" or de-iconified where they pop up lies nowhere near where the icon sat. I liked the old feature of X10 whereby a window that requested it could warp the pointer to the window's open location. That meant I could pop open a window and immediately be able to type into it. I wish that the window manager would allow windows to be selectively warped by a keystroke of some sort. That would prevent the case of wanting to open several windows and each annoying you by warping the mouse halfway to china. ------------------------------------------------------------ Arturo Perez ComputerVision, a division of Prime primerd!cvbnet!aperez 14 Crosby Drive Bedford, MA The difference between genius and idiocy is that genius has its limits. ------------------------------------------------------------ Arturo Perez ComputerVision, a division of Prime primerd!cvbnet!aperez
chan@hpfcmr.HP.COM (Chan Benson) (06/10/88)
> When you ^X^F, you expect the minibuffer to become the selected Emacs > window, which will only happen if the E-Screen of the minibuffer is the > selected X10 window ("real estate" focus management). In X10 you can in fact assign the keyboard input focus to a window regardless of where the mouse is (see XFocusKeyboard). It was not necessary for you to warp the mouse. -- Chan Benson HP Fort Collins
eric@batcomputer.tn.cornell.edu (Eric Fielding) (06/11/88)
In a recent article jimc@iscuva.ISCS.COM (Jim Cathey) wrote: >This is where having the input focus separate from where the mouse >pointer resides comes in handy. The Mac works this way -- you need to do >more than just move the mouse to change input focus (clicking is the >'blessed' way). I also like the way that the Mac does this. The DEC VAXstations running the VMS window manager called UIS (I think) does the same thing. You have to click the mouse on a window to change the input focus. The good thing about this is that you can then move the mouse out of the way. I hate having a mouse get between me and the text I am typing. ++Eric Fielding
halvers@iraq.steinmetz (Pete Halverson) (06/14/88)
[Dave Riches (riches@uk.ac.essex) sent me the following, which I thought was worth passing on to the Net ---PCH] I work on a project called Adaptive Intelligent Dialogues which is sponsored by Alvey in the United Kingdom. During the course of ourt research into adaptive mechanisms we played around with Adaptive Mice. The idea was to see if we had enough information at the mouse level to provide adaption for the user. If we could work out the user's intentions when moving the mouse then we could 'second guess' the user and put the mouse where it was wanted. Firstly we had to see whether users liked having an adaptive mouse. The mouse adapted to the direction and speed of movement which the user was applying to it. We had various strategies such as speeding the mouse up in any direction, or like a black hole effect drawing the mouse in the direction of greatest movement etc. This experiment was performed on a Sun 2/120. The main conclusion was that users did not like non-deterministic mice. The users preferred a mouse which moved faster than the normal sun speed but they did not like the ones which predicted where they were going and helped them in that direction. There was one interesting strategy though. This used prediction and moved at 3 times the normal speed BUT decelerated to normal sun speed at a distance of less than 2cm from its objective. This strategy was consistently 2nd out of the 8 strategies being beaten only by a 2 times strategy. Generally it was felt that because there is such a tight feedback loop between the user's hand-eye movement then any interference to this was detrimental to the user's performance. As regards applications which move the mouse automatically, Smalltalk 80 and XSIS-Analyst do this. I sometimes find this irritating especially when it is not a consistent strategy across the application. Otherwise as you say, if the style of movement is consistent then it should be ok. dave -------- ~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Pete Halverson ARPA: halverson@ge-crd.ARPA GE Corporate R&D Center UUCP: uunet!steinmetz!iraq!halvers Schenectady, NY halvers@iraq.steinmetz.UUCP "You may be a vampire, but you're still my brother!" -- The Lost Boys
blarson@skat.usc.edu (Bob Larson) (06/14/88)
All this talk about mouse movment has me wondering why noone has
sugested the obvious: when the mouse cursor moves, have the mouse
crawl to the corresponding place on your desk. Additional feedback
could be added: have the mouse bite when something wrong is attempted.
Some of the details may need to be worked out, such as: should the
mouse be willing to jump off the table? :-) (I have 4 terminals, but
the only mice I have are the furry kind.)
--
Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list: info-prime-request%fns1@ecla.usc.edu
oberon!fns1!info-prime-requestgeorge@mnetor.UUCP (George Hart) (06/15/88)
In article <5663@venera.isi.edu> raveling@vaxa.isi.edu (Paul Raveling) writes: > As Jim Gettys pointed out, it is RARELY appropriate to > warp the cursor, but there are a few situations that > demand it. Those I've seen tend to involve maintaining > a semantic context when associated graphics change. I think your example describes a situation, where given the design of the package, warping makes sense to preserve the user's sanity. In general though, there are few situations where the design space is so limited that warping is necessary/desirable/acceptable. As a window system implementor (and user), warping strikes me as bad manners (mainly because it usually violates the principle of least surprise). I receive many requests for the cursor to be warped for convenience in the requestor's favorite situation(s). The problem, of course, is that the notion of "convenience" varies by situation, requestor, and phase of the moon. -- Regards, George Hart, Computer X Canada Ltd. NOW REAL SOON NOW UUCP: utzoo UUCP: utzoo >!mnetor!george > cxhi!george uunet uunet BELL: (416)475-8980
sierch@well.UUCP (Michael Sierchio) (06/16/88)
Does this study indicate failure of the predictor used, or does it indicate
that attempting to predict where the user is attempting to move the pointer
is not a good idea??
The Macintosh uses a simple method that is equivalent to one type of
predictor method, without regard to the screen content -- the pointer
movement speed is automatically changed according to the mouse speed.
When the user gets closer to the target, he/she slows down the mouse,
and the positioning becomes more precise.
Using anything other than a first-order predictor is likely to give the
user the feeling he/she's not really in control.
--
Michael Sierchio @ Small Systems Solutions
sierch@well.UUCP
{pacbell,hplabs,ucbvax,hoptoad}!well!sierch