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

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

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

Schwab,Wilhelm K
Chris,

What about the common scenario of writing software for users who are
not going to change?   It can manifest as avoidable training costs,
matching user expectations to avoid support hassles, or simply not
biting the hand that feeds us.

Bill




Chris Muller:

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

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!




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