OSNews

The question you should be asking is this: "why not?"

"""
The question you should be asking is this: "why not?"
"""

No. The question is "why?". Options should not be added to the UI needlessly. It must have a solid reason to be there.

I'm surprised that you, Eugenia, would look at it that way. I would have expected that including UI options without solid reason would go against your philosophy, as I understand it.

You're absolutely right. The reason is simple: I find it to be a UI enhancement. Changing the question to "why not" really makes a solid point. UI camps are divided on the issue, but it's a fairly equal division. It's times like that where having it as an option that's off by default is the best route.

The answer to "why" is very simple: because there are enough users out there that find it useful to warrant such inclusion as an option that's off by default.

"Why not" is brought up because so many are immensely and adamantly opposed and, quite frankly, for no reason other than that they don't particularly want it.

That's not to say that every option need be present in Gnome. This particular one, however, deserves a place.

1) Because if you put the menues in a OSX-like menubar, then the windows doesn't needs to have enougth width to have them in the window. If you have used Adium, you have like 7 menues, or even more, in the OS-X menu bar. The Adium window design only could have 2 or 3. Having menues in a separate bar separes the menues design from the GUI design.

2) Microsoft have tried to design an interface that has the same objective (make the menu bar disappear from the window UI), the ribbon thing. The Apple approach looks cleaner IMO.

3) Cleaner window UI, due to 1)

4) It's easier to find the menues that way, they are always on top of the screen

4) Since all the windows share the same menu bar, you save screen space when you've multiple apps opened.

5) You can use it as "system" menu bar. This saves you from using the app launcher to find the "shutdown" function.

6) Because Apple is the most usable OS, they really care about usability and there must be some reason why they do it (sorry for the weak reasonement but it's true)

Disadvantage: The menues are separated so it's not directly obvious that they're related to the app you've opened. It's ver very easy to get used to it, though.

Edited 2007-05-17 21:16

7) It's been proven to be a faster method of using a menu. It's late and I can't remember the reference though. By having it at the top of the screen you can just move your mouse upwards without having to target a specific vertical space. Because the mouse is bounded by the screen that small bar becomes, in terms of hand movements needed, a much larger area.

The usability gurus seem to love it but personally I hate it.

The question is "who chose to put application menus at the top of every window?" It's a waste of space.

Personally, as by now I have no doubt said many times here, I'm holding out for menus that disappear unless you click a mouse button.

I'm sorry, I think "why" is very much the better question. For the last few years, Gnome has put a lot of effort to stripping its applications of excessive options and advanced settings. Some people might not like this, but it seems to be working for them. There has been a lot of positive response to a FOSS desktop environment with a minimalist interface, sane defaults, and large focus on HIG. Thus, they have to be very careful about adding options that allow users to change the core interface of the Desktop Environment.

Why? Because some people prefer it that way. I don't, but I can understand that some people do.

He knows that. Assume he is asking why they like it better.

The question you should be asking is this: "why not?"

Please explain how that is a better question to ask??

why not. because when windows aren't maximized they are confusing. controls that work for a program are off of the window. AND on the window. which is weird. either have the controls ON or off the window. why both? it just makes it confusing.

it's not my way of working, and i wouldn't want it as default.. but why not just have it as an option? it's always nice to have options. Especially with something as often used as the main gnome bar. It's just one of those things that MUST be configurable so that it can please any user.

Because global menu bars suck on large screens or dual screens. They work very well on traditional screens but they have severe limitations on larger screen areas. It starts to take longer and longer to access the menu via mouse the larger the screen area gets. The global menu bar paradigm is failing now that technology is surpassing its usefulness.

To make the display even more non-cluttered and mainly to save space.

Menubars at the top of the screen are the pedagogical example of the utilization of Fitt's Law.

Fitt's Law is given by:

T = a + b log2(D/W + 1)

Where a and b are empirically-determined constants, D is the distance to the target, W is the size of the target in the direction of travel, and T is the time required to perform the motion.

(http://en.wikipedia.org/wiki/Fitts_law)

Moving the menubar to the top of the screen has the effect of increasing D*, but also has the effect of drastically increasing W (since overshooting the target is not possible), leading to an overall decrease in T. Fitt's law is particularly important for menubars, which tend to have a fairly small height, and thus a very low W unless they are at the edge of the screen.

*) By a moderate amount. It's likely that the tops of most windows are near the top of the screen anyway, so the increase in D is unlikely to be even a factor of 2.

I have a hard time believing that. It doesn't take into account that menubars for not active windows are hidden and require bringing them "up" which in reality places mouse about 10 pixels from place where classic menubar would be. If the app is not taking the whole screen the distance between area that you operate on and menu is quite big and grows annoying if you have to access it frequently. At least that's my impression after using OSX.

First, its a very well-established empirical equation in user-interface research. If you don't believe it, I presume you have some evidence to counter all the studies that have supported it?

Second, yes, it doesn't take into account that menubars for inactive windows are hidden, but that's beyond the scope of the equation. In anycase, if you're having to click regularly on the menubars of inactive windows, then there is something wrong with the design of your applications.

Third, yes, the overall distance of travel increases, but because the target gets larger, you can use a much sloppier (and much faster) motion to traverse it. That's the whole idea embodied in the equation: the less accurately you need to aim, the faster a motion you can use. Absolute mouse movement speed is rarely the bottleneck in clicking on a screen element. Rather, the bottleneck is how fast you can move the mouse while retaining the required accuracy, and that speed is *much* lower.

First, its a very well-established empirical equation in user-interface research. If you don't believe it, I presume you have some evidence to counter all the studies that have supported it?

I'm not that bored

Second, yes, it doesn't take into account that menubars for inactive windows are hidden, but that's beyond the scope of the equation. In anycase, if you're having to click regularly on the menubars of inactive windows, then there is something wrong with the design of your applications.

Wrong design? How about Gaim/Pidgin or other IM apps? It's perfectly reasonable to have main contacts windows and separate chat windows with their own menubars. And I'm usually running more than one application.

Third, yes, the overall distance of travel increases, but because the target gets larger, you can use a much sloppier (and much faster) motion to traverse it. That's the whole idea embodied in the equation: the less accurately you need to aim, the faster a motion you can use. Absolute mouse movement speed is rarely the bottleneck in clicking on a screen element. Rather, the bottleneck is how fast you can move the mouse while retaining the required accuracy, and that speed is *much* lower.

Neither this patch nor OSX moves toolbars with the menubar. Somehow I'm supposed to have a hard time clicking menus but for small icons it's ignored? I'm already focused on the app, menubar is there, it's not hard or counterintuitive to aim there.

Edit:
Is it me / my browser or are the OSn-v4 bbcode tags broken? I can't use multiple quote tags (only first and last one work) and italics tag looks strange o_O

Edited 2007-05-17 20:36 UTC

'Third, yes, the overall distance of travel increases, but because the target gets larger, you can use a much sloppier (and much faster) motion to traverse it. That's the whole idea embodied in the equation: the less accurately you need to aim, the faster a motion you can use. Absolute mouse movement speed is rarely the bottleneck in clicking on a screen element. Rather, the bottleneck is how fast you can move the mouse while retaining the required accuracy, and that speed is *much* lower.'

-- Great with todays monitors, but surely the problem you'll incounter when monitors increase in size is that the amount the mouse pointer can be moved is dictated by the space on the physical desktop for one to move the mouse in.

I may be able to move the mouse pointer 20 times or whatever faster because I don't have to aim at a target, but come the day I can buy a new better bigger monitor and several thousand pixels of space to traverse moving the mouse just once, no matter how fast, ain't going to reach the menu bar at the top of my huge display. Factor in the time taken to move my mouse to some space on my physical desktop so that I can 'push' the pointer upwards again and I've probably added time to what I'm trying to do.

Rather than clicking in the window then clicking the menubar inside the window, which is currently the default on Gnome?

Rimmer's Law 271 states just as clearly, "No chance you metal bastard."

Fitt's Law is for you and your fellow robots, a few fractions of a few ms saved aiming the mouse at a menu option only annoy those who have to repeat tasks ad infinitum: like machines. To people just editing documents, creating websites, reading the news and who aren't spending 24/7 online the time save by Fitt's Law isn't worth worrying about.

Edited 2007-05-17 20:00

Watch my parents trying to click a button or a menu item.

WATCH THEM. Have your stopwatch handy.

Then you will understand which dimensions in time Fitt's Law can be about.

I use Fitt's law to reach scrollbars all the time, and get *very* frustrated if they don't touch the edge o the screen. I think frustration by not being able to hit a button easily should be factored into your thinking.

Can you tag an english conclusion onto that so I know what you're talking about?

"Moving the menubar to the top of the screen has the effect of increasing [variable], but also has the effect of drastically increasing [other variable]"

What you're trying to say in a very mathematical way is that moving the menu bar to the top makes it easier to access it. But who says the menubar -- an extremely old UI paradigm -- deserves this level of attention? Why not move the toolbar up there instead, which contains the most useful commands for any given application, rather than every possible command?

I'd say if an application needs this focus on the menu bar, it's badly designed.

The menubar might be old, but then again, so is thermodynamics and classical physics. All are still around, well, because they're as useful today as they were decades or centuries ago.

Part of the reason for putting the menubar there instead of the toolbar is because the toolbar is already pretty large to begin with. The menubar, consisting of text, is much smaller and harder to target.

But who says the menubar -- an extremely old UI paradigm -- deserves this level of attention?

The menubar may well be an old concept, but there are programs for which it is vital.

Quick example: try to move all the functions OpenOffice has on the toolbar rather than in the menubar. It will fill up half of the damn screen.

The menubar and the toolbar have their own place in a GUI. The functions which are used so often that they should not only be readily available, but displayed in full view, are on the toolbar. The rest can be moved in the menubar, in a hierarchic structure (i.e the File menu will contain all operations related to files; the Export to... submenu will contain all the formats something can be exported to).

The "logical" trend is to find a way to keep a balance between them. Move everything that is not so essential that nobody should click a menu in order to find it out of the toolbox. Provide keyboard shortcuts for everything, and so on. All these come from one logical fact: windows are to display your work, not what the application can do. If an application has a toolbar with more than 10-12 icons, a reasonable maximum for one's short-term visual memory, it has too many and, in order for the user to find the relevant option, he'll have to hover the mouse over the icon to get a tooltip -- which ruins the whole point of having icons in the toolbar.

Then, you may ask, why do Windows and X11 programs have such a cluttered toolbar? I mean, compare, say, Kdevelop's interface (this: http://www.ellak.gr/pub/knoppel/shots/kdevelop.jpg ) to Xcode's: http://zovirl.com/2006/07/xcode_pics/xcode.jpg .

Quick answer: because accessing them from the menu became very painful.

Back in the days when the earliest Mac OS was conceived, the menubar was established for a good reason: screen space. On a 512x384 screen, having 12 16x16 buttons was already a lot of space -- not to mention that if a menu was longer, once placed in a window, there was a chance you actually had to move the window up in order for the damn menu to fit.

Later, with the advance of high-res displays, Apple didn't abandon the idea -- and for a reasonably good ideas: context menus and past habits.

It's a false idea that "everything" is concentrated in the menubar. Instead, the menubar contains (or should contain, in an ideal world of GUIs) only general, readily-accessible functions. For instance, if a function refers only to a certain kind of object (i.e. a Select Color item for a shape in a vector drawing program), it doesn't belong to the menubar, it belongs to a contextual menu you get by right-clicking the object..

The other important thing was that virtually all the audience of OS X was already used to having a top-screen menubar. For anyone switching fomr OS X to something else, it's an equal pain in the neck not to have the menubar up there.

With Gnome trying to implement it -- it's hardly a case of "shininess". There are a lot of people for whom that bar is the natural way to operate their computers. This is a good enough reason for implementing such a feature.

-------

Slightly uninteresting mentions.

The other reason behind that menubar is having to do with the idea of "closing" windows -- and the best example for me to show this is Gimp.

In many systems, including many X11 environments, the idea of one big window having all documents inside (i.e. Windows' MDI) is evil. Indeed, there are cases when you want to have several windows open -- in my case, for instance, it's having a look over a Python tutorial in Firefox while typing <something> in IDLE and having a window chat open just in case someone asks for me. On a 21" screen, it's no big problem for me, and I don't want one big window to force me to click on the taskbar when I want another one.

The application-window-and-menubar has one fundamental flaw with which a lot of new users are confronted (and which is why the MDI concept appeared in the first place). If the present application has many windows open on the screen, each with its own close button and menubar, which window should you close if you want to exit the application?. This is easy for each of us to figure, but for someone touching a computer for the first time, it's not. Furthermore, if there are a lot of windows on the screen and the one which, once closed, will quit the program, is hidden, one may have the surprise of exiting the application alltogether. The idea of "minimize" works fine -- but with Gimp's many-many-many windows, the whole things get so cluttered you can hardly find it once it's down.

In addition to this, if a window merely shows information, there is no logical reason for the application to exit completely just because a window is closed. What if I want it to continue running, but I want no window on the screen OR in the taskbar?

On OS X, every application is represented by its menubar. This is counter-intuitive for anyone coming from a Windows environment (i.e. how can an application run without any windows??) but it actually makes a lot more sense to a novice user.

How do you distinguish which window is currently "active" when there are more? It's subtle, I know, but OS X employs an easy way to do that: the shadow under the active window is more pregnant. It sounds as a little thing, but actually I've found it very easy for people who haven't used computers before to recognize it. The only obvious failure for this is that it won't work very well on a dark background, where the shadow is not visible. On a Gnome without beryl, compiz, xcompmgr or anything else that draws shadows it will be, indeed, confusing.

----

The bottom line is, however, that there are a lot of people who find a top-screen menubar easier. It's all about accessibility and usability. I know that Linux is a geek's toy (it's been my toy for years), but some tolerance for the modestly few who consider the top-screen menubar the better way would be cool to have. I am one of those, actually, even though I've used OS X seriously less than I've used Linux and NetBSD.

I apologize for the lengthy reply.

P.S. Lengthy as it is, I'll need to make a quick entry.

Fitt's and Hick's laws are both excellent theoretical models, in the way that they represent the easiest method of operation for someone who sees an environment for the first time. Basically, considering Fitt's laws, if you place an user in front of a screen he's never seen before, there are five places he will be able to reach without any kind of effort: the four corners of the screen and the pixel just underneath his cursor.

This is why a) the corners are used for things like Start Menus, Apple Menus, Hot Corners and system trays, while the pixel underneath is used for context menus.

However, if the user is already familiar with the screen, there are other places he can reach with very little efforts. These are mechanical automatisms, and the best example is the NeXTStep dock (note: not Apple's horrible dock). If a user has clicked a fairly large icon/button a lot of times, and the button has always been in the same particular place, clicking it again is effortless. The user no longer needs to have a deep look, find the relevant button and then click on it -- it takes him sensibly less time to find it.

In general, a badly designed GUI with which the user is, nevertheless, used, will seem much more efficient than one which is perfectly designed according to GUI design principles, but which is unfamiliar to him. Virtually all seasoned Windows users will seem lost when using OS X's interface (OK, their dock IS bad) or, even better, NeXTStep's (if they find any around), without actually realizing that, by any meaningful GUI design principles, the Windows desktop is a disaster.

Edited 2007-05-17 23:13

Quick example: try to move all the functions OpenOffice has on the toolbar rather than in the menubar. It will fill up half of the damn screen.


That's why Office 2007 uses a ribbon.

Maybe that's the direction Gnome should take for apps with many functions.

Microsoft got it right more or less (yes, yes, you may shoot me now http://en.wikipedia.org/wiki/Image:Office07homestu.png

In Office 2007 you can more or less create your own toolbar with the stuff you really need in the titlebar (+the file menu).
Those buttons are
a) easy to reach if the window is fullscreen, thx to fitt's law
b) but avoid the problem where you have to first move your mouse to a window, activate it, then move back to the top of the screen for the menu bar.

This behaviour is optimized for apps you generally use maximized and reduce in size only when you switch windows often, which more or less is exactly how most people use office apps.

Of course MS snatched defeat from the claws of victory on the UI front with Vista. There the toolbars are all over the place, and the menus, lists and sidebars, panels, buttons at the bottom, top and on the backside of your monitor. When MS started to copy OSX someone should have told them that iTunes isn't the best place to start...
Oh, and KDE's and XP's control panels are a triumph of usability compared to Vista's.

I'd be really interested in a DE where the office UI was used consistently for all apps. I suspect it might not work quite as well for some kinds of apps, but overall it's the best alternative to the old menus+toolbars paradigm that I know. (well, apart from the the elegance and simplicity of the CLI of course =)

I haven't used Office 2007, but the screenshot seems familiar to me in terms of UI elements. Is that toolbar any different from a tabbed toolbar?

If so, these things already exist, and while they are useful (i.e. they can accommodate more options with less screen space), they fail to solve another problem. The reason why toolbars with many items are of limited efficiency is that there are only so many items a user can remember visually. Basically, if the user has to hover the mouse over the toolbar to get a tooltip, the whole point of the toolbar is lost -- it becomes just as efficient as a menu, only with more sugar.

I agree with your comments about Fitts law, but global menubars break basic UI design. The application menus belong to the application and not to the screen/desktop.

It's not my place to say which set of laws should win, but there is a conflict between them here.

It should be noted that in the Mac paradigm, windows belong to applications, which exist independently of windows. The menubar is the central representative of the application as a whole, so it makes sense to put application-global functionality in a place separate from any window. Most other UIs conflate applications and windows in a way that the Mac UI does not.

And that made beautiful sense when we had a single-tasking Finder. I liked it, anyway.

That is true. If you had a system with a large number of multi-window applications, that system would do well with the Mac-style menu bar. Windows and Ubuntu are not such systems, however

but then you dont have the funny experience of closing every window and still have programs running.

i would love to toss the whole idea of programs. rather make them into plugins or extensions tied to file types.

if i have a file type open, said plugin is loaded by the system. when no such file type is active in any window, toss said plugin away for now.

today one have to all to often link file types with programs to get anything done...

I've been a Mac user since 1987 and I used to quote Fitt's law and all the other standard reasons for having a top menubar. Then I actually tried timing my response and others to a request to find and click on a menu item under Mac OS X and Windows. My experiment found that having the menubar at the top of the screen made no measurable difference. My observation was that most of the time isn't spent positioning the mouse (the part Fitt's Law applies to), but recalling which menu to select and finding a menu item. Menus are not as efficient UI elements as buttons in terms of time to action, Fitt's Law proves this, and so you gain nothing by putting menus that change per-application at the top of the screen. My theory is that the top menubar is a hold-over from the original design before the Mac could run more than one application at a time, then it made a lot more sense and Desk Accessories had no menubar probably for this very reason. I don't think Apple revisited the menubar when they were forced to implement the MultiFinder to stay competitive.

GNOME uses mostly static buttons (with the exception of three static menus) in locations positively effected by Fitt's Law. GNOME has correctly applied Fitt's Law and Apple hasn't in this case.

"""
Then I actually tried timing my response and others to a request to find and click on a menu item under Mac OS X and Windows. My experiment found
"""

Your empirical approach is refreshing. :-)

Uh, the word your looking for is "anecdotal".

Anecdote is what you use when you don't have a good empirical rule. Empirical rules are, in turn, what you use when you don't have a good theory.

Since we have a good empirical rule in this case, excuse me if I'm not readily willing to abandon it in favor of anecdote...

It has been proven by real world testing time and again that what you're saying is infact true. The gain from using Fitt's law is lost by having more then one application on the screen and having to refocus the mouse to the application after you got it so far away from the application. The fact that you're saying its the same time alone is a bit inaccurate.

to prevent Microsoft form saying that GNOME violates there patents for the look of menus

Edited 2007-05-18 01:37

Fitt's law doesn't seem appropriate for 2 reasons:

1) If an action is frequent enough that efficient access is needed, it would be placed in the toolbar of the application window.

2) Menubars require 2 clicks to activate an item. Any speed gains from opening the menu is lost in finding the menuitem, after the menu has opened.

When people apply Fitt's Law to mouse distnace, they often forget that distance on the screen is not one-to-one with distance of the mouse.

There is a region around your pointer that does not require you to move your wrist, and is thus very easy to mouse to. Mouse acceleration makes this region larger, but usually not large enough to cover the entire screen. There is a region surrounding that for which you need to move your wrist. And there's a region surrounding that for which you need to pick up your mouse, move it, set it back down, and move it some more on the mouse pad.

Obviously, where each of these regions lay depends on your screen size, mouse acceleration settings, mouse skills, mouse pad size, and other factors. Nonetheless, most people can't hit their entire screen without at least moving their wrist. I can hit a little over a quarter of my screen without moving my wrist.

What's more, other types of input devices (track balls, touch pads, stupid little nipply things) have different ways in which the input device motion does not map one-to-one to screen motion. And touchpads, at least, are fairly common devices, since most laptops are equipped with them.

None of this is to say that the spirit of Fitt's Law is bad. It's just that with modern screens and input devices, the screen corners aren't quite as magically easy to hit as the too-simplistic Shannon formulation might suggest.

Im currently on a laptop trackpad, at 1440x900 resolution, and i can go from the very bottom to the very top of the screen with two full swipes accross the trackpad.

The idea behind the global application menubar streaches fittes law a bit, it is that you only have to aim in two directions, instead of four. That means you can "throw" your mouse up to the top of the screen with reckless abandon, secure in the knowledge you will alwas hit your target. Then it is a matter of left or right. Menus in applications require you to slow down your mouse movement as you approach the (roughly) 20x30 pixel target. While you could argue that because of modern resolutions, application level menubars are equivilent in speed to the global menubar, due to the aiming in only one direction, and the consistant fixed location of the widget, the global bar will alwas take less effort to use, which leads to a more pleasent experience.

Fitts law is a bunch of bollocks quoted by usability experts to try to make what they do sound scientific. Any change that requires quoting Fitts law to justify is generally a bad change.

People don't spend most of their time hunting for the menubar so shaving a fraction of a second off the time to find it is pointless. Doubly so if the change forces people to work in a new way that they are uncomfortable with.

For applications with large windows, where the top of the window is close to the top of the screen, on a single monitor under 1280x1024 in size, I can see this being true.

For applications with small windows (like IM programs), or on computers with multiple monitors, or large monitors (1600x1200 for example), separating the menu from the active window makes things harder. Especially if the menu always starts on the left monitor, and you are working on windows in the right monitor.

As with everything, there are times when one way is better than the other. Making it a togglable option is good. Forcing it on users is not.

Anyone using multiple monitors on MacOS X care to comment on it?

Because menu-bar usage is common. Instead of carefully aligning a cursor where it goes, you can just flick it upward.

thats to hit the bar in general...

but then you have to find the specific menu you want, and the entry in said menu.

keyboard shortcuts for the win

How would that work if you have an app open on monitor 2, and the global menubar starts on monitor 1? Going straight up doesn't hit anything but empty space.

The usability studies for this particular concept were done decades ago. The Wikipedia article I referenced shows that Fitt's Law has been shown to have a correlation of 95% in hundreds of studies conducted since the mid 1950s when the law was introduced. The menubar application is one of the fairly rare instances in psychology when the result falls very neatly out of a very simple and well-supported equation.

2 words: bad idea. and like the first guy said, people are requesting it because osx has it. show me usability studies first...

I can come up right now with Fitt's law http://en.wikipedia.org/wiki/Fitts_law . While it may not be a usability study per se, I agree with the conclusion that a menubar on the top of the screen is easier to reach than a menubar in a window. The only thing I have to do to reach the menubar is kick the mouse to the top of the screen. That requires less coordination than reaching a menu item in the middle of the screen.

but you still have to find the part of the menu that you want...

look before you jump, grasshopper

and anyway, it "cant" work on X because it would require all toolkits to support it. it would be a major usability problem to have have applications supporting it and applications not supporting it at the same time.

KDE manages fairly fine with it. GNOME+this patch as well, especially taking into account this patch is done and maintained by one single guy.

True, but even in KDE it only works for other KDE (do plain QT apps work?) apps. Having GNOME and KDE interoperate in single menu bar mode would be good, but the other random toolkits will still not support it, making the UI more inconsistent across toolkits than it already is. :-(

Yes, it works very nicely indeed with both KDE and Gnome applications.

http://img519.imageshack.us/img519/6160/gnomeob8.png

http://img374.imageshack.us/img374/1056/kdeoi6.png

Yeah great if you only have a single screen i suppose. But this would be a nightmare for multi screen users!

Why? If the patch is extended for multi-screen purposes, GNOME has a chance to do something better than Mac OS X: One menu bar per screen, that changes depending on the last selected app on that screen.

But the reason the single menu bar approach works so well on the Mac, is that you almost never need to access the menu. Which is how applications should work. Menus should provide the full palette of functions that a program performs, but frequently-used functions should have both buttons and shortcut keys, so the user only needs to go to the menu in case she wants to do something out of the ordinary.

Menus are extremely bad usability-wise. They are, in fact, the worst invention since software patents. They require immense mouse precision, are hard to find your way through, are very unintuitive, and worst of all they treat all actions as if they were equal. They're not; some are performed more often, others almost never.

Mac OS (X) has relied on shortcut keys for many years, and has achieved great consistency in this regard, thanks to the Apple HIG (and similar projects). I am unsure whether GNOME applications have reached a similar level of consistency, as to enable this kind of UI-enhancement. It is only a good idea to get the menus out of the way if you only need them rarely.

- Simon

I love the KDE Global App Menubar and use it. If I were able to use my GTK apps with the menu at the top of the screen, I would certainly use more Gnome/Gtk apps. In fact, for awhile now, the ONLY reason I haven't been using Gnome is because of the lack of a Global Application Menubar. I always felt that it was odd that they didn't have one, since the Gnome team seems to pride itself on being the more "Mac-like" of the linux DE's.

I agree, having had to use macs at uni, I think the one menu bar approach sucks. If I have several windows open and I want a particular option, I can go straight to it because I can see it even though the window is not the active one. With macos you must first select the app and then wait for the menu and then select the option.

Maybe if you running everything full screen it could be automatically enabled, otherwise it is autom