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.