Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!hplabs!hpl-opus!hpccc!hp-sde!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.SDE.HP.COM (John Diamant)
Newsgroups: comp.windows.misc
Subject: Re: DOS & MS-windows Vs. Unix & X experience + MS-windows Flame
Message-ID: <10700008@hpfclp.SDE.HP.COM>
Date: 7 Jun 88 00:56:46 GMT
References: <10799@apple.Apple.Com>
Organization: HP SDE, Fort Collins, CO
Lines: 41

> >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.

This is true.  General rules make sense, but there may be extenuating
circumstances that take priority over the general rule (they still have
to have a good reason!).

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

[discussion of a pie menu partially off screen omitted]

I agree.  This makes sense in menus and is probably O.K. for
dialog boxes that come up as a result of direct user action as opposed
to one that pops up because of some background process.

I see now that I didn't actually correctly specify the condition under
which warping the mouse is bad.  It is not a universal, certainly.  The
rule is that the system should not take control of the input focus away
from the user.  It should not take control, in general (this is partly
what causes novice computer users to be scared by computers).  If the
user's input focus was already on the menu or some action which caused a
dialog box to pop up immediately, then there is no problem in correcting
the location of the mouse.  This is because the user is the one who decided
to perform the action.  On the other hand, in a multi-tasking system
where a dialog box pops up because of some background processing, it would
be extremely bad human factors to grab the input focus by taking his
mouse sprite away while he may be in the middle of something else.  That
was the point I was really getting at, though I didn't specify it
sufficiently.


John Diamant
Software Development Environments
Hewlett-Packard Co.		ARPA Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		UUCP:  {hplabs,hpfcla}!hpfclp!diamant