Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!stew From: stew@harvard.ARPA (Stew Rubenstein) Newsgroups: net.micro.mac,net.cog-eng Subject: Re: menubar items without menus? (suggested enhancement...) Message-ID: <410@harvard.ARPA> Date: Thu, 10-Oct-85 00:51:05 EDT Article-I.D.: harvard.410 Posted: Thu Oct 10 00:51:05 1985 Date-Received: Sat, 12-Oct-85 18:20:31 EDT References: <3281@nsc.UUCP> <5387@mit-eddie.UUCP> <1701@dciem.UUCP> Reply-To: stew@harvard.UUCP (Stew Rubenstein) Distribution: net Organization: Aiken Computation Laboratory, Harvard Lines: 90 Xref: watmath net.micro.mac:2904 net.cog-eng:548 Summary: 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)