Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!usc!apple!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.cog-eng
Subject: Re: Menu Interaction Techniques
Summary: Eating at the menu tree.
Keywords: mouse ahead, pie menus
Message-ID: <14011@well.UUCP>
Date: 9 Oct 89 07:52:11 GMT
References: <2722@trantor.harris-atd.com> <16179@brunix.UUCP> <19812@mimsy.UUCP> <523@sunfs3.camex.uucp>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 69

+-- kent@lloyd.UUCP (Kent Borg) writes:
| In article <19812@mimsy.UUCP> don@brillig.umd.edu.UUCP (Don Hopkins) writes:
|  [ ... ]
| The other value to menus is that they present the user with choices
| which must be recognized, but need not be remembered.  Seen from that
| perspective, the Macintosh menu bar is not a linear menu system.
| Rather it is a very compact 2-dimensional menu system.  The user can
|  [ ... ] quickly be presented with
| well over a hundred uncluttered menu choices.
| 
| The speed and ease with which the user can see all of the first level
| menu choices is very important.  It is one of the reasons I can sit
| down at a new Macintosh program and immediately start using it.
|  [ ... ]
| How do pie menus do at quickly presenting the user with lots of
| choices?

So what's so great about hundreds of menu choices?  Most of the programs
I've seen with these kinds of menus suffer from what I would call, "digital
watch syndrome."  Dozens of different functions are all cramed together
into the same interface without regard for a logical, coherent structure
for them to coexist.  The result is like those watches that do about 57
different things all controlled with four buttons.

The Xerox Star interface had very few menus, perhaps half a dozen or a 
dozen per application, and most of those were "expert features."  Much
of the interaction was done through "Property Sheets," which were
control windows that let the user set the attributes of an object in
the interface.  The user selects the object she wants, presses the 
PROP'S key on the keyboard, and the property sheet opens, which can
be examined and optionally modified.  Probably 90% of the interaction
was done using property sheets and a set of eight standard function
keys that operated polymorphically across the objects in the system.
(Sort of like the Cut, Copy and Paste are supposed to work on the 
Mac, but don't.)

The result is a much more "browse-able" interface.  The user need only
be concerned with the object that needs changing at the moment, and 
never even needs to see the options available for any others.  The user
also doesn't have to figure out by trial and error which commands and
options apply to which objects.  If she wants to change the attributes
of a paragraph, she just selects that paragraph and looks at its 
properties.  All the properties for a paragraph are right there.

It's true that all the options in a Mac program are visible 
immediately, but I don't necessarily consider this an advantage. 
Global and object-specific commands, as well as global and
object-specific options are all intermixed in the same
hierarchical menu structure, with only very loose guiding principles
for what items go together or don't.  If someone thinks of a neat feature,
it can just be added to the menu somewhere, like another digital watch
function.

The Star had a lot of really nice ideas that seemed to get dropped
along the way somewhere.  When I first started playing with the Star-
style of user interface only a short time ago, I was quite astonished
at how it got by with so few menus, and replaced a proliferation of
menus with a system of interaction that was better organized, cleaner
and easier to learn.  The trend these days seems to be that if a 
program has more menus, it must be better.  I would be very happy if
this reversed, so that a program with fewer menus was considered the
better.

P.S.  A Xerox Star retrospective was published in an IEEE mag recently.
Perhaps someone would be kind enough to give the full reference, as
my Xerox copy doesn't.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(ferguson@metaphor.com)