Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

Schwab,Wilhelm K
Chris,

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.

Bill


Chris Muller wrote:

> Now, the biggest annoyance about morphic is that I
cannot use my
> >keyboard properly, e.g. I have to point my mouse to
an input box
> >before typing.

I never understand this.  To get initial focus you clicked that
window,
so why move the mouse away?




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029


Reply | Threaded
Open this post in threaded view
|

Re: Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

timrowledge

On 18-Dec-06, at 3:22 PM, Bill Schwab wrote:


>
> I never understand this.  To get initial focus you clicked that
> window,
> so why move the mouse away?
In my experience you don't have to - not deliberately anyway. Unless  
you are one of the worrying psychopaths that somehow manages to have  
a completely clean desk there is always something that will knock a  
mouse and move the pointer inadvertently. Even the mouse tail can be  
stiff enough or twisted and cause it to inch away.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Quo signo nata es? = What's your sign?



Reply | Threaded
Open this post in threaded view
|

Re: Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

keith1y
> psychopaths that somehow manages to have a completely clean desk
As a friend of mine used to say... "empty desk... empty mind!"

Keith
Send instant messages to your online friends http://uk.messenger.yahoo.com 

Reply | Threaded
Open this post in threaded view
|

Re: Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

Chris Muller
In reply to this post by Schwab,Wilhelm K
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..


Reply | Threaded
Open this post in threaded view
|

Re: Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

timrowledge

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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Solid concrete from the eyebrows backwards.



Reply | Threaded
Open this post in threaded view
|

Re: Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

K. K. Subramaniam
In reply to this post by Chris Muller
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

Reply | Threaded
Open this post in threaded view
|

Re: Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

Chris Muller
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!