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