 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Applications / Mac Applications / December 2007Location of menu bar
I started with a macplus. Back then, the small screen real-estate made the menu bar alwasy on top of screen very natural and efficient, especially since back then, you only had a single application running at a time (then came multi finder which would then change the menu bar when you switched applications). My machines then upgraded over time, but displays never grew beyond 640-480, so the menu system of the mac remained a good solution. A number of years ago, I switched to mostly using motif on a vms box (x windows) with a much larger display. There, each window has its own menu bar. And when you have a large screen, it makes sense since if you have a small window towards the bottom of the screen, it doesn't make sense for its menu bar to be located on top of the screen when that window is active. Having now returned to the mac under OS-X a few months ago, I now find it odd to find that about the only thing Apple retained from the classic OS design was the location of the menu bar. At a time where screens are much bigger, I find it odd that Apple chose to retain this mantra. When you look at an app such as thunderbird which has many rows of "menus" at the top of the window, it just isn't so natural to have the topmost menu row detached from the widnow and out in a distant location at top of screen. Was there any debate about the menu bar when OS-X first came out ? (or since). Or am I the only one who no longer thinks that the single menu bar philosophy is the best one ? > At a time where screens are much bigger, I find it odd that Apple chose > to retain this mantra. When you look at an app such as thunderbird which > has many rows of "menus" at the top of the window, it just isn't so > natural to have the topmost menu row detached from the widnow and out in > a distant location at top of screen. by having a fixed menubar at the top of the screen, the menubar is 'infinitely tall' and is easy to hit with the mouse. having multiple rows of menus or icons requires precise aim, and it's easy to overshoot. although there's more distance to cover on a 30" monitor than a macplus monitor, there are plenty of command-key equivalents for most tasks and a method to change or add additional ones. i think there's even a third party utility that can pop up a contextual menu with the contents of the main menubar anywhere on screen. > Was there any debate about the menu bar when OS-X first came out ? (or > since). Or am I the only one who no longer thinks that the single menu > bar philosophy is the best one ? there's some valid user interface research behind it. > by having a fixed menubar at the top of the screen, the menubar is > 'infinitely tall' and is easy to hit with the mouse. having multiple > rows of menus or icons requires precise aim, and it's easy to > overshoot. If this is true, then why do so many apps have toolbars? They're usually at the top of the window, but the above logic suggests that they should be at the top of the screen. Toolbars are those "multiple rows of menus or icons" that you suggest are hard to use. There are a few applications that have a freestanding toolbar that hugs the menu bar and appears when the application is active, e.g. all the MS Office apps. The main justification I can see for this style is that the toolbars have so much stuff in them that it would be a pain to steal that much space away from each window.  SignatureBarry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group *** > > by having a fixed menubar at the top of the screen, the menubar is > > 'infinitely tall' and is easy to hit with the mouse. having multiple [quoted text clipped - 5 lines] > should be at the top of the screen. Toolbars are those "multiple rows > of menus or icons" that you suggest are hard to use. It's not a question of being hard to use, but of relative ease of use. The theory behind having the menu bar at the top is Fitt's Law-- <http://en.wikipedia.org/wiki/Fitt%27s_law>-- which as others have noted has been validated by experimental data. SignatureTom "Tom" Harrington Independent Mac OS X developer since 2002 http://www.atomicbird.com/ > It's not a question of being hard to use, but of relative ease of use. > The theory behind having the menu bar at the top is Fitt's Law-- > <http://en.wikipedia.org/wiki/Fitt%27s_law>-- which as others have noted > has been validated by experimental data. I had no problems adapting when moving from MacOS (Classic) to X-windows. But upon returning to the mac, I have found myself stumbling on the menu bar and really noticing it. On small screen MACs, each application basically took the whole screen, so the upper left edge of the application window was right at the upper left edge of the screen, just below the menu bar. So the menu bar was one with the application window. But these days, with larger screens, you will have the menu start at the upper left of the screen even if the application is at the bottom right of the screen. HUGE amount of travel. And while it may be true that it is easy to jump to corners, it isn't so obvious to jup to the top of screen and then travel left/right to reach the desired text to deploy the menu item. > > It's not a question of being hard to use, but of relative ease of use. > > The theory behind having the menu bar at the top is Fitt's Law-- > > <http://en.wikipedia.org/wiki/Fitt%27s_law>-- which as others have noted > > has been validated by experimental data. Hi JF, > I had no problems adapting when moving from MacOS (Classic) to > X-windows. But upon returning to the mac, I have found myself stumbling [quoted text clipped - 12 lines] > obvious to jup to the top of screen and then travel left/right to reach > the desired text to deploy the menu item. It's still fine on my 14" iBook, but if I moved to a 30" screen then I imagine I'd have to reorganize my physical desk to accommodate the mouse movements (which is what I did when I had that lovely 21" Digital monitor running CDE). SignaturePaul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html > > It's not a question of being hard to use, but of relative ease of use. > > The theory behind having the menu bar at the top is Fitt's Law-- [quoted text clipped - 13 lines] > upper left of the screen even if the application is at the bottom right > of the screen. HUGE amount of travel. And yet still proven to be a win. Please try not to fall into the "gut feeling" group when it's already been pointed out to you that there's hard data supporting the choice Apple made. > And while it may be true that it is easy to jump to corners, it isn't so > obvious to jup to the top of screen and then travel left/right to reach > the desired text to deploy the menu item. Motor memory helps a lot here, but you're still having to aim in only one dimension rather than 2 and, since menu titles are almost guaranteed to be wider than they are tall - usually by a large margin - the dimension that you have to aim in is the larger of the two. In another post you asked why Apple has given in to toolbars if window-rooted menus are so bad. The simply answer is popularity. As you noted, toolbar icons are almost guaranteed (I think it's strongly recommended in the HIG) to be redundant. Ditto, by the way, for context menus. The answer is almost certainly that Apple provided standardized mechanisms for them, and used them in their own apps, because people like them and feel more comfortable having them available. But note that having them available does not preclude also having the commands in the screen-rooted menu. Having window hosted menu bars - I'll reiterate, the worst of the 3 menu schemes in use today by a large margin - in addition to the screen-rooted menu would be bizarre. In terms of confusion and wasted time and space it'd be an objective loss for most users. It would likely open them to well-founded ridicule and pressure to drop the screen-rooted menu bar entirely, and at that point they'd be in a no-win situation. > recommended in the HIG) to be redundant. Ditto, by the way, for context > menus. The answer is almost certainly that Apple provided standardized The thing is that menu-bar menus are easy to *trigger* due to their infinite height. Window-based menus and icons are not becuase you have to aim the mouse at them first to trigger them. *context* menus are triggered wherever you already are - it doesn't necessarily apply the same way. In fact, it says that pop-up menus can usually be opened faster because they *avoid* the travel in the first place. > Having window hosted menu bars - I'll reiterate, the worst of the 3 menu > schemes in use today by a large margin - in addition to the Clearly. But I'd like to see pop-ups enhanced. With large screens and becuase of the zero travel, they may often be the best - even according to Fitt's law. SignaturePlain Bread alone for e-mail, thanks. The rest gets trashed. No HTML in E-Mail! -- http://www.expita.com/nomime.html Are you posting responses that are easy for others to follow? http://www.greenend.org.uk/rjk/2000/06/14/quoting > > recommended in the HIG) to be redundant. Ditto, by the way, for context > > menus. The answer is almost certainly that Apple provided standardized [quoted text clipped - 6 lines] > pop-up menus can usually be opened faster because they *avoid* > the travel in the first place. Except they don't. Which is why they're in second place. > > Having window hosted menu bars - I'll reiterate, the worst of the 3 menu > > schemes in use today by a large margin - in addition to the [quoted text clipped - 4 lines] > becuase of the zero travel, they may often be the best - even > according to Fitt's law. There've been some interesting experimental variations on context menus that do a lot to reduce their relative penalties, but nothing I've heard of yet that fully counters them. The problem with context menus is that they aren't zero-travel in any current implementation. To achieve that you'd need a truly stunning predictive algorithm to determine which of several commands you're likely to want to trigger on any given invocation and an underlying context menu mechanism that ensures that item is under the mouse no matter where that puts the full border of the menu display. The second is trivial, but rarely used for some reason. The first is nigh-impossible. > There've been some interesting experimental variations on context menus > that do a lot to reduce their relative penalties, but nothing I've heard [quoted text clipped - 6 lines] > menu display. The second is trivial, but rarely used for some reason. > The first is nigh-impossible. can you point me to some further reading on the various studies? > > There've been some interesting experimental variations on context menus > > that do a lot to reduce their relative penalties, but nothing I've heard [quoted text clipped - 8 lines] > > can you point me to some further reading on the various studies? The seminal research on the top remains that of Walker & Smelcer. Any web search on their names should get you a good start. Really most of what has come in follow-up to their work has been people saying "That can't possibly be true. ... Damn!" You should also find some good experiments, results and discussion from and through Bruce Tognazzini. > > recommended in the HIG) to be redundant. Ditto, by the way, for context > > menus. The answer is almost certainly that Apple provided standardized > > The thing is that menu-bar menus are easy to *trigger* due to > their infinite height. Window-based menus and icons are not > becuase you have to aim the mouse at them first to trigger them. What a terrible scenario! So instead of a errant mouse click simply showing a menu, you now have it going to some background application and triggering some unknown and *definitely* undesired action. Your point actually supports the design of the Mac menu bar. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, ntli.net, teranews.com, vif.com, x-privat.org > > The thing is that menu-bar menus are easy to *trigger* due to > > their infinite height. Window-based menus and icons are not [quoted text clipped - 4 lines] > triggering some unknown and *definitely* undesired action. Your point > actually supports the design of the Mac menu bar. Just the opposite. Just because a menu is easy to *trigger* doesn't mean you have to choose one of the items in it. My point is that pop-up menus are a very good thing, not that the fixed top-of-the-screen menu bar is a bad one. If you want to talk about undesired actions screwing things up, consider when applications steal the focus, especially while, say, entering a password somewhere. An errant activation of a menu is not a problem. Continuing that error by selecting something from that menu - a decidedly more active choice - is another thing altogether. SignaturePlain Bread alone for e-mail, thanks. The rest gets trashed. No HTML in E-Mail! -- http://www.expita.com/nomime.html Are you posting responses that are easy for others to follow? http://www.greenend.org.uk/rjk/2000/06/14/quoting > And yet still proven to be a win. Please try not to fall into the "gut > feeling" group when it's already been pointed out to you that there's > hard data supporting the choice Apple made. Is it "still" proven to be a win ? That study seemed to predate large screens. You seem to place a large value on the difficulty of aiming properly. I now place more value on need to reduce mouse commuting. Having all buttons/gatgets/widgets in the window greatlky reduces not only mouse movement, but also eye movement since with one glance, you can see where all teh functions are. When you have a separate menu bar, your eye first scan the window to see if the needed functions are self contained in the window and if now, then you have to "travel" all over the junk fromn underlying widnows to see where on the menu bar you need to aim. Reverse must be done once you've intiated the right menu option and must then return to your own window. Now, consider an extreme case of a 50" screen where you can tile your windows without any overlap. Will you really like all the mouse travel needed to go to and from the top menu bar when you are working on the rightmost widnow at the very bottom and need to travel all the way to the top and to the left to reach that window's menu ? There is some point between that extreme and the original macintosh where the mouse travel starts to outweight the advantages of having a menu bar at the top all the time. Note that for X applications on OS-X, each window gets its own menubar. Consider that when moving from Classic to OS-X, Apple dropped the two most productive items: the Apple menu on the left and the list of running applications on the right which allow you to get a very quickl list fo apps and quickly change focus from one to the other no matter how deeply the windows were hidden. (CTRL-TAB doesn't work as well as on X-wwindows since you cycle between apps, not between windows, so if Thunderbird has 3 windows opened, you only get to the first one and must then trvel to the menu bar to select the right window from witin Thunderbird. > Consider that when moving from Classic to OS-X, Apple dropped the two > most productive items: the Apple menu on the left and the list of [quoted text clipped - 5 lines] > then trvel to the menu bar to select the right window from witin > Thunderbird. command ` will cycle windows within a single application, so no need to go to the menubar to select the window. also, you can use expose to find any window among all windows, and i vaguely recall that there's a third party utility that can do that with a keystroke, but i'm not 100% sure on that. > > Consider that when moving from Classic to OS-X, Apple dropped the two > > most productive items: the Apple menu on the left and the list of [quoted text clipped - 11 lines] > third party utility that can do that with a keystroke, but i'm not 100% > sure on that. You're probably thinking of Witch. <http://www.manytricks.com/witch/> > command ` will cycle windows within a single application, I have a french keyboard, I'll have to figure out what this is on my keyboard. But it now requires you do cmd-tab to switch between applications and then cmd-` to switch widnows inside each application. OK, I just installed a second graphics card and now my VMS monitor acts as either a VMS monitor or a second screen for my mac. Pretty cool. But it makes the issue of the menu bar even more important. This window (create message) is on one monitor, and the menu bar appears on the other monitor. That is a LOT of travel for both the eyes and the mouse. > > And yet still proven to be a win. Please try not to fall into the "gut > > feeling" group when it's already been pointed out to you that there's > > hard data supporting the choice Apple made. > > Is it "still" proven to be a win ? That study seemed to predate large > screens. Yes. It's valid for large screens and it's valid for screens that are not described by a convex polygon. > You seem to place a large value on the difficulty of aiming properly. I > now place more value on need to reduce mouse commuting. _I_ am not placing a value on anything except results. Extremely consistent empirical data indicate that the effective size of the screen-rooted menu trumps travel distance so far. The literature on this is far too large to cover meaningfully in a usenet post, but it is available. So I'll say again: Please try not to fall into the "gut feeling" group. I can already see you drifting that way because you're starting to attribute the message to the messenger. If you actually care about reality, the information is trivially available. > Having all buttons/gatgets/widgets in the window greatlky reduces not > only mouse movement, but also eye movement since with one glance, you [quoted text clipped - 4 lines] > then you have to "travel" all over the junk fromn underlying widnows to > see where on the menu bar you need to aim. Most of this seems to rely on the notion that the user is not familiar with the application. But that's not a stable scenario; users become familiar with the aspects of the tool they use. The screen rooted menu bar is _always_ where it is: A quick wrist-flick up and to the left; no matter where you are on the screen, that action grounds you for item selection. Window-hosted menus have no such advantage. > Reverse must be done once you've intiated the right menu option and must > then return to your own window. That's covered in the literature. But also note that it's not a uniform case. It's actually a relatively uncommon and suboptimal situation to be using the mouse for a large amount of interleaved data manipulation and command invocation. G > Most of this seems to rely on the notion that the user is not familiar > with the application. But that's not a stable scenario; users become > familiar with the aspects of the tool they use. Yes. Exactly. But this is why I felt the need to relate my experience because someone who has never left the mac wouldn't notice how the menu bar may no longer be the best answer (and they woudl have never really tried a different menu bar philosophy. I went from small screen mac to X-windows and now back to MAC but this time with a big screen (and starting now, twin screens too boot !). It the menu bart was one of big UI changes I noticed as being less user friendly on MAC then on X-window. Of course I will get used to it. But that is just the brain making up for a definciency in the UI. Hence, when you switch from one system to another, your brain has not yet adapted and you can really see the deficiencies. (Like going from classic to OS-X, having to deal with loss of a functional apple menu). > The screen rooted menu > bar is _always_ where it is: A quick wrist-flick up and to the left; My mouse is set to the fastest setting and I can tell you that it isn't anywhere near a "quick flick" up ad to the left to reach it. Just tried: 4 full flicks to the left and 2 full to the top to reachj the File menu from my location on the second screen. (menu is on first screen) And when looking at my window on the right screen, I have no visual focus at all on any menu bar and it takes a while to shift head and visually locate the menu bar on the left. > > Most of this seems to rely on the notion that the user is not familiar > > with the application. But that's not a stable scenario; users become [quoted text clipped - 4 lines] > bar may no longer be the best answer (and they woudl have never really > tried a different menu bar philosophy. I think you would have a difficult time finding someone who has never used anything except a Mac. Please don't make the too-common mistake of thinking that you're the first Mac user to have experience on any other platform recently, or even that it's particularly rare. > I went from small screen mac to X-windows and now back to MAC but this > time with a big screen (and starting now, twin screens too boot !). It > the menu bart was one of big UI changes I noticed as being less user > friendly on MAC then on X-window. User-friendliness is a tough argument because it's not really an objective measure. Mostly it's about what any given user expects, and I would submit that your expectations are coloring your interpretations. What *is* objective, are things like time elapsed and error rates. The screen rooted menu structure empirically offers a superior combination of effectiveness and efficiency than context menus and (especially) window-hosted menus. If you want to argue preference or comfort or any other personal issues, fine. But be honest about what you're talking about. > Of course I will get used to it. But that is just the brain making up > for a definciency in the UI. Maybe. Or maybe it's the brain recovering from having adapted to a deficiency in a prior scenario. > Hence, when you switch from one system to > another, your brain has not yet adapted and you can really see the > deficiencies. Or you can start making the mistake of thinking that something you're not used to is inferior. In which case you're pretty much lost to the "gut" side. G > My mouse is set to the fastest setting and I can tell you that it isn't > anywhere near a "quick flick" up ad to the left to reach it. I went back to read over this entire thread but it's possible I might have missed something. So if I did, I'm sorry. I'd like to add a few comments. First, I think you can fine tune the adjustment on your mouse tracking in the Universal access preference. IIRC, it defaults at the middle setting on the slider there. And then you can adjust it further in the regular mouse prefs. Leastways I think you can, if you are using Leopard. I don't know about Tiger since I skipped it. Have you tried DejaMenu? It was designed specifically for people who use huge displays and it works in both Tiger and Leopard. You can access most of the menu bar commands via contextual menus instead of having to travel so far with a mouse. It's a great app and free to boot. As a longtime Mac user, I tend to use the keyboard much more than a mouse for most things. But it does take time to gradually expand your use of the keyboard commands so I do understand the inconvenience of mousing. But that'll improve a lot faster than you think. And one reason for that is because, from the beginning, the Mac menu bar command set has served as a common frame of command reference for all Mac apps. So, no matter what application you're using, certain commands will always elicit the same behaviors. That makes it easier for the user. Those tend to be the commands in the top menu bar. However, many apps are duplicating some or all of those commands in their tool bars and contextual menus, especially apps which can use a lot of screen real estate. Another app that could ease your large screen burden, that I've used for over ten years, is Keyboard Maestro. Not only does it have a much better way of switching between applications and windows IMHO, it also incorporates macros (both built-in and user-designed), and a clipboard switcher. Originally developed by Michael Kamprath, it's well maintained & updated now by Peter Lewis. > Now, consider an extreme case of a 50" screen where you can tile your > windows without any overlap. Will you really like all the mouse travel > needed to go to and from the top menu bar when you are working on the > rightmost widnow at the very bottom and need to travel all the way to > the top and to the left to reach that window's menu ? I wouldn't like such a 50" screen at all, because it would be unusable regardless of menu placement. If the GUI uses all those pixels the same way as with smaller screens you'd have to place the screen at the same distance from your eyes as smaller screens, meaning that you'd actually have to move your head and strain your neck when looking from the bottom-right to the top-left window. > There is some point between that extreme and the original macintosh > where the mouse travel starts to outweight the advantages of having a > menu bar at the top all the time. No, there is a point where screen sizes and resolutions require resolution-independent GUIs instead of just cramming more content onto the screen. A 50" high-resolution screen would be used to render the contents with more detail and better quality instead of using the same tiny and crappy fonts and UI-elements as with the original Mac screens. Believe me, nobody *wants* wall-filling screens with 20 non-overlapping windows on them if you have to stand up and squint at the top-most window if you want to read its contents. Jochem Signature"A designer knows he has arrived at perfection not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery > And while it may be true that it is easy to jump to corners, it isn't so > obvious to jup to the top of screen and then travel left/right to reach > the desired text to deploy the menu item. If you have a hard time just moving from left to right, window menus won't help you in any way and only add to the difficulty by forcing you to hit a smaller vertical target as well. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, ntli.net, teranews.com, vif.com, x-privat.org > > > by having a fixed menubar at the top of the screen, the menubar is > > > 'infinitely tall' and is easy to hit with the mouse. having multiple [quoted text clipped - 10 lines] > <http://en.wikipedia.org/wiki/Fitt%27s_law>-- which as others have noted > has been validated by experimental data. Which doesn't really answer my question: why are in-window toolbars so popular if the data indicates that top-of-screen menus are easier? Everything in the toolbar usually duplicates something from a menu, so the toolbar is both redundant and harder to use. If even Apple has given in to toolbars, Is it because toolbar icons are usually bigger than menus, so the size makes up for the fact that it requires more accuracy in mouse movement? SignatureBarry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group *** > Which doesn't really answer my question: why are in-window toolbars so > popular if the data indicates that top-of-screen menus are easier? It is a mistake to think that something is popular just because it is widely used. Windows is widely used, for example, but not widely liked. > Is it because toolbar icons are usually bigger than menus, so the size > makes up for the fact that it requires more accuracy in mouse movement? Keep in mind that the toolbar represents a full action, whereas the menu bar only represents a *first* target. The actual item might be buried several submenus deep, making the toolbar a faster choice. Even faster might be a command key, assuming the menu item has one. SignatureMy personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com, heapnode.com, localhost, ntli.net, teranews.com, vif.com, x-privat.org In article <droleary.usenet-7FA2B0.08271114122007@sn-ip.vsrv-sjc.supernews.net>, > > Which doesn't really answer my question: why are in-window toolbars so > > popular if the data indicates that top-of-screen menus are easier? > > It is a mistake to think that something is popular just because it is > widely used. Windows is widely used, for example, but not widely liked. Popular can mean either "a widely held opinion" or "a widely liked thing". I meant it in the former sense. Or perhaps in the latter sense, but with respect to application designers, i.e. they seem to like to use toolbars. > > Is it because toolbar icons are usually bigger than menus, so the size > > makes up for the fact that it requires more accuracy in mouse movement? [quoted text clipped - 3 lines] > several submenus deep, making the toolbar a faster choice. Even faster > might be a command key, assuming the menu item has one. Good point. Also, GUI designers in general like *icons* rather than text, but icons tend not to fit well into menus. SignatureBarry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group *** > Good point. Also, GUI designers in general like *icons* rather than > text, but icons tend not to fit well into menus. *Good* GUI designers prefer a combination of icons and text, which usability studies invariably prove to be more effective than icons alone. > *Good* GUI designers prefer a combination of icons and text, which > usability studies invariably prove to be more effective than icons alone. I'd say good GUI designers give the used the option of having both or either text or icons. For instance, for the "DOCK", I find that having icons only not only takes up more space, but is also far less obvious initially. (sure you get used to it and eventually know that firefox, no matter what its icon might be is the 3rd item on the doc). The itunes and X11 icons are perhaps the only ones that are really obvious. A good UI is one which makes it easy for a new user to get comfortable. Every user will eventually get comfortable with any UI, even a character cell unix command line. The question is whether there are some "unnatural" things in the UI which makes it harder to get comfortable with and which slow a process down. (for instance, looking at unfamiliar icons on the DOCK and wondering what they do and which one is the browser). > > by having a fixed menubar at the top of the screen, the menubar is > > 'infinitely tall' and is easy to hit with the mouse. having multiple [quoted text clipped - 5 lines] > should be at the top of the screen. Toolbars are those "multiple rows > of menus or icons" that you suggest are hard to use. Numbers and Pages (Apple apps) being prime examples. > There are a few applications that have a freestanding toolbar that hugs > the menu bar and appears when the application is active, e.g. all the MS > Office apps. The main justification I can see for this style is that > the toolbars have so much stuff in them that it would be a pain to steal > that much space away from each window. Office 97 was where I first came across that feature and it did save valuable screen estate. The drawback with leaving it running permanently was that it used valuable RAM, when that was still expensive. SignaturePaul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html > If this is true, then why do so many apps have toolbars? They're > usually at the top of the window, but the above logic suggests that they > should be at the top of the screen. Toolbars are those "multiple rows > of menus or icons" that you suggest are hard to use. A humourous take on that... <http://www.digibarn.com/collections/screenshots/Screenshots%20Funstuff/M SOffice.jpg> SignaturePaul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html > I started with a macplus. Back then, the small screen real-estate made > the menu bar alwasy on top of screen very natural and efficient, Even today, it's efficient. Hard to believe, but empirically proven. > A number of years ago, I switched to mostly using motif on a vms box (x > windows) with a much larger display. There, each window has its own menu > bar. And when you have a large screen, it makes sense since if you have > a small window towards the bottom of the screen, it doesn't make sense > for its menu bar to be located on top of the screen when that window is > active. Yes it does. Target acquisition time improves drastically as target size increases. The benefit to window-hosted menus being closer is (still) completely lost in having to aim more carefully. Exhaustive context menus suck less - a lot less - than window-hosted menus but still suck more than the screen-top menu bar. Which, granted, also sucks. It just sucks least of the 3. > Was there any debate about the menu bar when OS-X first came out ? (or > since). Or am I the only one who no longer thinks that the single menu > bar philosophy is the best one ? There's been a lot of discussion, dating back to well before OS X shipped. There hasn't been a lot of what you could fairly call debate because there's honestly not much opportunity for it. There's data, objectively produced and then verified repeatedly by groups that for the most part are initially hostile to the premise they end up validating. Then, on the other hand, there are people who assert that their instinctual belief *must* be true. So, no. No debate as such. >the menu bar alwasy on top of screen very natural and efficient Menu bar always at the top works best for me because it's easy to get to, with limited accuracy required. Anywhere else would slow me down, even though I use shortcut keys a lot. However, I take your point about hi-res displays. I used someone's XP machine the other day with a rediculously hi resolution. I could hardly read anything and mouse movements were so hard work. I quickly found myself using contextual menus and shortcut keys. Also, on some machines the mouse doesn't accelerate enough to cover large distances. G. > Was there any debate about the menu bar when OS-X first came out ? (or > since). Or am I the only one who no longer thinks that the single menu > bar philosophy is the best one ? I actually agree. I earn my living as a software usability guy, so I know all about the reason for the menu bar being where it is. But like you, I would contest that as screens become bigger and bigger, and multi-screen setups become more common, the advantage is certainly much less than it was on the original Macs. I wonder if the 'ghosting' of the menu bar in Leopard is a sign of things to come: Apple beginning to de-emphasise the menu bar as a primary means of interaction. Maybe they have something new up their sleeves for 10.6.... > I wonder if the 'ghosting' of the menu bar in Leopard is a sign of > things to come: Apple beginning to de-emphasise the menu bar as a > primary means of interaction. Maybe they have something new up their > sleeves for 10.6.... There was a utility under old Mac OS (don't know if it made it as far as OS9, but I certainly tried it out well before then) which let you, with a command key, click the mouse and have a pop-up menu appear wherever you were which contained all the menus from the menu bar. It was kind of like how menus were handled optionally under NextStep where you could put the menus anywhere. Maybe we have too many modifier keys and of course there is always the impending religious war about the number of mouse buttons, but as screens get larger, and as multiple screens proliferate, maybe it's time to revisit some variation of that. (as it is, I use a multi-button mouse when possible and the control-click on my notebook all the time to access the contextual menu which I find astoundingly convenient. Just adding a single hierarchical element at the top of the contextual menu which corresponds to the general purpose menubar would solve much of this) SignaturePlain Bread alone for e-mail, thanks. The rest gets trashed. No HTML in E-Mail! -- http://www.expita.com/nomime.html Are you posting responses that are easy for others to follow? http://www.greenend.org.uk/rjk/2000/06/14/quoting > There was a utility under old Mac OS (don't know if it made > it as far as OS9, but I certainly tried it out well before > then) which let you, with a command key, click the mouse and > have a pop-up menu appear wherever you were which contained > all the menus from the menu bar. DejaMenu for OS X does something similar: http://www.versiontracker.com/dyn/moreinfo/macosx/21184 > > Was there any debate about the menu bar when OS-X first came out ? (or > > since). Or am I the only one who no longer thinks that the single menu [quoted text clipped - 5 lines] > multi-screen setups become more common, the advantage is certainly much > less than it was on the original Macs. On the contrary, the bigger the screen is, the more important it is that the menu bar is someplace easy to get to. SignatureJerry Kindall, Seattle, WA <http://www.jerrykindall.com/> Send only plain text messages under 32K to the Reply-To address. This mailbox is filtered aggressively to thwart spam and viruses. > On the contrary, the bigger the screen is, the more important it is > that the menu bar is someplace easy to get to. In that case, there should be a 4th button on the mouse. You click on it, your current cursor position is rememebered, and the mouse cursor then moved to the apple menu so you then have easy access to the menu bar, no matter how far it is from your window. Then, when you release the 4th button, the mouse cursor returns to where it was in some far away window. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.