Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site dciem.UUCP Path: utzoo!dciem!mmt From: mmt@dciem.UUCP (Martin Taylor) Newsgroups: net.micro.mac,net.cog-eng Subject: Re: Menubar items without menus are AWFUL Message-ID: <1719@dciem.UUCP> Date: Fri, 18-Oct-85 13:01:25 EDT Article-I.D.: dciem.1719 Posted: Fri Oct 18 13:01:25 1985 Date-Received: Fri, 18-Oct-85 14:13:24 EDT References: <3281@nsc.UUCP> <5387@mit-eddie.UUCP> <1701@dciem.UUCP> <1713@dciem.UUCP> <1052@arthur> Reply-To: mmt@dciem.UUCP (PUT YOUR NAME HERE) Distribution: net Organization: D.C.I.E.M., Toronto, Canada Lines: 104 Summary: > 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