🚀 go-pugleaf

>     The menu bar is not a "menu", it is a "menu bar".  It contains
>"menus", not "menu items".  If something on the menu bar does something
>besides pop up a menu, like save a document for instance, then the poor
>fellow that pops up the wrong menu and runs the mouse across the menu bar
>to the right menu might cause something to happen that he didn't want.
>Active items in the menu bar are unforgiving, not the kind of interface for
>"the rest of us."
>
>                                        Steve Munson

Here is the relevant part of my comments on the Mac out of the paper
on Layered Protocols that I mentioned in an earlier message.  Perhaps
it will address the above comment as well as others that I have received
both privately and over the News.

(If you post a reply to this on the News, please mail me a copy.  I shall
be away for 3 weeks and many items will have expired before I get to them
on my return.  See signature line for address).

================
Let us now consider a single protocol: Menu selection by
Mouse.  In the Macintosh, menus come in several flavours.
There is an ever-present ``menu bar'' across the  top  of
the  screen,  not  associated with any particular window.
Items in this primary menu are selectors for a  secondary
type  of  menu,  sometimes  called  a ``window-blind'' or
``pull-down'' menu, which is revealed when the mouse but-
ton  is  depressed  on  an  item in the menu-bar.  If the
mouse is dragged to an item in  the  secondary  menu  and
then  the  button is released, that item is selected, and
an action performed.  If the item had a  name  ending  in
three  dots  ``...''  the action is to display a tertiary
menu that has yet  another  form,  known  as  a  ``dialog
box.''  In  the  dialog  box  may  be  a quaternary menu,
perhaps showing a list of files available for  selection,
in  a  box  that might have a scrolling control to permit
lists of indefinite length to be  shown.   Some  applica-
tions  display  menus  of  yet  another  form, the ``pal-
lette,'' which displays a set of forms that can  be  used
to change modes in the programme.
     The multiplicity of menu kinds, and the  differences
in the ways they are selected and activated, seem to make
complex a protocol that ought to be simple  and  easy  to
use.   The  messages  available  to the menu protocol are
``Click,'' ``Drag,'' ``Double-Click,'' and one  not  nor-
mally  used ``Button-Release.'' The protocol for the pri-
mary menu is to  select  by  Click.   The  only  possible
action  is  the  display  of  a  sub-menu (there are rare
exceptions, but that only confuses  the  story  further).
Selection from the secondary menu is by Drag, and activa-
tion by Button-Release.   In  the  dialog  box  (tertiary
menu) selection is by Click, and activation by clicking a
separate menu item often labelled ``OK.'' If the  quater-
nary  menu  in  the  dialog  box is used, selection is by
Click, but activation may be by Double-Click or by selec-
tion of a special menu item perhaps labelled ``Open.''
     It might be easier to define a single  protocol  for
selecting  and  for confirming a menu selection, indepen-
dent of the level of the menu in the hierarchy.  The main
characteristic  should be that the mouse and button state
should be the same at the start of the protocol for  each
level  of  the  menu hierarchy, namely mouse off the menu
and button released.  This being the base state, it makes
sense  for  selection (but not the activation) to be done
by moving the cursor onto the desired menu  item.   Feed-
back  indicating  selection  would  be  to  highlight the
selected item, and if the action of the item would be  to
activate a sub-menu, then the submenu should be displayed
so that the user could determine whether it was  the  one
desired.   Moving the cursor off the main menu item would
cause the sub-menu display to vanish.  A single Click  on
the  menu  item  would confirm it and cause its action to
happen.  If the action were to activate a  sub-menu,  the
sub-menu already displayed would be locked, and it in its
turn could be scanned by  running  the  cursor  over  its
items  in  the  same  way.  A second Click, or an initial
Double-Click, would negate the  activation  of  the  sub-
menu,  leaving the sub-menu visible but unlocked.  If the
sub-menu had a large number of items, such as a  list  of
files,  it could be provided with a scroll bar, as is the
current quaternary menu.
     The actions caused by some  menu  items  are  poten-
tially  dangerous  and irreversible.  It might be wise to
require some confirmatory action  from  the  user  before
such  actions are performed.  The Macintosh provides this
confirmatory requirement in the form of a dialog box with
the  menu  options  ``OK'' and ``Cancel.'' Under the pro-
posed protocol,  there  are  various  possibilities:  (i)
require  a  Double-Click for activating a dangerous item.
This is not a good idea, since  it  would  be  an  incon-
sistent  use  of  the  menu protocol, as well as probably
becoming an automatic behaviour on the part of the  user.
(ii)  Rather than performing the action directly, provide
a sub-menu with the options  ``Perform''  and  ``Cancel''
along  with  some  visual  display indicating what danger
lies in performing  the  action  (that  is,  provide  the
information  and  the options that the Macintosh now pro-
vides, but in a different visual form).
-- 

Martin Taylor
{allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt
{uw-beaver,qucis,watmath}!utcsri!dciem!mmt