radford@calgary.UUCP (Radford Neal) (10/09/85)
Somebody's got to say it...
The idea of clicking on a menu item causing an action in itself, without
a subsequent selection, is TERRIBLE.
The present interface makes "browsing" through menus a very desirable
activity for a user to engage in. It lets him know what commands are
available, their command key equivalents, etc. If a menu item is followed
by "...", he knows that he can furthermore select it to see what its
dialog box is like, without worrying that it might do something he doesn't
want. (The dialog box had *better* have a "cancel" option, or we'll send
around the boys...)
If I understand it properly, the proposed extension would eliminate this
useful behaviour, and no doubt result in many mangled documents before users
caught on to the change.
Radford Neal
The University of Calgaryclive@druri.UUCP (StewardCN) (10/10/85)
Couldn't agree more. The ability to browse the menu line without actions happening is completely important. Even for an experienced user. Clive
mmt@dciem.UUCP (Martin Taylor) (10/11/85)
>The idea of clicking on a menu item causing an action in itself, without >a subsequent selection, is TERRIBLE. > >The present interface makes "browsing" through menus a very desirable >activity for a user to engage in. It lets him know what commands are >available, their command key equivalents, etc. If a menu item is followed >by "...", he knows that he can furthermore select it to see what its >dialog box is like, without worrying that it might do something he doesn't >want. (The dialog box had *better* have a "cancel" option, or we'll send >around the boys...) > The idea of having a special symbol to show that a menu item will bring up a sub-menu is a good one. Why not extend it to the menu bar, for consistency. In general, selecting a menu item (and I'm not just talking Macintosh) causes something to happen; that something is often a new level of menu. Consistency demands that the items on the menu bar be treated like any other menu items. If their names are followed by "...", then they should bring up sub-menus when they are clicked. Otherwise, they should DO something. For example, a menu-bar item called "Quit" would be much nicer than the non-obvious sequence "File ... Quit." Similarly, "Save" could often be useful on the menu bar instead of in a sub-menu. The only use for sub-menus is to reduce the number of things that have to be scanned in a single menu level, and to ensure that those things that belong conceptually together are scanned together. Major controls for the operation of the computer/application should normally be at the top level, readily accessible without having to be sought in places that might be obscure to the unskilled user. While I'm on the topic, the idea of command-key equivalents for menu items scattered all through the menus of an application is TERRIBLE. The command keys should be unique to a sub-menu, NOT to the whole set of menus and sub-menus. It would be better if the menu-item name could be typed as a whole in order to cause its action, as an alternative to (a) clicking on the menu and sub-menu items, or (b) typing a sequence of 2 or more command characters (only 1 for top-level menu items on the menu bar). For consistency, again, all menu items should be treated alike. All menu functions should be accessible from the keyboard (especially if your mouse is dead), not just some of them, and those by obscure and inconsistent single keystrokes. -- Martin Taylor {allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt {uw-beaver,qucis,watmath}!utcsri!dciem!mmt
sbm@arthur (Steven B. Munson) (10/16/85)
In article <1713@dciem.UUCP>, mmt@dciem.UUCP (Martin Taylor) writes: > .... Consistency demands that the items on the menu bar be treated > like any other menu items. 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 sbm@Purdue.EDU sbm@Purdue.CSNET
radford@calgary.UUCP (Radford Neal) (10/17/85)
> > >The idea of clicking on a menu item causing an action in itself, without > >a subsequent selection, is TERRIBLE. > > > >The present interface makes "browsing" through menus a very desirable > >activity... > The idea of having a special symbol to show that a menu item will bring > up a sub-menu is a good one. Why not extend it to the menu bar... > > Martin Taylor > {allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt > {uw-beaver,qucis,watmath}!utcsri!dciem!mmt Something like this *might* make clicking on the "menu" name acceptable. Putting "..." after all existing menus could be a problem though (for one thing, they might not fit any more). It also would look ugly. Given that we're retrofitting this, it might be better to put a special symbol after those menu names which *don't* have menus. Unfortunately, nobody is going to know what it means at first. I'm still not convinced it's worth it, at this stage at least. Radford Neal
pugh@cornell.UUCP (William Pugh) (10/18/85)
If you want to put active items in the menu bar, you should make
them look totally different from menus. For example, for something that
activated when you clicked on it, you should put a button in the menu bar.
You might also put check boxes in the menu, although there is not that much
room.
Although I'm not wild about the idea of active menus bar items, if
they were done this way I think most users would be able to figure out
how they worked.
--
Bill Pugh
Cornell University
..{uw-beaver|vax135}!cornell!pugh
607-257-6994mmt@dciem.UUCP (Martin Taylor) (10/18/85)
> 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
peter@graffiti.UUCP (Peter da Silva) (10/21/85)
> 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." You can't trigger something by running the mouse along the menu bar even if the items are active. You would have to release the mouse button, just as you now do when running down the "Files" menu. There are active items there, but you can't set them off by accident either.
peter@graffiti.UUCP (Peter da Silva) (10/21/85)
> Something like this *might* make clicking on the "menu" name acceptable. Putting > "..." after all existing menus could be a problem though (for one thing, they might > not fit any more). It also would look ugly. > > Given that we're retrofitting this, it might be better to put a special symbol after > those menu names which *don't* have menus. Unfortunately, nobody is going to know > what it means at first. How about "!". Then you could have [ @ Files Quit! This That The other thing... ]