mmt@dciem.UUCP (Martin Taylor) (10/08/85)
The following was a response to a proposal that menu-bar items on the Macintosh should be allowed to cause "real" actions rather than just calling up window-blind menus. >I don't like your proposal, primarily because it is confusing to use the >menubar for multiple things in this way. By the way, Switcher does >something like your proposal, with its double-arrow icon at the >righthand end of the menubar; while it doesn't really confuse me, I can >imagine that it would confuse less experienced computer users ("the rest >of them"), especially since one has to be very precise and point at the >correct little arrow head. > >There are several command styles that I have seen which provide the >functionality you are describing. First of all, you can have ordinary >"Next/Forward/Previous/Backward <unit>" menu items, but have command key >equivalents; this is probably the most standard way to do this, and it >provides the simplicity that novices need and the shortcut that >experienced users want. Another possibility is to use Forward/Backward >buttons somewhere in the window. Finally, a method I have seen in some >software (although I don't fully approve of it) is to make use of the >horizontal scroll bar when real horizontal scrolling doesn't apply in >the current context; the standard Scrapbook DA does this, although I >would much prefer real scrolling, or at least the ability to resize its >window (I seem to be digressing). >-- > Barry Margolin Why should it be confusing for a menu-bar item to cause an action other than presenting a new menu? The menu-bar provides a menu. Clicking on a menu item does something. Sometimes that something is to call down another menu, sometimes it is not. Sometimes items in the window-blind menu call up a third-level menu, sometimes not. Personally, I'd much rather have a menu item "Quit" on the menu-bar than to have it as the only entry under "File", as it is in several applications distributed over the net. (Why "File", anyway? What's that got to do with quitting?). The suggestion about loading other controls, such as scroll bars, sounds much worse, since those items do have specific functions in the usual case. Forcing the use of command keys is bad: in my view, command keys should apply ONLY to visible menu items, and a new set of command keys should be available when a sub-menu is alive. For example, ^F (clover-F) might call the "File" menu, and ^S could be "Save" under that menu, so that ^F^S always meant "Save". That way, there would be compatibility between what is done at the keyboard, as well as the possibility for giving every menu item a commend-key equivalent, be it two, three, or more keystrokes. The only cost of that would be that only those functions on the menu-bar could be performed with one keystroke. I don't consider that a problem. -- Martin Taylor {allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt {uw-beaver,qucis,watmath}!utcsri!dciem!mmt
stew@harvard.ARPA (Stew Rubenstein) (10/10/85)
In article <1701@dciem.UUCP> mmt@dciem.UUCP (Martin Taylor) writes: > >The following was a response to a proposal that menu-bar items on the >Macintosh should be allowed to cause "real" actions rather than just >calling up window-blind menus. > >>I don't like your proposal, primarily because it is confusing to use the >>menubar for multiple things in this way. > >> Barry Margolin > >Why should it be confusing for a menu-bar item to cause an action other >than presenting a new menu? The menu-bar provides a menu. Clicking on >a menu item does something. Sometimes that something is to call down >another menu, sometimes it is not. Sometimes items in the window-blind >menu call up a third-level menu, sometimes not. Personally, I'd much rather >have a menu item "Quit" on the menu-bar than to have it as the only entry >under "File", as it is in several applications distributed over the net. >(Why "File", anyway? What's that got to do with quitting?). Why? Because practically all other menu bar items in every application written for the Macintosh cause this action. Menu items which cause a third level menu (dialog box) should end with an ellipsis (three dots). Quit is on the file menu because there is no better place for it. ALL OF THIS IS IN THE "USER INTERFACE GUIDELINES" SECTION OF INSIDE MACINTOSH. ***** READ IT! ***** Sorry to shout, but consistency is an important feature of the Macintosh. Please take the time to read this important section -- it will make your applications much easier to use. It also states (top of p. 35 in the phonebook edition) "Nothing actually happens until the user chooses the command; the user can look at any of the menus without making a commitment to do anything." In my opinion, this is gospel. The switcher \had/ to be an exception because it has to intercept the mouse-down at the event stage, without relying on the application to call MenuSelect or anything like that. >The suggestion about loading other controls, such as scroll bars, sounds >much worse, since those items do have specific functions in the usual case. The use of scroll bars on the left and lower edges of a document window conventionally scrolls the document in the window. A scroll bar in a non-document window or in a different place in a document window has no conventional meaning. I think that scroll bars may be reasonably used in these positions for other purposes. Moving "Forward" or "Backward" (whatever that means for your application) may well be a left-and/or-lower edge situation. Scroll bars are often used for value selection where non-graphical systems might well ask the user to type in a number. This is \not/ a left-and/or-lower edge situation. >Forcing the use of command keys is bad: in my view, command keys should >apply ONLY to visible menu items, and a new set of command keys should >be available when a sub-menu is alive. For example, ^F (clover-F) might >call the "File" menu, and ^S could be "Save" under that menu, so that >^F^S always meant "Save". That way, there would be compatibility between >what is done at the keyboard, as well as the possibility for giving every >menu item a commend-key equivalent, be it two, three, or more keystrokes. >The only cost of that would be that only those functions on the menu-bar >could be performed with one keystroke. I don't consider that a problem. > >Martin Taylor >{allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt >{uw-beaver,qucis,watmath}!utcsri!dciem!mmt This last may be a good idea. Unfortunately, it is too late for incorporation into the Macintosh user interface. The most common things ought to single keystrokes, though, and I can remember more than 5 or 10 at a time, myself. A less experienced user might well be different. I was going to suggest using icons (such as in MacPaint, or MacDraw, or my application, ChemDraw), but this may not be so good. Selecting an icon from a pallette is a great way to handle "tools" but the action of selecting an icon usually doesn't do anything. Inside Mac doesn't say anything about them, but these applications all work that way. I remember an implementation of a dataflow processor simulation (by Gus Fernandez at Stanford maybe?) which used a vertical "icon bar" with pop-out icon menus. I think that this may have worked differently, i.e., something happens when you click in some cases, though some icons were mode selections. The current mode was, as I remember, displayed as the "title" of the icon "menu". I liked this when I saw it, but that was a year or so ago, before I had any experience as a Mac developer. What about other applications which use icons? A survey, anyone? Stew Rubenstein Rubenstein@lhasa.harvard.edu (maybe) Rubenstein@harvard.arpa (more likely given current confusion) { seismo, ut-sally, decvax!genrad!wjh12 } ! harvard ! rubenstein (uucp)