setting pointer location
dvk at dvkconsult.com.au
Fri Dec 27 21:24:01 EST 2002
On Saturday, Dec 28, 2002, at 08:57 Australia/Sydney, Rob Cozens wrote:
>> The former action obviously works well while the latter I personally
>> abjure when writing and object to when using.
> My question, David, would be, "Is you abjuration theoretical or based
> on experience where the technique was actually manifested in
> operational software?" Since you included "and object to using", you
> must have found some real world software that does this. Are these
> Mac or Windows apps? And what genre?
> I don't recall ever seeing a real-world manifestation of the
> technique. I never explored it, because I couldn't find a way to do
> it in HyperTalk; but it occurred to me that OenoLog's button-driven
> interface might benefit operationally if the mouse cursor could be
> positioned over the next default button via script.
> I doubt I'll change the OenoLog UI to play with the technique even
> though I could in Run Rev. If you've seen it in operation and found
> the technique lacking or distracting, that's the first concrete point
> against it in my score book...however I would want to know the context
> in which you found it a poor approach before ruling it out altogether,
> once & for all.
Rob, practical experience drives my theory in this instance (although
often I go in the other direction). I never thought about it until I
encountered it and thought "what the hell is my cursor doing there?"
with "there" being the wrong place because, being human, I had already
started moving the mouse to the right place even before the interface
had responded to my last click. The result of my own anticipation was
that I was now below and to the right of the required place rather than
homing in on it from top-left, having effectively shifted the mouse off
the right place the software had so "helpfully" put it - my mouse
movement continuing briefly after the dialog had appeared.
In interaction terms, if I knew that the software would behave that
way, then I would passively click, wait, see if the mouse was in the
right place and then click again or move it as required. I normally use
software rapidly by active mouse movement, actions ahead or in
anticipation. If I _know_ what the software behaviour will be, I can
adjust of course but the most common situation is that the software can
not anticipate your next action - it presents objects and waits for
your selection and action. Therefore, expected behaviour is no mouse
relocation by the software, as the user is in control. This is quite
different from directed tabbing between fields, as I said earlier.
One place I encountered it is certain confirmation dialogs in Windows.
This is not a Windows-objection thing (you know I mostly use a Mac) but
just strange behaviour - if the idea of a confirmation dialog is to
make sure the user really wants to take this more serious action, why
turn the action into a minimal click-click without even a button
selection (by mouse movement) in between? In an earlier generation of
database design I removed prompts like "Delete, OK?" from dBase and
Dataflex apps in favour of an undo, because I found that users became
so accustomed to hitting Enter-Enter that the confirmation served no
practical use on the occasions you actually needed it; yet added a
small delay to data entry. Hence the rise of Undo, which allows actions
to fail gracefully, as it were.
A bit long-winded but I think I got close to a theory there :-)
> Rob Cozens
> CCW, Serendipity Software Company
> "And I, which was two fooles, do so grow three;
> Who are a little wise, the best fooles bee."
> from "The Triple Foole" by John Donne (1572-1631)
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the Use-livecode