setting pointer location

[David Vaughan]

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 :-)

regards
David
> -- 
>
> Rob Cozens
> CCW, Serendipity Software Company
> http://www.oenolog.com/who.htm
>
> "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
> http://lists.runrev.com/mailman/listinfo/use-revolution
>