I’ve always found Global menu bars (ala Mac) to be bad usability-wise. They have numerous problems. I’ve always found that having a single menu bar at the top of the screen as Macs are both confusing and inefficient. Menu bars like that are leftovers from when Mac OS was primarily a single process operating system, and it should have been ditched long ago.1) They place unwarranted emphasis on menu bars. Menu bars are a UI element that should not be used frequently. In dealing with basically any application, most of my time is spent manipulating the content, followed by using the tool bars, then lastly menubars. In my word processor most of my time is spent typing, followed by quick formating and saving from the toolbar. In my web browser I frequently interact with the webpage, use forward and back buttons, but how often do I need to use stuff from the menu bars? Its only on the odd occasion that I need to open a website from my harddrive or get help.
Toolbars should hold the most common tasks for quick access, while menus are good because they can hold a lot of commands to all the less used operations. Menus are slow and error prone. It usually takes quite a while to find what you are looking for, and, as with any nested structure, slight movements can put you in the wrong place especially with things as narrow as menus. Menus are an important part of UIs because they allow you to do uncommon tasks, but why make uncommon tasks available at the easiest to reach spot on the screen?
2) A global menu bar is disconnected from the task at hand. It appears to be global, but functions local to what you are working on. If the focus is on the wrong window, for various reasons, it can lead to very confusing and potentially destructive behavior. This is just confusing, toolbars are attached to the application, isn’t it inconsistent to not do the same with menu bars? There is no quick way to tell without thinking which application the menu is functioning for. If menus were connected directly to the task, this problem would not exist. Global menu bars were fine when most people were running one application, but in todays multitasking world it is a poor choice. Global menu bars appear to be a part of the OS by appearing globally, but confusingly function local to the application.
3) Global menu bars don’t work with focus follows mouse.
4) Global menus don’t work well with multiple monitors. For a given application, you have two choices. First of all, you could put the menu always on the first monitor (like OSX). This means if you are using an application on the second monitor, you have to move your mouse to the first screen to use the menu. Confusing and inefficient. The second choice is to put a separate menu on each screen. This ends up being more efficient but just as confusing.
5) This really only applies to GNU/Linux and Unix desktops, but having a global menu bar would be inconsistent. With Macs, Apple has control over the GUI. On GNU/Linux, there are dozens of toolkits floating around, and if one desktop environment switched to having menus at the top of the screen, there is no way that every toolkit would do the same. You would end up with a desktop with some applications having menus at the top of the screen, and others with them on the application.
6) Widgets must be dynamically changed. You essentially have a moving target.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
i’ve been a long time linux-user and i’ve got myself a powerbook half a year ago of course i also tried OS-X (beside the obligatory linux
) and i found this one menubar quite a good idea, it’s less waste of desktop-space.. it also makes all apps use quite the same HIG.. but if you don’t like ’em i’m not gonna do anything about it, as long as you keep me liking ’em 
One opinion and I can resepect it since you were kind enough to spell it out in a reasonable matter.
But, I disagree. I didn’t start using a Mac until recently, and I actually much prefer the “application menu bar” since it frees up the rest of the application windows to be placed where I want, extra space on the screen isn’t being taken up by toolbars and I still have access to the most important functions of the system.
Personally, the more I’ve used the Mac recently the more I’ve liked it. I’ve been using PCs since 1990s, and my first computer was an Apple //C+ so I think I have some experience qualification
I think it’s more a matter of what you’re used to. To me the Mac menu bar is more intuitive, it’s omnipresent and contains the menus for the current application, and is always in the same place. You speak of moving targets, run multiple apps in Windows or Linux and each app’s menu can be in a different location.
In other words, don’t knock something based strictly on a lack of familiarity.
One major problem with windowed menubars is small or narrow windows such as instant message programs. These programs commonly have alot of different options and functions they can do, but never have enough menu space.
I agree with the above posts, but I also find that all the menu items are always visable regarless of window size.
beat me to it 😉
I really have to disagree with the editorial:
“Menu bars are a UI element that should not be used frequently. In dealing with basically any application, most of my time is spent manipulating the content, followed by using the tool bars, then lastly menubars.”
This is precisely why global menu bars are far more preferrable. I would rather have one unused menu bar out of the way at the top of the screen, than a menu bar on top of each of my ten windows. 1 unused element is way better than one unused element for each window on the screen! That is one of the reasons I typically have 3x as many windows open on my Mac than on my PC. So to me, it’s the per-window menu bar that is a holdover from the non-multitasking days.
I haven’t used mac’s much, but I’ve tinkered with this emac we have at work that sits in the corner collecting dust. For me it feels like more work bringing focus to a window and then trying to select it’s menu items at the top of the screen. I guess they provide key bindings that could speed this up a bit, but moving the mouse cursor all over a 1280×1024 desktop feels like a big waste when I use the system. Just my opinion on the subject.
1) They place unwarranted emphasis on menu bars
I agree with this. However, I fail to see how having a global menu bar prevents you from having more emphasis on toolbars. In Word on OS X, I find myself making far more use of the floating palettes that I do the menu bar. I agree with your point that toolbars should hold commonly used items. But I fail to see how having a global menu bar affects that.
2) A global menu bar is disconnected from the task at hand….There is no quick way to tell without thinking which application the menu is functioning for.
This takes a little getting used to. However, it is easy to see which app has the global menu bar. The name is written in bold on the top left of the menu bar, making it easy to know which app currently has focus.
Can’t comment on point 3 :-).
4) Global menus don’t work well with multiple monitors.
This has more to do with the implementation of global menu bars on OS X than with that concept in general. There is nothing preventing you from having the menu bar on the second monitor, and this is a _major_ gripe I have with OS X at the moment. Complain to Apple. If enough people complain, perhaps they’ll do something. Fortunately for me, I don’t use a secondary monitor often.
5) This really only applies to GNU/Linux and Unix desktops, but having a global menu bar would be inconsistent.
Applies to Macs too. There are Java and X11 apps that don’t follow this paradigm, and it affects the consistency of the desktop. Nothing that can really be done, aside from not using those apps.
6) Widgets must be dynamically changed. You essentially have a moving target.
This doesn’t make sense and needs a more in depth explanation. What do you mean by widgets need to be dynamically changed? I fail to see how having a global menu bar will affect widgets.
“I guess they provide key bindings that could speed this up a bit, but moving the mouse cursor all over a 1280×1024 desktop feels like a big waste when I use the system. Just my opinion on the subject.”
I respect your opinion, but the argument is nonsense. Look at this screenie:
http://img100.echo.cx/img100/5352/screenshot8yt.png
How far away is the top Gnome bar from the menubar of FireFox?
Other than that; OSX relies heavily on keyboard shortcuts. I can’t even remember the last time I actually used the menubar on any of my apps in OSX.
The strength of the global menu bar is that they present an infinitely high target for a user’s mouse movement. However, I must firmly disagree with some of your points. I remember reading the human interface design (HID) studies Apple did in 1984. (I loved my Mac 128K!) If you read these HID reports, you’d understand that in actual practice, most users–not the geeks but most normal users–use a single application at a time maximimzed. Further, the single menu bar at the top creates an infinitely high target, since you cannot scroll past it. It was not about single or multiprocessing apps. With Switcher at the time, you still could run multiple apps.
On other menuing approaches, you must use much finer motor control to hit the menu. This represents a slow down in performance and a higher level of difficulty for the average user.
That’s not to say that for power users, the global bar is a good idea. Frankly, I switch between both with ease. But separating the windowing functions from the app should give a user the ability to designate when and where they want the menu for their particular style.
I agree with some of his points, but I don’t think a perfect menubar for every possible circumstance exists. All the menubars in every OS I’ve used have their problems, even the well designed variants found in NeXTSTEP and RISC OS.
IMO most of the time the benefits of a global menubar compensate for it’s flaws. It allows for significantly faster access than a detached menubar, menus on the the global menubar are a much larger target (see Fitt’s law). When combined with contextual menus and toolbars it seems at least as good as any other solution.
Even though I don’t often use Mac OS I don’t find it’s menubar to be annoying or unintuitive. If it was possible to have a single menubar in Windows I’d probably switch to it.
I’ll have to disagree with the article. Mainly for what the previous posters said, takes up less space, etc. Also, if you are taking to long to find something in your menu bar, talk to the application developer, on the mac, there are guidlines and I always know where everything is, on first launch.
The other thing is that this paradigm really only works on a mac. In Os X, there isn’t a seperate instance of each app like it is on Windows or Linux. Every time you launch an application in those OS’s they launch a WHOLE nother app. This doesn’t work with a global menubar at all. You can do this with kde and instantly see it doesn’t provide the same usablity as Os X. This complents thier other paradigm of one process per app. And in my opinion works a ton better than having 5 mPlayer controllers on my screen because i opened 5 videos from the file manager.
Sure, its odd at first, when i first moved to Os X, i knew i had to adjust, but after about a month, i saw the strengths of these two different ways.
Have you ever heard of Fitt’s Law? To summarize: the futher a target is, the longer it takes for a user to acquire it, and the smaller a target is, the longer it takes the user to acquire it. While having a “global” menu may mean that it is a bit further away, it also forms a much larger target (because you can over-shoot and go off the screen). In other words, the Macintosh menus are more accurate.
I think the problem that most people have with accuracy relates to nested menus. While I haven’t read Apple’s latest user interface guidelines, the old ones definitely said that nested menus were a faux pas.
Two of your points were directly tied to Unix environments (the widgets and the sloppy focus).
As for the context of the menu changing based upon the system’s state: well you cannot even avoid that with window per-window menus: if the window is maximised the menu remains in the same position regardless of the application.
Worse yet, if the window is not maximised, the location of the menu is not predictable.
The application that comes to mind is the terminal emulator shipped with OSX. It’s a small window and I frequently have lots of shells open. I have to move the mouse to the top of the screen just to open more shells since simply trying to launch the terminal emulator from the icon on the desktop more than once doesn’t work. I usually keep the terminals near the bottom of the screen. This wouldn’t be a problem provided I was familiar with the keybindings, but as new mac os user I find it to be a pain. But as I said earlier, that’s just my opinion on it.
Try, when a terminal instance is focused, to press apple+n.
There, new terminal instance. There is no need at all to use the menubar
.
To kill one instance, press apple+w. To kill the entire app, press apple+q.
“The application that comes to mind is the terminal emulator”
Umm.. command-n. And you’re in a terminal, so i KNOW your hands are on the keyboard. And don’t say “i’m not familiar with the keybindings”, not only is this an OBVIOUS key command to get a new shell, its also written in the menu bar item NEW that you keep clicking.
I dare anyone to find me a Mac user that uses the menubar to open a new document, it just isn’t done. Command-n is your friend. Apple chose the command button instead of the control button for a reason, its actually USEABLE, you dont have to shift your whole hand and use your pinky like you do with control. Mac users keep their thumb resting on the command key, and get tons more done way faster. Just ask one.
the solution for the multiple monitors is to have multiple menus. apple has to implement something like that.
screen A has application X
screen B has application Y
then
menu on A should hold menu for X
menu on B should hold menu for Y
I like that the Mac toolbar wastes less space than one toolbar in every window. For the same reason I almost always (except in my browser) turn the stupid toolbar off. Mostly a keystroke is the most efficient and easy to memorize, since they’re consistent on the Mac.
OTOH some people are right that only rarely used stuff needs to be in the menu. I really like the NeXTStep/GNUstep menus, since you can detach part of it and keep it around like a toolpane on the Mac. Bummer that Apple didn’t keep this feature!
The only big disadvantage is point 3: focus follows mouse is so incredibly cool (I’m used to the Mac click-ten-times-for-everything now, but still kindof miss it) and efficient if you do actual *work*. I think menus should come out of a button in the window, maybe Apple should add a blue button for the menu that pops up a NeXT-style menu
Well, maybe that’s what I should code in 40 years when I’m retired.
That’s the windows way. Have one window with the toolbar on top and all open documents open inside that window. Ugh!
The X11 + Mac way is definitely nicer. Use the *window-manager* for managing all your windows, put them on all the screens you have, use multiple desktops, but don’t run everything fullscreen and put all windows *in there*!
i agree with the author. i’ve never gotten used to the global menu bar..it is confusing, and any added benefit from the menubar being placed up top does not outweigh the extra time it always takes to ask myself if i’m in the correct application. and what’s with the one-button mouse? anyway two big reasons why i haven’t bought into mac.
ty
Menu bars are a UI element that should not be used frequently.
Maybe for you, but others may disagree.
I think a really well designed menu system can aide someone in learning how to use the application. For example, when I’m learning how to use a new app, I just peruse the menu system to see what kind of
functionality is available.
Menus and toolbars provide a different command interface to the software. Some people find it easier to navigate the command system based on the textual hierarchical structure of the menu system, while others find the graphical nature of toolbars easier. The benefit of a menu system is that most of the software’s functionality can be accessed through it while minimizing screen real-estate. Also, including keystroke combinations with the menu item text [think windows app] gives users the ability to learn how to access the most frequently functionality very quickly. Using CTRL+P[print] and CTRL+S[save] are faster and easier when editing a document then clicking a toolbar button or menu item [for me anyhow]. I personally feel that a well designed menu system with full keyboard support is the most efficient way of interacting with an app. That said, I think that the nouns[File] and verbs[Edit] used could be more intuitive. Not really an issue for us that know how to use the system and are familiar with the standards of an OS, but probably not very intuitive for new users.
“I haven’t used mac’s much, but I’ve tinkered with this emac we have at work that sits in the corner collecting dust. For me it feels like more work bringing focus to a window and then trying to select it’s menu items at the top of the screen. I guess they provide key bindings that could speed this up a bit, but moving the mouse cursor all over a 1280×1024 desktop feels like a big waste when I use the system. Just my opinion on the subject.”
I have the same feeling about global menu bars. I run my desktop at 1600×1200 and if I’m using a program which is located on the lower part of the screen (I sometimes have several non-maximized windows that I’ll work with at the same time) it takes me a lot longer to move my mouse up to the top of the screen to click on the menu and do something then it does when the menu is attached to the window.
Granted this is only an issue when the window I’m working with isn’t maximized or located towards the upper left hand side of the screen (which is often with some programs and never with others).
There are advantages and disadvantages to having a global menu bar, much like everything else in the world.
This is precisely why global menu bars are far more preferrable. I would rather have one unused menu bar out of the way at the top of the screen, than a menu bar on top of each of my ten windows. 1 unused element is way better than one unused element for each window on the screen! That is one of the reasons I typically have 3x as many windows open on my Mac than on my PC. So to me, it’s the per-window menu bar that is a holdover from the non-multitasking days.
You are forgetting that the top of the screen is the most important area of the whole screen. For ergonomic reasons, this should be at your eyelevel, and also because of Fitts law. I think the top of the screen should be rather used for something more common, like launching applications.
All of the points in the article are good ones (except for the last one, which I don’t understand).
Some additional thoughts on the subject.
Focus follows mouse is far more useful to me than menu on top. I would never sacrifice that feature.
I can’t see how a menu in each window wastes space. In the focussed application, the menu bar takes up an equal or lesser amount of space if it is in the window, rather than on top (the window could be less than the full width of the screen. In unfocused windows, I’m not so interested in maximizing screen real estate. They’re in the background because I’m not currently interested in them much.
Additionally, in OS X, it takes two clicks, widely spaced apart, to access the menu of an unfocused application. I have to click on the window to focus it, then move my mouse to the top to click on the menu. In KDE, I just move my mouse to the menu.
On the subject of small windows, I’ve never seen an application that was meant to be in a small window, but had a large menu bar. My instant messenger window (kopete) is quite narrow (~250 pixels) and has room for 4 top level menus. If your instant messenger needs more than about 5 menus, it’s broken. In fact, I’d argue that for these small applications, a global menu bar is a huge waste of space. Instead of using up about 20×300 pixels, you are now using 20×1024 pixels since the top menu bar is the width of the screen.
I use OS X, and I’ve tried the menu on top thing with KDE, but it just doesn’t work for me. Too many clicks, too much mouse movement. For the people spouting fitt’s law, it’s a tradeoff. I use the close button much more often than I use the menus, so I’d rather have that at the top of the screen.
I have heard the arguments for the global menu, but by and large about the only argument that I ever hear that sounds compelling is the infinite height argument that you can overshoot the menu on height and get to the menu, but as many have pointed out the infrequent use of the menus and that most any common functions have memorable keybindings I don’t find this as valueable as the proponents of the global menu think. Menus attached to individual program(a la windows and some unix GUIs) allows one to be in focus on one program and click on a menu in another inactive program that is visible next to the active windows by simply clicking on the menu of the other program. You don’t need to bring your mouse to the inactive window to change the focus of the program and then go back to the menu at the top. I realize that you need a monitor capable of a good resolution for this is be too practical, but with high resolutions becoming commonplaces I think this would be a useless advatage for those using multiple programs at the same time.
have to move the mouse to the top of the screen just to open more shells since simply trying to launch the terminal emulator from the icon on the desktop more than once doesn’t work.
Mate, try ?N.
And yes, menu bars are a very important of UIs. This does not mean they are commonly used so should not be put in the most accessable part of the screen.
No unicode
I meant apple-N (but others already said that)
Should try the Preview more often.
I agree with the article. The global menubar is a relic of yesteryears. It should be abandoned. The fitts law argument for its survival is exaggerated.
I completely despise the MacOS user interface. To me the only redeeming quality of the Mac is that you can run Linux on it. Otherwise they are only useful to prop doors open. A good part of that reason is because of that fucking obnoxious global menu bar. I despise that it serializes my workflow back into the anemic computing environment of 1985 where it was hard to run more than one program at a time. It makes the whole GUI modal. This wasn’t so bad when you had a tiny monochrome screen but there is no way in hell that you could get me to switch backwards to that crap again. I cannot believe they left that in OS X when they made the more NeXTish change to the new OS.
Michael
The amount of precision it takes to reach a specific pixel (or area) in some part of the screen is definitely much more than the one you need if you “only” has to roll to the top of the screen. If your mouse has good acceleration, this is just a matter of reflexively roll the mouse upwards and you’re there; in the Windows/KDE/Etc. paradigm, you have to carefully reach the menu which is randombly placed in the screen, inside a window. Even worse, the menu could be too long and if the application is too close to the lower border the menu may display upwards generating more imprecision and confusion; if the menu is only a few elements long, it won’t display upwards… so.. you get the idea.
People may be used to KDE style and Menu inside the window, but if you just think of it a little bit, even when not perfect, the OS X way is very usable too. I come from the Windows world and when switched I found the top menu bar quite adequate. It just takes a little bit of effort to get used. After 15 years of “the other way”.
My 0,2¢
I’ll preface this by saying that I have NOT used an OS for any substantial amount of time that uses global menu bars, but I think I understand how it works and really see no point.
There are a lot of comments about screen real estate wasted by per application menu bars. Now I love every little bit of screen real estate(I run at 1600×1200 res), but it seems the more you like screen real estate, the farther your apps are going to be from the global menu bar. For instance, I have firefox and gaim open right now, gaim is in the upper right hand corner of my desktop, firefox in the upper left hand corner. Now for firefox’s position, the global menu bar idea seems fine, at the moment, but for gaim on the other hand, if I have my mouse over gaim it’s going to be quite a long way to the upper left side of the desktop. If I decided to open a term right now, it would end up in the lower right hand corner, really far from the global menu bar.
I also see a lot of references to fitt’s law, which I understand from the thread says that the target area and the amount of distance to be traveled are both parts of the equation. So it seems counterproductive to be traveling over 1000px just to save 200×20 px from my gaim window and 20×1000 px(I’m obviously estimating all the pxs) from my firefox window just to gain a “greater” target area. Also this target area is only bigger for your mouse, due to the border. As far as you eyes are concerned, the target area is just about the same size, and for me at least, having the target area be bigger to click on than it already is doesn’t make too much sense unless you’re a klutz with a mouse or a drunk.
I see how this is a benifit to those who use one window in full screen mode, as it saves screen real estate there without any real hinderence. On the other hand though, for those people who really care about screen real estate, are you really running most of your apps full screen? Wouldn’t that be a waste of screen real estate?
Maybe I don’t understand completely because I haven’t had a large amount of experience using global menu bars, but logically it just doesn’t seem to add up. Maybe that’s because I’m not a UI designer. Honestly though, I really can’t find a reason I’d like to try it.
In Os X, there isn’t a seperate instance of each app like it is on Windows or Linux. Every time you launch an application in those OS’s they launch a WHOLE nother app.
Not true. On Windows, try starting IE several times. You’ll get a new window each time, but only a single process. Typical SDI behavior, office does this too. But if you start Media Player a second time, it only switches to the already opened instance, you get no new windows or processes. Single document, single window. Very newbie friendly, but a pain in the ass for the rest of us
Other apps can have several instances (processes) at the same time, cause this make sense for some power-user apps, like Total Commander. In that case, the Mediaplayer hand-holding behavior would just make the app less useful. You could of course implement a combination of SDI and MDI in such and app, to make it only ever use a single process, but that seems like a waste of time and effort for an app that is mostly used with only one instance anyway. Firefox is an example of this – multiple windows, each with multiple tabs. And you can’t start more processes even if you try.
which results in the menu bar being at the top of the screen and no being able to see the desktop, I think a universal menu bar is a good thing.
just right click and select new shell (of ctrl-click if you like the 1 button mouse)
Menu bars like that are leftovers from when Mac OS was primarily a single process operating system, and it should have been ditched long ago.
Intuition had a global menu bar, and the Amiga was a multitasking system from day 0.
In facts, when I first used Win 3.0 I found the per-window menu non practical and screenspace wasting.
Years passed and I get used to it also. But when I found myself in front of the Workbench on an Amiga emulator, or with Mac OS X, I found the global menu a refreshing experience.
Could be a very subjective thing, maybe.
Bye!
People who have never spent one minute doing a real usability test need to stop writing articles about what is or is not more usable. Just because you don’t like it, doesn’t make it unusable.
People (including you, yes you, right there, reading this post) are incredibly bad at judging their own performance. This is a fundamental fact that forms the basis for any non-crackpot psychological research. That means you personally have no authority to say whether or not somethine you use is more or less usable. Not to mention how your performance extrapolates to your peers, or to the population in general.
And a bit of advice, in the future if you want to be taken seriously when you’re talking about usability, you probably won’t want to mention how great “focus follows mouse” is. Sheesh, what a newbie.
If “no more info was sent”, how can you really know if he wrote the article himself and isn’t plagiarizing?
I’ll vote global, although I admit it’s personal. I’ve used Macs and Windows for many, many years, and the global menu bar feels way more productive to me.
I think that people who believe that local menu bars are faster to access are really missing the point – you don’t move the mouse to a global menu bar, you ‘throw’ it. See The Humane Interface (Jef Raskin) for a mathematical proof. People who try global menus and say they have to move the mouse further are conditioned by their use of local menus.
The mouse-move-changes-focus is a red herring – the global menu bar could easily be made to change based on mouse focus, as it does now for input focus.
Re: comment by Anonymous
“I think the top of the screen should be rather used for something more common, like launching applications.”
You launch application more often than you use commands in an applications? Surely, most users launch a few applications to perform a task, maybe adding an application or two as necessary. An interface should be designed for the majority of it’s users, not a few power users. That’s not to say it can’t add features to accomodate power users, but the design must be for the average user.
not bad. The problem in this topic is the adaptation of the user.
I like the global menu bar because it keeps all the items that I rarely use out of the way so that I can focus on my current task. In Safari for instance, I use keystrokes for new windows, new tabs or bookmarking. The only task that I tend to use the menu bar for is application preferences (I just realized that there is a preferences keystroke).
It also reinforces the fact that you are using one application of “Safari” with many windows instead of “Safari – OSNews.com – Exploring the Future of Computing” and a dozen other sites all as separate running applications.
heh FFM was a funny comment.. I can just see my dad moving to the menu and all of a sudden the app he was using loses focus for some unknown reason 🙂
I am a power user and I hate FFM. it is only good for accessing menu items on an unfocused window in a window based menu OS.
The major issue with the global menus is the fact that it sets the standard for where the focus is. For example, if you alt tab through applications, you only get one of the many potential windows of the application. Having the applications self-contained makes more sense in this regard because each window is essentially an application. I have never understood why Apple chose to use a direct manipulation metaphor with the file manager and drag and drop while completely destroying that metaphor with a global menu. With that said, I am not that familiar with OSX so I am sure there are options available that can be easily learned. It is always my pet peeve when on a mac.
You launch application more often than you use commands in an applications? Surely, most users launch a few applications to perform a task, maybe adding an application or two as necessary. An interface should be designed for the majority of it’s users, not a few power users. That’s not to say it can’t add features to accomodate power users, but the design must be for the average user.
Most commands I use in an application are within toolbars or within the interface. In Firefox I use toolbars for back and forward, or interact with web pages directly. The only thing that is in the menus that isn’t elsewhere is uncommon commands like opening files or help. I certainly use those uncommon commands less than launching applications.
I’m glad someone has taken the time to spell it out. There are a few other points that are worthy of mention (asides from the multiple monitor problem which is huge)
A) FITTs law has to be seen as being two-folded. First you have to make the menu selection and in that case, for a single-monitor the global menu wins; however, then you have to return to original place of focus and the more distance the mouse has to travel from your focus area the less likely you are going to be able to reliably return to it. Local bars win on the trip back. Further, I don’t have to change my point of focus and that makes a huge difference. Otherwise, there is no point in having multiple, open windows to begin with.
B) On large desktops, the amount of mouse movement for a global bar is ridiculous. It is worse for multimonitor setups. The only time global wins always is when you only run apps full-screen — but then local bars are equivalent to global bars.
C) Local bars can be improved vis-a-vis screen real-estate by having them hide when a window loses focus. In fact, all non document controls could be hidden leaving that much more useful information visible in a non focused window. As a matter of fact, when global bars are used, the preference seems to be to include larger toolbars in their place. Thus, no screen real-estate is actually saved but more focus and refocus work is required by the user.
In a palm top or limited screen area I’d prefer full-screen app windows with a “global” bar. On larger displays I prefer multiple windows with local bars. And, despite all the global bar supporters, the real reason to favour local bars is FITTs law just because you have to look at the whole interaction and not just the menu selection. Which leaves…
D) Perhaps the best menu bar is a context menu since it is always where you need it to be — directly at the mouse pointer.
While certainly not the ideal solution, top menu bars do provide a some value. They’re more consistent than their Windows cousin. In Windows, to open a new IE window, I press ctrl-N. To close that window I press alt-F4. Suppose I’m going quickly though; open, close, open, close, close. What’s happens when I close the last IE window and instinctively press ctrl-N to create a new one? I’ve close not the window, but the IE application, and open another application’s window. Similarly, as open now behaves differently, so too does close, possibly bringing up the shutdown dialog. To use keyboard commands safely, I must keep track of my stack of windows and be aware of any implicit shifts in mode.
Top menus provide a distinction between the window and application metaphors. In Windows, what might be called a window can in fact be an application and the user needs to be aware of the subtle difference. While this may seem like old hat to most of us, it actually requires fair amount of mental acrobatics to move through such an environment without error. Perhaps not huge deal, but it does mean most Windows users don’t take advantage of the keyboard, where many Mac users do.
This window and application separation also allows a clean way for applications to sit in the background. A mail or ftp application can remain running without keeping an open window. In Windows, a background app’s only real option is to run in the taskbar, which isn’t its intended purpose. Now a taskbar icon can either reflect some state of his machine or be a full fledged application. This requires even more mental overhead from the user. The misappropriation of taskbar is such a problem, a feature of Windows XP is hiding the myriad of icons.
You also don’t see much of windows within windows on the Mac. More mental overhead.
“I cannot believe they left that in OS X when they made the more NeXTish change to the new OS.”
NeXTSTEP had a global menubar too, the main difference is that it was vertical and movable.
Considering how little it’s necessary to access the menubar (thanks to keyboard shortcuts, contextual menus and toolbars), I don’t see what all the fuss it about. I find that needing to access the main menubar is quite rare, even in complex apps like Photoshop. The possition of the menubar doesn’t significantly effect my workflow when I’m only using it a few times a day. Even if the global menubar was less efficient in some ways, I think the saved screen space makes it a better choice.
One of the reasons I like the Opera web browser on Windows is that it’s an MDI app with a single menubar for all windows. That means that I can tile or cascade individual web page windows without them each having a menubar taking up space.
Actually, I’ve been meaning to hide the main Opera menubar. You can set it to appear as as a dropdown menu from a toolbar button and I don’t use it enough to have it on screen all the time. 99.9%+ of the time all the controls I use are available from the toolbars, mouse gestures and contextual menus.
I can see the arguments for the idea that the top 20-odd pixels is a great place for something. I’m less convinced that it is the best place for an application-specific menu-bar I might use once an hour, rather than a desktop-wide taskbar I use several times an hour. The universal menubar on OSX bothers me a lot less than my inability to remember how to switch between application windows.
There is also a rather interesting problem I have with the OSX universal menu. It is possible to have an application open with control of the menu-bar, but no open or visible windows, and a different application with visible windows. While it does not happen often, it happens frequently enough to frustrate me.
People (including you, yes you, right there, reading this post) are incredibly bad at judging their own performance. This is a fundamental fact that forms the basis for any non-crackpot psychological research. That means you personally have no authority to say whether or not somethine you use is more or less usable. Not to mention how your performance extrapolates to your peers, or to the population in general.
Actually, I would argue the basis for any non-crackpot psychological research is the examination of human behavior. The interesting feature that people misjudge their own performance follows from that.
On the other hand, having acutally done usability testing, I’m increasingly skeptical of the claim that there are very many rules that apply to “the population in general.” I suspect the only universal rule of usability is that you have to design for specific populations performing specific tasks in specific contexts.
‘system tray’ instead of ‘taskbar’, sorry.
Perhaps Apple need to introduce 3 button mice like what the rest of the world has. The middle button could be used for instantly snapping the mouse to the menu bar and back to the focused application…of perhaps for popping the ‘application context menu’ much like how the right mouse button pops up a control/window specific context menu. Of course, this starts to overcomplicate matters which isn’t consistent with Apple’s design philosophy.
For the record, I vote for the global menu. At first it takes a bit of getting used to, but I prefer it.
Whatever Apple does is The Right Thing. A few years ago they used to argue that the Mac menu behaviour (menu disappears if you don’t hold the mouse button) was much better than the Windows behaviour. Of course, nobody bought up the issue anymore after Apple copied the Windows behaviour…
Almost forgot an obvious space cleanup for local bars:
E) integrate the menu bar into the application bar.
You launch application more often than you use commands in an applications? Surely, most users launch a few applications to perform a task, maybe adding an application or two as necessary. An interface should be designed for the majority of it’s users, not a few power users. That’s not to say it can’t add features to accomodate power users, but the design must be for the average user.
I find it interesting that most desktop models do put the interface for launching applications at the bottom of the screen, another “throwable” location.
But I’m wondering if the invention of the mythical “average user” actually leads to less than optimal interfaces in many cases. Not that I see an answer to the problem, I just get very twitchy and nervous whenever the “average user” makes an appearance in these kinds of discussions.
I just wanted to note that you can set up KDE to use (a la Mac) global menus.
Best regards
Single menu bar is very good in a lot of situations… Didn’t like then until started using a Mac for work past year… but they look very sweet.
The major problem is when you need to access the menu bar from another app in the desk… then you have first to select this app and then click on the menu bar… not dificult, but VERY annoying for heavy multitask users…
There’s also some editor/pro programs that does perform better with per-windows menu bars (well, not in ALL windows like GIMP…).
I think for maximised windows, global menu bars are great. But otherwise, they can be a bit cumbersome.
And I think any other comment isn’t really much worth.
Pie menus with keyboard acceleration is the best, IMO.
See http://en.wikipedia.org/wiki/Pie_menu
would you just leave? you do nothing but spit venom. this entire discussion has been civil and you interject by claiming that Mac users are irrational fools for not agreeing with you.
This article really made no sense. The first point is silly, because a global menu bar doesn’t put any more emphasis on menus than a lot of individual menu bars. It makes menus quicker to access, so you might use them more often, but the alternative is making them slower to access, which makes no sense! By that logic, the menubar should require a complex escape sequence to pull up… The second point makes no sense either. In all GUIs, there is an “active” (foreground) application. All global things go to the foreground application. Global things include menubars, keyboard inputs, mouse clicks, etc. Having the global menu target the focused app is no different from having keyboard input go to the focused app. MacOS is particularly rigorous about making the user consious of the foreground application. That’s why Photoshop’s toolbar windows dissapear when you unfocus the app. The third, fourht, and fifth points are implementation details, not flaws of the global menubar context in general. As for the last point, I don’t have a clue what the author is trying to say there.
There are few things as objective in GUIs as the global menubar. Just do the math (plug numbers into Fitts’ equations) and you can prove a quantitative superiority. The dislike of global menubars stems almost entirely from inertia, and from experience with braindead UIs like Windows that have a very sloppy concept of the currently-focused app.
This article really made no sense. The first point is silly, because a global menu bar doesn’t put any more emphasis on menus than a lot of individual menu bars. It makes menus quicker to access, so you might use them more often, but the alternative is making them slower to access, which makes no sense!
That is the point, they should be put in a slower to use spot. The top of the screen is fundamentally the most accessable spot on the screen. This implies something useful and frequently used should be put here. Menus aren’t used frequently. Menus contain all the common and uncommon tasks for an application.
In Firefox the common tasks like back and forward, and interacting with the web page is done without menus. No one uses a menu to go back or forward because it would be slower no matter where the menu is. Uncommon tasks like help or opening files are exclusive to menus, and thats really what menus are used for. Since menus are used infrequently, the space at the top of the screen should not be wasted by them. This is not saying menus are unimportant – they are very important – they are however not used frequently.
theres soooo many innovations to do there!
the desktop ergonomics should take a look on the 3D modeling and animation softwares , coz their really complex appz made easy to use because of greats ideas.
But it’s not a fact that it is more usable. Considering Fitt’s law actually has 5 hot spots, not just 4. That included the context menu, as it is used in Windows/Linux. It is just different…
The context menu is rather different from the main menu. It’s not supposed to hold a lot of entries, while the main menu is supposed to be a canonical listing of appliciation functionality. So it’s not an choice between global menus and context menus, but a choice between global menus and per-window menus. Mathematically, it is a fact that global menus are better than per-window menus.
@Anonymous
That is the point, they should be put in a slower to use spot. The top of the screen is fundamentally the most accessable spot on the screen. This implies something useful and frequently used should be put here. Menus aren’t used frequently. Menus contain all the common and uncommon tasks for an application.
That’s just your opinion. I use menus all the time, via keyboard shortcuts and the like. In fact, I can’t count how many times I acccess the file menu in Firefox, etc. using “Alt + F” to bring up the menu and then arrowing to something I want to use.
I strongly disagree that menus aren’t used often. When I’m in Photoshop I use them *a lot* for example…
The global menu is confusing because you don’t always know which window has focus.
If you want to change something in a window that doesn’t have focus global menus go against Fitz law. You have to move the mouse all the way down and click on licq then move it all the way up and click on the menu.
I use the top pixels to change between windows (right click to lower, left click to focus). I normally have 10-15 windows open at a time so switching between windows is important. I use the left hand row of pixels to launch new apps.
I also see a lot of references to fitt’s law, which I understand from the thread says that the target area and the amount of distance to be traveled are both parts of the equation.
Fitt’s Law is defined as:
T = a + b log_2(D/W + 1)
Where T is total time, a and b are emperical constants, D is distance to target, and W is width of target in the axis of motion. This equation has been supported by decades of studies. The reason in-window menubars are fundementally flawed is because they are narrow in the axis of motion. Usually, ‘W’ is on the order of the height of text, which can be as little as 10-15 pixels. In a global menubar, ‘W’ is infinity, so even if having the menu at the top doubles ‘D’, it’s still a win. In emperical studies, a Mac user acquires a menu item 5x faster than a Windows user. For people using an inaccurate pointing device, like a pointing-stick or touchpad (remember, nearly half of computers sold these days are laptops), this number is probably even bigger.
There are few things as objective in GUIs as the global menubar.
Well, in my case it has to do with naughty habit of not accepting things on dogma. Or perhaps I should say that I’d be interested in research comparing the global menubar to the global taskbar, rather than the global menubar to the window menubar. I’d also like to point you to the fact that in some cases (kiosks, POS systems), any kind of a menubar, much less a global one, should be involved, so I would not call it an obvious truth for all application domains.
MacOS is particularly rigorous about making the user consious of the foreground application. That’s why Photoshop’s toolbar windows dissapear when you unfocus the app.
I’ve run into cases where I’ve been honestly confused about what the foreground application happens to be. This occurs when there is a foreground application with focus that does not happen to have a foreground window.
If you want to change something in a window that doesn’t have focus global menus go against Fitz law.
Not if you do the math. An application is an enormous target (hundreds of pixels). That means you’ve got two fast motions (big ‘W’s in the above equation), instead of one slow motion (small ‘W’ in the above equation).
Not if you do the math. An application is an enormous target (hundreds of pixels). That means you’ve got two fast motions (big ‘W’s in the above equation), instead of one slow motion (small ‘W’ in the above equation).
Assuming of course that the application (or the application window) is visible at all on the screen. Then you are faced with a situation of getting the menu (a big W or a small W depending on the desktop design) then getting the menu item (small W).
My apologies for the mispelling of your name BTW.
I think I agree with the author, mostly for the dual monitor dilemma.
Well, in my case it has to do with naughty habit of not accepting things on dogma.
In professional fields, existing research is generally accepted, unless there is evidence that it is invalid. If you’re going to claim that Fitt’s Law is invalid, the onus is on you to prove it’s invalidity. As for the other research you’d like to see — Fitt’s Law is an equation, and has nothing to do with menubars per se. Global menubars is just an application of that equation. There is no reason you can’t have global menubars and a global taskbar — there are four edges on each screen.
I’ve run into cases where I’ve been honestly confused about what the foreground application happens to be. This occurs when there is a foreground application with focus that does not happen to have a foreground window.
Such an app is badly designed, for reasons that have nothing to do with menus. In such an app, where does keyboard input go? The thing is, as long as we have keyboards, we will require the concept of a foreground application. Once we have the idea of a foreground application, we need to build a system consistent with it. Global menubars just fall out of that requirement.
wow.. you continue to sunrise me. very unexpected of you I must say.
be careful though, some of these newbies on here might think you are a mac fanboy for supporting even a portion of the Mac side of things.
In professional fields, existing research is generally accepted, unless there is evidence that it is invalid. If you’re going to claim that Fitt’s Law is invalid, the onus is on you to prove it’s invalidity. As for the other research you’d like to see — Fitt’s Law is an equation, and has nothing to do with menubars per se. Global menubars is just an application of that equation. There is no reason you can’t have global menubars and a global taskbar — there are four edges on each screen.
I’m not arguing that Fitt’s law is invalid. What I’m arguing is that it is not obvious that an application-specific menu is the best thing to put at that particular edge, given the debate as to how frequently that menu is used compared to other functions. (And also that what works best for one domain and population may not work best in another domain.)
Such an app is badly designed, for reasons that have nothing to do with menus. In such an app, where does keyboard input go? The thing is, as long as we have keyboards, we will require the concept of a foreground application. Once we have the idea of a foreground application, we need to build a system consistent with it. Global menubars just fall out of that requirement.
(From memory) the app I’m talking about is the Mac OSX terminal program. Unfortunately, the household powerbook is in Atlanta, so I can’t play around and provide a screenshot of this at work. The question is, are there cases where it is reasonable for an application to have focus with no open windows? Or should the application not be active in the absence of open windows, or show a dummy window? I don’t know the answer to this question, I just wanted to highlight an example of a case where OSX is not always obvious about which application has focus.
remove the wax from your ears and listen up…..
none of your argument is relevant to this article. the argument in the article was about why WINDOW BASED menus are better than GLOAL menus.
if you want to discuss the relevancy of putting a menu at the top of the screen rather than some other interface element, write an article about it.
BTW.. there is nothing keeping an application menu from being added to Apple’s global menubar. right now on the right side I have volume control, date, time, virtue VD control icon, GMailStatus, display controls and iChat status . no one says you cannot write an applet that creates an icon control item that lists the applications or open tasks, etc.
Oh, as another example, finder used to be one of those applications that could have focus with no visible open windows.
I would also like to add that another point of confusion I have with the OSX global menu is that I have a hard time getting used to global functions mixed with local functions. Now perhaps that’s not a bad thing overall, but it still is one of those things that bug me when I’m switching between paradigms.
I agree. My only problem is that I like the infinite on the CLOSE BUTTON rather than the menu, so I stick with Winodws and linux…
If you use the top edge for something other than a pull-down menu, then you push the application menu to another location. The left and right edges are problematic because of tradeoffs with readability and screen real estate. This makes the top of the window the next best choice.
Deciding what interface elements go in the best location is the easiest part of design. It’s what to do with the interface elements that are not quite important enough to go in the best location that’s the challenge.
Which is why I personally have always had difficulty using Macs – I don’t use them often enough to adjust to their many quirks, and those quirks coming from the PC side of things just annoy me to the point I end up wanting to throw the machine out the window. This is simply one (of the many) quirks.
For most people it’s hard enough to learn to use a computer. For them, having to RELEARN by switching to a different way of doing things frustrates them worse than a nube sitting down for the first time… For longtime users who are profficient on one platform, this effect is magnified a thousand fold… especially if said person has a stack of work they need to do, in which case there’s no time for yet another learning curve.
Thinking back though, coming from the DOS world pre-GUI I remember sitting down at a MAC for the first time and going “Wow, this sucks. Completely counter-intuitive… and this is supposed to be EASIER to use?”
Matter of perspective.
I agree, about the menu bar not being good. I now own a mac, and have adjusted to it, but it’s by no means a great thing.
I think its find for core OS things, make it sorta like the windows start menu as an access point to OS things, and have finder route into it. But apps should have their own tool/menubar. Apple could easily make an add-on to the GUI that allows menubars to let users have such an option. And if it was collapsable into the apps window, like they do now with options on the windows (not sure what you call that when you click the oval). But still retain the current menu bar function.
The big problem is simple. Were are not in 1986 any more. Any usability study from then, is totaly worthless today. At that time, a menu bar would have been the way to go without a doubt. Since pretty much everyone used one app at a time, at full screen. It just made sense then. But now this is not the case. Next to no one runs apps at full screen now, unless you are using some major app doing a specific thing. A normal user now has a 17 inch or bigger monitor, and runs at a res over 1024xwhatever. People now have a Browser window or 2 open, AIM windows open, some music app going, and so forth, none of these are full screen, and people switch back and forth non stop. This is where the global menu bar fails. You have to keap going all over the place to get to the menu. They just don’t work when people have windows all over the place. And people are just going to keap having smaller and smaller windows relative to screen size, and more and more windows open at one time.
I’m sure if people did a really good test today, the global menu bar would tank. After all, companies like Microsoft have probably spent way more money studying these things then Apple, and most other companies had the advantage of going about things after Apple, and far as I know, none have done it the apple way. I think the reason is simple, the apple way is not better. But clearly if Apple contracted a new study done today, and it came back saying the menu bar was bad, there is no way they would get rid of it. It’s the Apple way, they have 20 years into it, they would never get rid of it plain and simple.
People need to stop using random studies, especially any that are very old. in the past 5 years computers have changed a lot, they are now everywhere and nearly everyone uses them. It’s a whole different world now and no study from the 80s could ever fit in today, computers are different, people are different, peoples experience around computers are different and people use computers for different things.
As the title says, I find the most awkward situation with the global menu bar is when you’ve closed every application. What do you do with it then?
The mac route is to turn it into a “Finder” menu IIRC, which is completely inexplicable – there isn’t a Finder window in focus, yet the menu bars are acting like there is.
I know there’s meant to be a “Finder” in the background that you’ve selected, but it’s not obvious at all. If I close down all my apps on here, I don’t suddenly find I’ve managed to activate a MySQL or DBUS background process.
It’s all very well putting the menus at the top, but it does prevent you having the minimise, maximise and close buttons in the top corner which I don’t think is a good thing. Of course in OSX the red X is nigh useless anyway so I guess that’s not such a problem 🙂
how can you access the menu bar using a keyboard shortcut in OSX ?
I know copy to clipboard is apple+c
I am not talkin abou that.
say I want to open the _Edit_ menu and view whats under it is that possible?
Fitt’s Law describes untrained movements, not movements that are executed after practice.
In other words it is irrelevant in quite short time.
Breaking down all of the arguments:
1. How is having 1 menu bar for everything placing unwarranted emphasis? I would think a menu bar in every window would place more emphasis on menu bars.
2. In OS X atleast, the menu bar tells you the name of the app you are working with.
3. Valid argument. (But not everyone likes focus follows mouse ;-)).
4. Valid argument and I cant really comment because Ive never tried using Dual Monitors on anything but a PC with Windows.
5. This is a problem with GNU/Linux and Unix not with global menu bars.
6. How is a menu in a moveable window a fixed target? Atleast you have some idea where the menu bar is and after some use you would probably remember where the widgets are anyways.
1. How is having 1 menu bar for everything placing unwarranted emphasis? I would think a menu bar in every window would place more emphasis on menu bars.
The menu is an infrequently used UI element (UI studies show this), yet the top of the screen is the most important part of the screen (Fitts law + ergonomics).
2. In OS X atleast, the menu bar tells you the name of the app you are working with.
Don’t make me think.
6. How is a menu in a moveable window a fixed target? Atleast you have some idea where the menu bar is and after some use you would probably remember where the widgets are anyways.
This really is a minor issue, but with each window the menu bar resizes. Because this is in global space, not space local to the application it is confusing. It makes it hard to be able to quickly get to a certain window of an unfocused window.
While I can see the appeal of a global menu bar on a single display system – it’s out of the way, and realisticly not far from the application., I have to agree with the multi head complaints.
I use a triple headed system, and having to drag my mouse from the far right monitor, to the far left, where I keep my panels to leave the centre clear for whatever I’m focused on.
Although admitadly I tend to be using two full screened vim instances, and an IRC client most of the time, so it’s not like I spend much time in menus anyway
I agree, the single menu bar is not the way to go, its clumsy.
but i also agree we are using too much screen real estate.
windows should be done something like this
|Application Name |Menu Bar |Min,Max,Close|
The application name bar, is a waste as it is.
Fitt’s Law has nothing to do with untrained movements. It describes movements in general. It’s really annoying having a discussion when people refuse to spend 5 minutes looking up basic theory in Wikipedia.
So after seeing Fitts law….it seems stupid as hell.
T = a + b log_2(D/W + 1)
so to figure out who is faster all you really need to do is fill in the value for D and W in X=D/W. Whatever has the lower value of x will be faster.
Now here is where this all starts to become ridiculous. If your distance is let’s say a pixel and your target area with along the axis of motion is say 100 px or 10x that in reality it will take you the same amount of time to perform that action, but according to fits law that’s not true. Having a 1000 px area to land in when moving one pixel is going to end up being 10x faster than moving into a 100 px area according to Fitt’s law. Obviously this is incorrect. The same mistake happens when the target area becomes very small, hitting a 1 px area is going to take a hell of a lot longer to hit than a 10 px area, not depending that greatly on the distance. Moving the initial distance will be much faster than locating the one pixel.
So if we begin to get a little smart about this we will realise that when dealing with most desktops, 100px is going to be just about as easy to hit as anything over 100px, so sticking to the law (even knowing that it’s dead wrong), and trying to make it work in the real world….Let us say that a global area has a hit box of 100 EFFECTIVE px.
Now for the setup of my enviroment, I have a gaim window open on a 1600×1200 desktop in the far right, the global menu has the button i’m seeking somewhere within the top 20 pixels of the screen, about 300 pixels off the left side. Now let’s say my mouse is in the dead center of the gaim window, so about 1450 pixels in from the left and 300 pixels from the top. It’s going to take somewhere around a distance of 1200 pixels to go from the center of the gaim window to the button on the global menu I want. And we are going to count the hit box as 100 pixels(this is probably bigger than will make a difference, and truely I’m not moving nearly as much vertically as I am horizontally which makes the hit box even smaller, but we are giving the global menu the benifit of the doubt here). Now to get back to the gaim window from the global menu it will take us again 1200 px distance to hit an effictive 100px hit box. That gives us: X=2400(trip both ways)/200(both hit boxes) or X=11 for the global menu bar.
Now let us do the exact same thing with a local gaim menu. I’m trying to reach less than 300 px up(but we will count it as 300 px to give the global menu the benifit of the doubt) and less than 150 left(we’re doing the benifit of the doubt again), so this gives us about 335 px as the distance to the local menu. Now to get back we are going another 335 px to an effictive 100 px hitbox. That gives us x=670(trip both ways)/120(size of the two hitboxes) or a X<6 for the local menu.
So we can see clearly here that even giving the global menu the benifit of the doubt, the local menu can be a large degree faster than the global menu. And most likely the local menu is faster than the global menu if you are running a couple applications on your desktop at once, in which case many of your apps will reside farther away from the global menu. Both methods are probably very similar on just speed to reach their respective menu(at least according to this law), but the return trip is much faster on the local menu. We can also see here that Fitts law doesn’t take into account extreme cases, such as “infinite hit boxes” or “infinitely small hit boxes” and therefore the whole thing probably shouldn’t be relied upon for much of anything.
simply read original two papers instead of wikipedia.
It is annoying if someone something somewhere heard, but not quite.
The thing I really like about global menu bars – when used properly – is that they provide some decoupling between the concept of “application” and “current task”. Ideally, in an OS X app, the menu bar is where you put all the stuff that either pertains to the application itself (save, help, etc.) or that could be used for every task/document/window in the application (edit, save, etc.). Anything that might apply to only a subset of the windows in an application or that is used often is then offloaded to that application’s toolbars.
I’ve noticed that this conceptual separation of an application from tasks of that application is both the most fundamental difference between the Mac user interface and those of most other windowing systems. It’s also sitting at the center of a whole mess of “Mac vs. XXX” debates – the way you can close all the windows in an app while still leaving that app open in Mac OS is another great example.
Methinks it lies at the heart of a lot of the issues raised in the article, too. For one, I think that global menu bars is only confusing if you are really used to a window-centric GUI – I had the same problem when I first switched to Macs about two years ago, and now I experience the same vertigo when I sit down at a Windows or Linux box after a long time without using either.
The same thing with the “disconnected from the task at hand” argument – now that I’m used to it, I don’t feel that way because “the task at hand” often involves several windows from the same app (especially when I’m programming in XCode), so the task at hand isn’t really tied to any one rectangle on the screen, anyway.
Focus follows mouse is largely a religious issue, and quite honestly , I don’t think it’s as sensible on OS X as it is in Windows or most X desktops for reasons that I won’t go into here because this post is already running too long.
The multiple monitors is the one I’ll really have to agree with wholeheartedly, and I’ll even extend it to include large monitors. We have one of those newfangled Apple flat panels that’s bigger than my TV at the office, and I gotta say, it’s pretty annoying to have to move the mouse across what feels like four feet of screen space in order to get to the File menu.
The mac route is to turn it into a “Finder” menu IIRC, which is completely inexplicable – there isn’t a Finder window in focus, yet the menu bars are acting like there is.
The whole desktop is a part of finder. It’s just like a window except you can’t change the size or move it around.
There seems to be an assumption in this discussion that a dual monitor setup only means side-by-side. Another way to use a laptop with a desktop monitor is with the laptop on the desk and the second monitor on a stand above, giving you a “deeper” rather than “wider” screen. In this case, the global menu is still in an easy and consistent place to reach.
At the top.
Global menubars exist because back in the old days (you know, before Windows and windows) there were full-screen applications. The problem people had with full-screen apps is that it was totally unclear what the possible commands were. You needed a lot of training to use the program, which was a ridiculously high added expense.
Plus, that was in the VAR days of computers. Nobody wants to support that sort of infrastructure now.
Menubars came about in an attempt to make the scope of possible commands more apparent to an unskilled user. Skilled users could eventually use command keys, but most people started out using menus.
Fast-forward a few years, and well, that unskilled user doesn’t really exist anymore in any meaningful way. In a generation, there won’t be any more unskilled users, period. Dealing with those users has really prevented UI designers from making a richer UI – you always have to worry about Grandma. For users that have been computer-literate since they’ve been 5, maybe menubars are on the way out. Why not have the menu pop up when you right-click (like the Kensington mice do)?
The only real downside to menus-in-windows is it takes up real estate. But realistically, people have real estate to spare these days. Toolbars work better (or word buttons), but toolbars have a problem where if you don’t know what the icon means, you’re hosed (see Word 6).
The reason for the global menubar in the MacOS is that the application can be open without documents. It’s always been unclear why that is, and it may be a remnant of the switcher days. It also provides a handy place to stash little things, like MenuMeters, airport status, battery state, etc. Windows uses the taskbar for the same thing, but that’s just a reverse global menubar.
Maybe dashboard will let people come up with some creative off-menu ideas?
I agree with everything said here. I never understood why some people (usually mac fanatics who blindly think EVERYTHING macs do is the best way to do it) find it so much easier. I’ve used macs a little bit and this has always been one of the more irritating features to me. It seems like I have to move my mouse a dispopotionate amount away from the app I’m using to get the menu bar when I need it.
One counter point though: Since menus are ment to hold the many not so common features, Having the menubar global means less screen space is dedicated to ALL menubars when more than one or two apps are open.
Also, I see no problem having this setup as an option in gnome or KDE for people who prefer it, or who are switching from a mac and find it more familiar.
Amigas and other systems had global bars too and weren’t single-process.
Has ANYONE here heard of Fitt’s Law? It states that the edges of the screen are the fastest-accessed points with a mouse cursor, particularly the corners, because you can jam the cursor up to them without having to slow down.
Guess where the global menu bar is sitting?
This isn’t just a Mac thing (never was exclusive to Macs), and there’s a reason for having it.
Jeesh.
The author agrees that the top is the most important part of the screen. Hence the advocation to put something that is used more commonly there.
Wow, the guy who write this article is an idiot.
Do you have to insult someone for having an opinion?
Unfortunately many Mac fanatics (such as the guy above, though not all) take ANY criticism of the Mac as a personal offense and throw tantrums like this. It is nearly impossible to have a reasonable discussion with them.
I’ve never liked the global menu bars. I like how Windows and KDE does it by having everything in its own little window with no sharing going on of menus. The other thing that really bugs me about the Mac interface is how a program doesnt really take up the whole screen. With Photoshop, for example, on a Windows machine when you go full screen you have a grey background hiding anything thats open undernieth. On the Mac you see everything underneith and to me it just gets in the way.
If I hear someone once again quoting Fitt’s law I will go postal.
We mostly know about it. Some of us even read the papers, not just the fluff.
It’s a law as in “a formula that fits quite well the empirical data of a phenomenon _in given conditions_”. It’s not about menu bars nor about usability of computers gui.
Those who like global menu bars have it as a pro argument, as in “it’s faster to slam the mouse there”.
Ok. So a global menu bar is usually faster to aquire. That’s all Fitt’s law tells you. Is faster to aquire==better? I don’t think so, I think lots of other things come in play. Things like distracting the users, or giving good metaphores of the tasks at hand etc.
When I’m on my car I can speed much more than on bike, but it takes less time and effort to reach my working place at Uni by bike because there’s no parking lot for researchers. Thus, time for the task is a function of many other (complicated) paramters and external conditions, though time=space/speed is a “law” and it’s even more general than Fitt’s law.
So please debate all you want about why you think global/local bar is the bee’s knees, but stop with the silly idea that usability is a one-parameter formula.