The Problem with Global Menu Bars
OSNews recently ran the piece “The Problem with Global Menu Bars” in which the author criticizes the usability of global menu bars (“ala Mac”). I would disagree with almost the entire article, and find most of the criticisms to be based on a Windows-centric mindset notably lacking an understanding (or basic knowledge) of the Mac HIG.
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.
This sort of thing just bothers me. So I’m going to take a cheap shot, and run down the points made in the article. I’d write the author, but he conveniently didn’t attach any contact information to his article.
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.
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.
This is based on what I would guess is mostly a power-user’s way of using applications. Toolbars are just as error prone due to their similarly small size (not just narrow in one dimension, but often in two dimensions), and have similar issues of being potentially disconnected from the application’s window that menu bars do.
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.
This is based on the Windows-centric view of an application as the fundamental object, not the document. Toolbars aren’t always connected to the “Application” (which I’m guessing is meant to mean the application window — another Windows-centric view); In fact, on the Mac, they’re often their own windows.
The “quick way to tell without thinking which application the menu is functioning for”, at least on OS X, is by looking at the first menu, and reading the application’s name.
3) Global menu bars don’t work with focus follows mouse.
A feature that has it’s own world of usability problems, and is a power-user feature. I haven’t used a focus-follows-mouse interface in some years, but I’m pretty sure that if you were using the menu, the application would move to the foreground.
4) Global menus don’t work well with multiple monitors.
This is a valid point.
6) Widgets must be dynamically changed. You essentially have a moving target.
I’m really not sure what this is supposed to mean. Maybe that menu items change as you change applications? If so, they do change, but the moving target criticism is offset somewhat by the infinite size of the menu bar due to Fitt’s Law.
Comments
My fundamental biggest concern with global menu bars is they are wasting the most accessible screen space. Lets think about how applications are used. In a typical application, menus are hardly ever used with the mouse. This should be plainly obvious to most users. I would go as far as saying days are common where I do not use menus for any applications on my system, why is this?
1) The commonly used functionality of menu bars is duplicated elsewhere. Menu bars are essentially a collection of commands, and any of these that are commonly used are placed elsewhere. When is the last time you executed the back or forward actions in your web browser from a menu? You likely won’t because you have keyboard shortcuts, toolbars, mouse gestures, context menus and an assortment of faster ways to do the task. How often do you copy and paste from the edit menu? Most people wouldn’t preform this action in such a manor for the same reason. What you end up with is the menu bars being used to execute the less common commands; in the web browser example, you might use the menu bars to open a file from your hard drive or get help. When you only use the menu bars for uncommon tasks, the menu bar becomes uncommon to use.
2) Menu bars are slow to navigate. Menu bars have a lot of information - they usually have all the commands of a program and you have to read a lot to get to the information you are after. Menu bars are usually stateless and thus they frequently show a lot of information that is irrelevant to the current context. Regardless of where the menu bars are located they will be slow to use because you have to sift through too much information.
I am arguing that menu bars are infrequently used, not that they are unimportant. It is very important to be able to do tasks like edit preferences or get help, its just something that isn’t done very often.
The top edge of the screen is a very accessible and very important part of the screen. Because of Fitt’s law, all the edges of the screen are easy to access fast. On top of this, ergonomically speaking, the monitor should be centred slightly below eye level meaning that the upper parts of the screen are closer to the eyes than the rest. Combine these two facts and you realize the top edge of the screen is incredibly important.
I do fully agree it would be faster to get to menu bar if it was placed at the top of the screen. What I do not agree with is that placing menu bars at the top of the screen leads to an overall faster experience. An application’s menu bar is uncommonly used, so why place it in such a prominent location on the screen? I would argue that there are more important things that we could put there. By keeping the menu bar with the task, you free up some of the most important space on the screen (the top edge) and use up an amount on each window that is irrelevant in todays world of decently sized monitors. By putting something that is used uncommonly in a very accessible spot, you are wasting that space.
Posted by: Steve on April 21st, 2005 7:58 PMThis is based on what I would guess is mostly a power-user’s way of using applications. Toolbars are just as error prone due to their similarly small size (not just narrow in one dimension, but often in two dimensions), and have similar issues of being potentially disconnected from the application’s window that menu bars do. No, not just power users know how to use the back and forward buttons on their web broswer, or know how to copy text using context menus or keyboard shortcuts. Virtually everyone does these things because it is dramatically more efficient.
This is based on the Windows-centric view of an application as the fundamental object, not the document. Toolbars aren’t always connected to the “Application” (which I’m guessing is meant to mean the application window — another Windows-centric view); In fact, on the Mac, they’re often their own windows. Safari has the toolbar attached to the window, yet the menu bar at the top. If we are trying to seperate the document from the application, wouldn’t it make sence to make both be not attached? Many other applications like Quicktime fucntion the same way. What you have when some toolbars are not attached, yet some are is inconsistant and confusing.
The “quick way to tell without thinking which application the menu is functioning for”, at least on OS X, is by looking at the first menu, and reading the application’s name. First of all, this is a lot more thinking for the user than attaching it directly to the window. Secondly, this leads to the problem of when you switch from an application who’s name is short to an application who’s name is long you end up with the menu bar in a changing location. Minor issue, but still more confusing than if it were to stay in the same place.
A feature that has it’s own world of usability problems, and is a power-user feature. I haven’t used a focus-follows-mouse interface in some years, but I’m pretty sure that if you were using the menu, the application would move to the foreground. It is a thing of preference, getting rid of it really isn’t an option - desktops like GNOME allow it because it is still very popular among power users. What would happen if you are using an application in the bottom corner, and you had to get to the top corner? Every application you would cross over would take away the focus and that would make it very hard to get to the menu for the right application.
Posted by: Steve on April 21st, 2005 8:15 PMI respect your position, but feel that most of it is based on the perspective of a power user, which the vast majority of computer users are not. I would assert that the vast majority of users have never gone “days” without using the menu bar. It is only “plainly obvious” to you because it’s difficult to imagine a world where people wouldn’t use toolbars and key combinations in place of the menus that is how you use a computer.
Certainly there are situations where you almost never use the menu-version of certain commands, such as the back and forward buttons in a browser. However, many people do use the menu bars for commands which you and I would always choose a shortcut method for. I can think of several people within my own family and closest friends, who range in menu-use from “almost entirely” to “relatively often” with toolbars and (more rarely) key commands taking up the slack.
Menu bars may be slow to navigate, but not dramatically more-so than some toolbars. I’m thinking particularly of some Microsoft products where it seems the UI designers felt it necessary to put as much functionality as possible into the toolbars, and ended up with a mess of icons that was only navigable through forced repetition. In either one, you’ve the need of precision ability with the mouse, except that the menu-bar will generally give you a wide (though short) target whereas the toolbar will give you a narrow and short target.
As to the question of “why place [the menu bar] in such a prominent location on the screen,” I’d suggest that the prominent edges of the screen are the only sensible place for menu bars. If they are commonly used, as I suggest, prominence (with help from Fitt’s Law) is important, and if they’re not, as you suggest, then they’ll be wasted no matter where they are, and with the current WIMP interfaces, nothing else of much importance is going to replace that thin strip at the edge of the screen (The window title? Another menu bar attached to a full-screened window?). I’m not sure what you’re envisioning using that “most important space”; a menu-bar seems ideally suited to fill a thin strip of monitor real estate, and I can’t think of any other interface element that could fill a similar space with anywhere close to the same power/size ratio.
Posted by: kasei on April 21st, 2005 11:07 PMYou have some valid points, but I would go as far as blaming the situation on poor UI design. I would say that we all pretty much can agree that menus are typically the slowest way to preform a task provided it can be preformed in another fashion (see #2 above). Ideally people then would avoid menus, but you are right, in certain applications many people don’t. Lets make some simple observations:
-Even non-power users avoid the menus for certain applications. Browsers, media players, and plenty of other applications fit under this category. -In applications like Word, the use of menu bars is far more common. -In applications like Word, you do see most users using certain UI elements like bold. -I personally find myself using the menu bars in Abiword far less than the menu bars in OpenOffice.org or Word (despite the fact that Abiword has a lot less in the toolbar).
I would blame most of these observations on poor UI design. I would say an application that is used the least is well designed. By this I mean that an ideal application allows you to get your work done the fastest and get out of the application without getting in your way. Because menu bars are fundamentally slower than other UI elements, minimizing menu usage can go a long way to speeding up application usage. I would offer several suggestions to minimize menu usage:
Posted by: Steve on April 22nd, 2005 12:57 PMSorry for the double post…made some mistakes… You have some valid points, but I would go as far as blaming the situation on poor UI design. I would say that we all pretty much can agree that menus are typically the slowest way to preform a task provided it can be preformed in another fashion (see #2 above). Ideally people then would avoid menus, but you are right, in certain applications many people don’t. Lets make some simple observations:
-Even non-power users avoid the menus for certain applications. Browsers, media players, and plenty of other applications fit under this category.
-In applications like Word, the use of menu bars is far more common.
-In applications like Word, you do see most users using certain UI elements like bold.
-I personally find myself using the menu bars in Abiword far less than the menu bars in OpenOffice.org or Word (despite the fact that Abiword has a lot less in the toolbar).
I would blame most of these observations on poor UI design. I would say an application that is used the least is well designed. By this I mean that an ideal application allows you to get your work done the fastest and get out of the application without getting in your way. Because menu bars are fundamentally slower than other UI elements, minimizing menu usage can go a long way to speeding up application usage. I would offer several suggestions to minimize menu usage:
-The interface should be simple, and not overwhelming. In your web browser or media player there really is only a few buttons and it is easy to tell what you can do. In most office applications you have several dozen commands. In these applications with more commands there is no way you will be able to look up at the toolbar and see everything that is available to you. When you don’t know you can do something easier you will do it the slower way.
-It should be obvious what the icons in the toolbar do. In my media player I understand what play and stop do, but in most word processors there are dozens of funny buttons that at a glance do not make their functionality obvious. I think that if you have many icons in your toolbar that do not have obvious functionality turning on text labels by default might be a good idea. If you cannot fit all the buttons on when you have text labels turned on, perhaps you have too many buttons.
-Provide a relevant and short context menu. The context menu should vary based on context - that is when you right click in different places it should provide commands relevant to where you clicked. If you do this right you will have a short list of the most common commands for an object. It is important that it is short so you may see everything you can do right away.
-Dynamic toolbars are bad. Applications like OpenOffice.org provide toolbars that change dynamically based on content and this just confuses me. Its important to be able to trust in the interface.
-Allow customization of the toolbar. I believe the toolbar should contain only the minimal functionality by default (as not to clutter the toolbar) but customization should be available to allow you to custom the application to your needs. Lets look at Abiword, how often do you work with documents that have three columns? Even if you regularly make three columnar documents, you will only need to execute this command once per document. Why is there an icon for it in the default toolbar then? There are of course some people who do regularly make such documents so they should be able to add this to the toolbar if need be, but it should not be there by default.
Again, I believe the ideal application should allow fast usage and menus will slow you down. I believe that better design can reduce menu usage for both power users and new users alike. Well designed, uncluttered toolbars with decently sized buttons should be dramatically faster to navigate than menus. Once again, I do not think menus are unimportant. I believe they are very important, just that they should ideally be used infrequently. I think that minimizing menu usage is a realistic possibility and so keeping the menus around within the windows is a better choice than placing them at the top of the screen because that is prime real estate.
Posted by: Steve on April 22nd, 2005 1:02 PM
I commend you for showing me up and try to reason out against what this guy says. You are better than me cause I’m just gonna lable this guy a “stupid mac-hating hoor” and be done with it.
I don’t know, I’m finding that there are people out there who find one way of doing something easier than others. Personally, I love menu bars because I always know exactly where I need to go to get to my options for what I want to do. It also makes the window a helluva lot prettier and you can’t make the window too small to see all of your menu options on accident so there’s no “>>” button to see what the rest of the menu holds.
Of course this dude’s brain probably is built somewhat differently than mine and he probably “gets it” on a non-global menu bar system where I would be irritated to no end.
Sara “my compy is prettier than your compy” Armstrong
Posted by: quasarsglow on April 19th, 2005 12:00 PM