Path: utzoo!attcan!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: The Mouse and HI design (Was: Re: There *ARE* uses for forcing...)
Message-ID: <8630@goofy.Apple.COM>
Date: 8 Jun 90 22:33:33 GMT
Sender: usenet@Apple.COM
Organization: Future Stuff,  Apple Computer, Inc.
Lines: 52
References:<2291@speedy.mcnc.org> <1990Jun8.200303.19157@d.cs.okstate.edu>

In article <1990Jun8.200303.19157@d.cs.okstate.edu> 
norman@d.cs.okstate.edu (Graham Norman Perc) writes:
> You can't argue Human Interface issues from examples; examples only
> show what _might_ be profitable. To see if it is _truly_ profitable,
> you must write sample programs that use the technique. Then you must
> perform scientific experiments with real users (sophisticated and
> unsophisticated) to see how the new technique affects productivity/

Absolutely right.  

There are 2 good examples from the latest CHI proceedings.  One is a test 
of accelerated (as on the Macintosh) vs. constant-velocity mice, which 
showed that accelerated mice didn't improve user performance.  
(Accelerated mice do save on the required desk space, which may account 
for their favor among users.)

The other tested pull-down menus (as on the Macintosh) vs. a 2-level popup 
 menu system and found that pull-down menus were faster even on a large 
monitor.  (The reason seems to be that the top of the screen acts as a 
barrier making easier to hit the menu titles.)

Both results seem to go against one's intuition about how things should 
work.

> to a program determined position, how about a modifier key that
> makes the mouse twice as fast (or 3x or 4x or ...); this modifier

See above.

> B)  In your scheme, users must
>       1) stop cognitive processes on the primary task,
...
> C)  In my scheme, step (4) would be replaced by "moving the mouse".
>     Because mouse movement is a low-level cognitive function, steps
>     (4) and (5) would be performed at the same time.
...
> shifts, the user is likely to perceive them as faster than normal
> mouse movement when, according to the clock, they may actually be 
> slower. Of course, all this is speculation as I've not done any of

These kinds of factors also enter into the debate of using a graphical 
interface vs. a command-line interface.  Users think that command-line 
interfaces are faster, but according to the clock they aren't.  (This 
according to Bruce Tognazzini, our Human Interface Evangelist; 
TOG@AppleLink.Apple.COM.)

Larry Rosenstein, Apple Computer, Inc.
Object Specialist
(graduate of the Wagner School of Human Interface Design)

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1