davidl@leonardo.intel.com (David D. Levine) (01/09/90)
>> ...instead of putting the menu IN the window, replace the Title Bar >> with a MenuBar, Perhaps in a format such as: >> AppName File Edit Menu Menu Menu ZoomBox I've used several programs that use menus in the window or title bar, such as MacSink/Vantage and FullWrite ("Find" dialog box) on the Mac and FrameMaker on UNIX systems. The problem with this strategy for me is that the menubar is too hard to hit. The Mac's menubar is at the very top of the screen for a good reason: you cannot possibly overshoot. You just WHANG the mouse up to the top of the screen and hold the button down (you can do this without even looking!), then wave it right and left until you see the menu you want. This makes selecting a menu easy for even the most uncoordinated. It is easy to select an item from the menu, too: you just wave the mouse up and down until the big black bar highlights the item you want. The whole system seems to me to be VERY carefully thought out: it never requires a precision better than about a quarter of a screen inch vertically and three-quarters of a screen inch horizontally, and there's big, bold visual feedback at all times. Menus in the window require much more precise positioning. You must move the pointer to the menu and not beyond. This means either overshooting and moving back, or slowing down before you reach the menu: either way, it's not as fast as whamming the pointer into the top of the screen at full speed.* The visual feeback is not as good, either: instead of a big menu that appears or a big black bar that moves, you must decide whether or not the little pointer is in the menu area you want before pressing the button. There is more higher-level brain function involved, so it feels like more work. The differences are tiny, but they have a big effect on the perception of the system. Of course, precise positioning IS required for many operations, especially in graphics programs. But the basic, lowest-level command mechanism (menus in the Mac's case) MUST be dead-simple to access. If the simple commands take a fraction of a second too long to execute, the system will be perceived as "slow" or "cumbersome." Some people say that the top-of-the-screen menubar is a problem with large displays. For me, at least, it's no problem. The way I have my mouse set, even with a full-page display I can still get to the top of the screen in one swipe. I'd much rather have the menus in one consistent, easy-to-reach place than have them scattered all over the screen. The other menu paradigm that works for me is having the menu pop up at the current mouse position. That's why I use DA Menuz (hierDA). However, I still use the menu at the top of the screen 90% of the time, because it's always there and always visible. - David D. Levine, Intel IMSO Tech Pubs davidl@leonardo.intel.com "Being disintegrated makes me very angry." (* This is also the way I stop when rollerskating. :-) )
ken@i-core.UUCP (Ken MacLeod) (01/15/90)
In article <588@sunfs3.camex.uucp>, kent@sunfs3.camex.uucp (Kent Borg) writes: >In article <2964@pur-phy> cca@pur-phy (Charles C. Allen) writes: >>[describes menu in a window, possibly/probably wrapped for size] >But we would loose an important feature of the current menus. People >can scan through the current menu bar by dragging left and right, and >select from within a menu be dragging down and up. If you wrap the >menu bar, you can't do this. It might sound trivial, but a lot of >what makes the Mac so great sounds trival. Drag down-left doesn't open/leave open the menu, same as drag-down doesn't leave hierchical menus open. Drag-down or down-right puts you "in" the menu and leaves it open. What makes the Mac so great is all the attention paid to all the things that seem trivial. 10,000 pennies is a $100, any one penny is insignificant, but they add up. >I agree that the menu bar can get pretty far away (I wish I had more >experiance with the problem--anyone want to send me a free big screen >so I can be more authoratative?), and I agree that presto-chango >nature of the current menu bar under MultiFinder is confusing. I'll take pop-ups and a second mouse-button myself. An INIT to put menus in a window shouldn't be too difficult. A little work on the window manager and default WDEFs to make "inMenuBar" come from the WDEF instead of the window manager, the app will still call the Menu Manager. A little kludge to re-find the window (since only the cursor is passed to the Menu Manager, not a Window handle) and maybe the addition of a Menu handle to a window object (so that menus are window-tied and not application-tied.) [What about custom WDEFs? Long Term: definition of how to interface to the Menu Manager from a WDEF. Short Term: a kludge to add the menu above the drag bar (ick) or a separate modeless vertical menu window (maybe we should skip the whole menu-in-window bit :-) ] As I mentioned, I'll take pop-ups. But I think the original decision for a menu-bar, on the assumption that only one program was running, was to make it always there and easy to get to. Now that multiple apps are running, I think putting it in the window is best to acheive the same ease-of-use and "always there" feeling. On the always there feeling, and keeping the one button mouse, and having pop-ups, and not using screen real-estate, I haven't heard any mention of a "Menu Region" in the title bar. This would be fairly large control, about two to three times the width of a scroll bar and almost the height of the title, that produces a vertical (or pie for you power users :-) pop-up. Command-click or second button would be a short-cut and produce the menu "here" instead of "there". (Note that command-click is style-guided for disjoint text selection (does anyone use that?) and is surely used elsewhere.) Currently defined pop-ups are style-guided mainly for item selection, and in doing define that the menu comes up with the current item under the cursor. Pop-up generic menus would most likely appear with the cursor to the left of the second to fourth item (contrast this with the style-guide, on pull downs, the second is the easiest to hit). Very nicely, this would put the "Edit" just above the cursor and the first and second items of the App's menus to the right and just below the cursor. >Another problem: What if an application has more than one window open? >Do they all have the same menu? That's not a problem, that's a solution! Document windows are almost by definition different contexts, the set of checked, enabled/disabled, and show/hide items are different. > Do different types of windows have >different menus (making them look like different apps)? Is there a >master window which has the single menu bar? 1. Yes, 2. No. Documents are documents. Layering, I understand, is a hack for applications that have tool or object attributes windows that are associated with the document window. I assume it was a choice of layered apps or losing the tool windows in the shuffle. There should be a way to make documents "layer aware". So for (2) you could have one modeless menu, tool, or object window always pulled to the front _with_ a document that uses it. But the other documents would not be pulled. Documents are different conceptual objects. I guess what I'm saying is that a document is tied to a menu or toolchest, but documents aren't tied together by an "application". >Another problem: If the menu bar is no longer at the edge of the >screen, the user can no longer use the top of the screen as a >backstop. It becomes possible to overshoot. Sure, that is true all >over the rest of the screen, but it should still be understood before >things are changed. Valid point. But it can be compared to the tiny close box or the drag region, as you mention. Once the menu is clicked it would have a slopRect like that of scroll-bars. A precise click to start it, but all the looseness in mouse waving you need to look at the menus afterwards. -- Ken [PS. I'm in need of a job. I'm looking for work in advanced technology, system software, language, and interface design. If the above kind of design thinking, tied with the ability to implement it, interests you, contact me at +1 801 255 3607, +1 801 269 0569, or ken@i-core.uucp. Have Mac, will travel.] -- Ken MacLeod, Barkeep Bitsko's Bar & Grill BBS, +1 801 269-0670 ken@i-core.uucp