Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!lll-winken!uunet!mcsun!cernvax!pan!aratar!chac
From: chac@aratar.UUCP (Chuck Clanton)
Newsgroups: comp.cog-eng
Subject: Re: Menu Interaction Techniques
Message-ID: <345@aratar.UUCP>
Date: 28 Sep 89 08:36:07 GMT
References: <2722@trantor.harris-atd.com>
Reply-To: chac@aratar.UUCP (Chuck Clanton)
Organization: Adasoft AG, Solothurn, Switzerland
Lines: 57

In article <2722@trantor.harris-atd.com> chuck@trantor.harris-atd.com (Chuck Musciano) writes:
>I am currently in the midst of a quandary involving two different
>menu interaction techniques...
>Is there anything in the literature which supports either (or both) of
>these claims?  Any thoughts or opinions?

With apologies that this is not an answer to your question, but I have 
some experience with a related popup menu interaction technique that 
seems quite useful so I thought you might like to hear about it. 

I am using a menu assisted text editor where the menu items are always 
the same and always in the same position with the exception that the 
most recent search string is added to the bottom of one menu, and the 
various windows/files that have been opened are available for selection 
at the bottom of another menu.  However, when you pop up a menu, the 
highlighted item is always the last item selected.  My first thought
was that this would make it hard for me to learn to find menu items since
my starting place was always different.  Probably true but it has not 
turned out to be a very big loss since, as others have pointed out, 
selection from linear menu arrays never quite has the facility of 
"touch typing" anyway.  Instead I quite like the fact that this menu 
interaction style creates kinesthetic "idioms" that are useful and quite 
a bit like touch typing.  For example, repeating a search is done by first 
typing a search string and executing it, then the second time carefully 
selecting the search string on the menu from the middle mouse button popup 
menu (presuming the last use of that menu was not for a search).  Then, 
subsequent searches are done by merely clicking the middle button rapidly 
without looking.  Similarly, if I want to paste the same string in multiple 
places, I can select the location on the screen with the mouse then 
carefully select the paste menu item, then select another place and paste 
with a single rapid click.  Another frequent idiom is to select with the 
mouse, then click on the cut menu item.  Repetion here also becomes a 
simple select/click idiom.

With three mouse buttons, I have the potential for interleaving three 
"current" actions.  So far, I have not noticed using more than two, and 
some frequent sequences are not possible because they appear on the same 
menu.  The menus are arranged logically, and I wonder if that is optimal.
They are easier to learn as a result, but perhaps it would be better to 
look for the highest frequency of paired actions (search-paste, for 
example) and put those on different menus.  

This brings up another more subtle idiom.  I changed the menus to place 
the search string and paste items adjacent thereby disrupting the "logical"
order of the menu items.  While the repetetive action of search and replace 
is not quite a simple click, it did become "touch typable" as well.  I 
was able to learn the amount of movement to go to an adjacent menu item 
so I can go back and forth between the two items without visual confirmation.

Finally, one difficulty with this scheme.  It is not easy to click the 
mouse without a small cursor movement.  There is evidence that this is 
a very common user error.  Larry Tesler described the solution that I believe
apple used in the lisa and in the mac.  The mouse driver ignores small 
movements occurring with a button click.  The interface I described above
is quite sensitive to the much more "accurate" mouse driver of my $20,000
workstation.  So while I dont have to look at the screen, I do have to
be quite careful to hold the mouse still while clicking the button.