Bill Schwab wrote:
Not necessarily! Aside from keyboard navigation, the focus might
have moved programmatically (I'm not _completely_ opposed to UI innovations<g>). Beyond that, it matters not why the user moved the mouse; the point is that many users do not want the focus to follow it.
Sometimes the user moves the mouse of "muscle memory" to get the cursor out of the way of reading what is being typed; other times, the blasted cable presses against the coffee cup and moves the mouse. Punishing a touch-typist for this kind of thing is not a ride up in the market.
Great points, thanks. Certainly, also, focus preferences are affected by the type of input device being used. I do 99% of my Squeaking on a laptop with TrackPoint and TouchPad, neither of which is susceptible to accidental mouse movements. Further, these devices allow my hands to remain at the home row and still quickly point at any object I want.
I'm really interested in this topic because, as I've been experimenting with my experimental naked-objects framework, Maui, which insists on mouseOver for focus, I've been appreciating it more and more.
Punishing a touch-typist for this kind of thing is not a ride up in the market.\
Well, the rewards for a touch typist are that it better allows "two-handed" interfaces. One hand on the mouse, the other on the keyboard. Point, keystroke. Point, keystroke. Point, keystroke. Three things just got done with just six gestures.
Yes, it does require one to "calm down" with the mouse, but this comes naturally once the power of pointing sinks in. Its worth a few moments of thought anyway, even if our cerebellums "muscle memory" have little hope of being reprogrammed. :)
Regards..
On 18-Dec-06, at 7:45 PM, Chris Muller wrote:
Well, the rewards for a touch typist are that it better allows "two-handed" interfaces. One hand on the mouse, the other on the keyboard. Point, keystroke. Point, keystroke. Point, keystroke. Three things just got done with just six gestures.
*that* s only going to work well with a one-hand keyboard like the Quinkey/Microwriter system. Many moons ago I specified a 2-and-a-half- D mouse with a quinkey as the physical half of a CAD UI. Mouse moved *and rotated* the pointer. It's a case where us leftys have a real advantage since we can mouse with the left hand and type with the right. Aside, of course, from the advantage of being the only people in our right minds. :-)
I had vague thoughts about using mouse-twist as a typographic control as well. You could gradually twist as you type to smoothly resize the text, or alter the colour or... whatever.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Solid concrete from the eyebrows backwards.
On Tuesday 19 December 2006 09:15, Chris Muller wrote:
Bill Schwab wrote: Well, the rewards for a touch typist are that it better allows "two-handed" interfaces. One hand on the mouse, the other on the keyboard. Point, keystroke. Point, keystroke. Point, keystroke. Three things just got done with just six gestures.
Using mouse cursor to set focus makes sense only when accompanied by buttons, as in click, drag, drop or scroll. Otherwise (like in typing keys), mouse cursor cannot be relied upon to indicate intention on user's part. The mouse could moved accidentally. When I am typing in large body of text, I prefer to keep my hands on the keyboard near the home keys. I want the focus to be around the text cursor; mouse cursor is irrelevant. But for click, drag, drop or scroll, the mouse cursor indicates focus. Text cursor is irrelevant.
Happy Holidays, K. K. Subbu
subbukk wrote:
Using mouse cursor to set focus makes sense only when accompanied by buttons, as in click, drag, drop or scroll. Otherwise (like in typing keys), mouse cursor cannot be relied upon to indicate intention on user's part. The mouse could moved accidentally.
I think of an accidental movement as "noise" in the communication-line between the user and computer. This is more an issue with the 43-year old mouse as an input device. A more fluid input device is needed.
When I am typing in large body of text, I prefer to keep my hands on the keyboard near the home keys.
Of course, me too. And remain at the home row to "point" too (as mentioned, courtesy of TrackPoint). So I essentially have an 87-button mouse and keyboard at my disposal, right at the home row. Far from perfect of course, but it also doesn't suffer the static of accidently moving.
I want the focus to be around the text cursor; mouse cursor is irrelevant. But for click, drag, drop or scroll, the mouse cursor indicates focus. Text cursor is irrelevant.
This combined 87-button mouse and keyboard into "one" input device is more a "higher-bandwidth" human-computer interface than the sum of the two individually because it adds many, many more combinations of short gestures available on the screen to direct the software (e.g., 87 per visible non-text widget instead of.. about 4). All of these many more "valid" gestures are within "easy reach" (one point, one key); but only if the underlying software is capable of leveraging this (e.g., mouseOverForFocus).
I can see that the input device really matters, because "point, key" is a lot of switching back and forth with docking-station and mouse (which I never use).
I'd like to point out one other unintended side-effect of this. Besides more productive, I have found it more "serene". Not because its been a more "efficient" way to direct the software, but because of the consistency with which direction occurs (e.g., point, key).
Certainly, it takes getting accustomed to the other when you are used to one..
Cheers!
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
subbukk -
tim Rowledge