Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!ncar!oddjob!mimsy!brillig.umd.edu!don
From: don@brillig.umd.edu (Don Hopkins)
Newsgroups: comp.windows.misc
Subject: Re: DOS & MS-windows Vs. Unix & X experience + MS-windows Flame
Summary: It's OK to move the cursor!
Message-ID: <11814@mimsy.UUCP>
Date: 5 Jun 88 08:55:00 GMT
References: <10799@apple.Apple.Com> <10700006@hpfclp.SDE.HP.COM> <5034@june.cs.washington.edu>
Sender: nobody@mimsy.UUCP
Reply-To: don@brillig.umd.edu.UUCP (Don Hopkins)
Organization: U of Maryland, Dept. of Computer Science, Human Computer Interaction Lab
Lines: 64

In article <5034@june.cs.washington.edu> roper@june.cs.washington.edu (Michael Roper) writes:
>John Diamant writes:
>>
>> Also, moving the mouse sprite over the dialog box is generally considered
>> to have poor human factors.
>
>Could you elaborate?  Seems to me to be a pretty good way of doing things.
>Especially if the dialog box is modal.
>

I don't think you can make sweeping statements about what techniques
are or are not good human factors, without taking into account the
application.

I think that there are situations in which moving the cursor on the
screen, with no corresponding movement of the mouse, is very
appropriate.

For example:

Idealy, a pie menu should pop up centered on the point where it
was invoked, so that the cursor starts out in the inactive menu center,
with all the selections around it in a circle.

However, if the pie menu is invoked near the edge of the screen, the
menu window must be moved so that it fits entirely on the screen, so
the user can see and select every slice. The cursor must also be moved by
the same distance that the menu was moved from its ideal
position, so that the cursor is not left behind in an unexpected
slice. Note that once the menu has popped up, the cursor may have
traveled some distance from where it was when the menu was invoked.
It's important to move the cursor to its CURRENT position plus the
distance the menu was moved, as opposed to moving it from the menu
invocation point plus the distance the menu was moved. If this is
implemented right, it feels quite natural, and pie menus are reliable
near the screen edge. If it's implemented wrong, or the cursor is not
moved at all, it's very annoying -- and THAT's poor human factors!

Another example is the way the OPEN LOOK scroll bar works:

With Macintosh style scroll bars, clicking in the bar above or below
the elevator brings the elevator towards the cursor by a certian
ammount. If it's already near enough to the cursor, the elevator can
move to the other side of the cursor, so the next click in the same
place will make the elevator move in the other direction back over the
cursor.  In this state, multiple clicks will cause the elevator to
oscilate back and forth around the cursor.

The OPEN LOOK scroll bars are different, in that they have arrow
buttons on the top and the bottom of the elevator, instead of at the
top and the bottom of the scroll bar. That means that if you're
clicking the arrow buttons to move up or down by lines, you don't have
to move the cursor all the way to the other end of the scroll bar to
press the other button, if you overshoot. What happens when you press
one of the buttons on an OPEN LOOK scroll bar elevator is that the
elevator moves up or down a little bit, and the cursor moves up or
down by the same ammount, so that it's still over the same button!
You can keep clicking the button, without moving the mouse, and your
cursor moves along with the elevator!  I consider that good human
factors -- it's how a real elevator works! Who would use an elevator
that you have to run up the stairs to catch, after pressing the up
button??!

	-Don