[2833] in java-interest
Re: warp pointer?
daemon@ATHENA.MIT.EDU (Christophe Meessen)
Tue Oct 17 10:30:26 1995
Date: Tue, 17 Oct 1995 13:12:08 +0100
To: julie melbin <julie@world.std.com>,
Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
From: meessen@cppm.in2p3.fr (Christophe Meessen)
Cc: java-interest@webrunner.neato.org (java)
>I grant you excessive use of this kind of function can be a bad UI - so is
>too many menu pullrights. Bad UI comes from bad design. Don't limit API
>power in fear of bad UI.
The arrow is the visual perception of the of the users "hand/finger". It should
follow the physical mouse movements. If you change the mouse location from
within the system or a program you corrupt this implicit and unconcious
association between a users hand/finger and the pointer.
This is unconfortable. Thanks the Macintosh developper team to have noticed it
and keep the invisible link constant. Note that the Macintosh developper team
does (most of the time) extensive test in situ. They took the time to analyze
users reaction to the application behaviour. I regret that this is most of
the time overseen these days. This make the difference between a confortable and
user intuitive UI and just another GUI.
>>This leaves the user in the unconfortable or frustrating impression that he
>>is not in control of the application or the system.
>>Anyway, even if it was passible/allowed I would never use it.
>
>And you need not be forced to; consider an application where the user
>selected a function like snap-to-grid. This is exactly the kind of UI where
>the user wants the mouse to move in specific ways, guided by the program.
>Note this is always under user control.
When the user use the snap to grid, it the object that is moved that will
snap to grid. At no time it is required that the pointer snap to grids.
In the snap-to-grid example you suggest, it is the object that is supposed
to snap to grid. It will jump to the right location when the user release it
(the button) or it will jump to closest possible location during draging action.
But all along this action the mouse must follow exactly the users hand
movements.
In the Macintosh ToolBox you will not find a command to position the
pointer. This is purposely because the pointer is supposed to be associated
by the user to its finger. Braking the association will brake the
uncouncious link between the pointer and his hand. And this will result in
giving the impression of uncontrolable pointer and tool, unintuitive behaviour.
The Macintosh UI is not just a good idea. It is also the result of extended
testing and analyzing users feedback. This last very important point is mostly
dropped of the progam developpment cycle. The Macintosh guidelines for
developers insisted on the importance of that point.
In summary:
As long as mouses are not able to change position on their own, the pointer
should not change position "on it's own".
In such context mouving the pointer around on it's own is bad UI programming.
As bad as using gotos. Thanks java developper team excluded them.
>Thanks for your comments.
I hope that the Java developper team will examine and study this carfully
before taking a decision.
It is true that it is always possible to add the feature in Java and that I'm
free not to use it. But it is equivalent to gotos. It is also possible to
add gotos in java and leave the choice to use them or not to the users.
The reason for rejecting gotos in Java was that it is well known bad
programming. My argument for disallowing application control of mouse
movement is the same, it is bad UI programming. So for the Java team, I
would say, stick to the logic.
I would be gratefull to hear any counter examples riquiring the aplication
to change the mouse movement/location.
Your welcome.
Bien cordialement,
Ch.Meessen
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
