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
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to