This is a response to the previous article on global menubars and why they are the preferred way to present menus as opposed to attaching them to floating windows.1.) They place unwarranted emphasis on menu bars.
On the contrary, emphasis on the menu bars is fully warranted, as these are where most of an application’s commands are listed. Menu items are the visual step up from typing input to the program directly and are nothing more than commands sent to the application. Because an application can contain so many commands, in a graphical environment the only logical place for these commands are in pulldown menus where they can be selected and executed. The only other locations for an application’s commands are in right-click contextual menus which hides functionality from the user, or displaying commands as a row of buttons on a toolbar which leads to monostrosities like Microsoft Office’s 20+ button extravanza. And the more toolbar buttons there are, the smaller they must be to fit, making them harder to hit with the cursor. Confusing and difficult to navigate.
It is hard to argue that a menubar shouldn’t be one of the most emphasized user interface elements as it is used the most often, and contains the application’s full command list.
2) A global menu bar is disconnected from the task at hand.
The global menu bar changes functionality based on which window has top focus, so it is always connected to the task at hand. If I click on an iTunes window behind Safari, iTunes will come to the forefront, the bolded application menu will read “iTunes,” and the menu items will change.
This is more of an issue regarding simply getting used to the location of the menubar. Mac users have no complaints about this feature. The global menubar is as attached to the topmost window as a floating menubar is; the location is simply different.
3) Global menu bars don’t work with focus follows mouse.
A lot of things don’t work with the focus-follows-mouse model. The issue of focus-follows-mouse is another discussion, and as few desktop environments are set up for this method of user input, there is no reason to address it here.
4) Global menus don’t work well with multiple monitors
The previous article stated that there were two options–have the global menu bar exist on the first screen, requiring the user to move the mouse to the first screen to access it. This is no different from attached menubars. For instance, Adobe Photoshop on Windows allows you to have its child windows situated on the second monitor. However, the parent window still contains the menubar, forcing you to move the mouse to the screen where the parent window is situated. The problem is no different.
The second option described was to have a seperate menu for each screen, which was “more efficient but just as confusing.” It’s unlikely a user equipped with a dual-monitor setup would be confused by this option, and at the least it is an option for the user to have, unlike floating menubars which are always attached to the parent window regardless.
5) This really only applies to GNU/Linux and Unix desktops, but having a global menu bar would be inconsistent.
This issue has nothing to do with the merits of global menubars themselves and everything to do with the human interface standards of the given platform. Any given interface model could be argued as being inconsistent on a platform that allows you to customize every given interface model.
6) Widgets must be dynamically changed. You essentially have a moving target.
I wasn’t sure what the author meant by this statement, and because systems like OS X have no dynamically changing widgets, and the Amiga had a fully skinnable GUI and a global menubar, I won’t address it. If the author was referring to the fact that the locations of menu items on the menubar change when you change focus to another application, the point is again moot because this is no different from changing focus in a floating menubar scenario where each application has a different menubar of its own. Each floating menubar is its own moving target, attached to the floating window and rarely in the same location.
Global menubars are simply another method of user input, and certainly a floating menubar may be preferred by those who have grown up with them. Having started computing on a Windows machine long ago, I too was introduced to GUIs through the floating menubar model. However, after I used a Macintosh, I came to prefer the global menubar model.
Mac users who are sat in front of Windows machines often shoot the mouse past the floating menubar and have to readjust their cursor. This is because Mac users are accustomed to driving the cursor up to the top of the screen and hitting the menu they want, which effectively has an infinite width due to being on the screen edge. A floating menubar requires the user to slow their hand and pinpoint the menu because there is no stopping point that prevents the cursor from missing them.
Usability studies have in fact been carried out comparing various platforms, and floating menubars were found to be slightly slower than global menubars (this point may be moot for users who simply use keyboard shortcuts regardless). Global menubars were generally regarded as easier to find as well because their location was static no matter the location of the application window, and there’s no way to drag any part of the menu off-screen and obscure it as with floating menubars.
Many people incorrectly assume that the global menubar of OS X is a holdover from the days of the original single-application MacOS, ignoring other multitasking systems like AmigaOS. There is also Fitt’s Law to consider. The fastest access points on a computer screen are the edges, particularly the corners. This explains Mac user behavior described above when they would drive the cursor up to the menu as fast as possible instead of slowing down to target as Windows users do. Global menubars also free up slightly more space for the main application windows, and they act as a convenient access point for other global information like the clock, speaker volume, recently accessed documents, and system preferences.
There are a lot of interface models out in the wild. But there is nothing inherently wrong with a global menubar; in fact, it has several advantages over the floating menubar system. In the end, it is up to user preference and what that person is accustomed to.
About the author:
I am an author at Slackers Guild and use a Linux system, two Windows PCs, and two Macs.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.