GNOME 2.8.3 has been released: This is the third and last maintenance release of the stable 2.8.x series of GNOME and it contains a huge amount of bugfixes and other improvements since the last release. Elsewhere, a user is discussing the things that annoy him about Gnome.
GNOME 2.8.3 released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
http://shots.osdir.com/slideshows/slideshow.php?release=234&slide=1
Global Menu Bar… I am all for that!
Well… at least as an option.
BTW, (IANAD: I am not a developer) seperating out the menu bar in GTK a la Qt may be profoundly helpful in porting GTK natively to Mac OS X.
I agree with every point that this blogger wrote about Gnome. While some features seem less important to me (hing files etc.), they’re all good things, and what especially annoys me is Nautilus telling me to right-click and select “unmount” when i drag volumes to the trash. While it is a perfectly valif argument that dragging volumes to the trash is not a logical representation of removing a device, it’s totally the wrong way around if my computer tells me how to do stuff.
Was this done first on Mac or Amigas?
Still haven’t fixed the logout delays?
The Mac menubar is absolutely awesome. It’s awesomeness knows no bounds. Given how much the GNOME HIG has been influenced by the Mac one, I’m surprised there isn’t a bigger push to adopt the feature.
it was done _better_ on macs
first? dunno.
KDE too is discussing to improve and use the “Global menu bar” concept found in MacOs X [1]. Maybe that will lead to a more unified look between the two desktops? Let’s hope so =)
[1] http://lists.kde.org/?l=kde-usability&m=110886510119868&w=2
Oops. Wrong link.
[1] http://lists.kde.org/?l=kde-usability&m=110875901921158&w=2
I’m wondering.. all of these people that want a menu bar like in the Mac OS-es… do they want it because they want to make their desktop look as Mac(tm) as possible? Or do they really want it because of the _functionality_ ?
It’s subjective. With a large high-resolution monitor, each window having its own menu bar doesn’t take up too much screen real estate. At a smaller 1024×768, it can save space to have one menu bar at the top.
Hmm… being a *nix minimalist type, I guess I should prefer having one menubar at the top rather than all the redundant duplication of each windowed app having its own menu bar.
Rayiner, I like your description of the Mac menu bar’s awesomely awesome awsome-tacity.
Whoops. Hang on a sec… Are we talking about Gnome having a universal main menu bar at the top of the screen for “File”, “Edit”, “View”, etc.? Looking at the screenshots, I now see that that’s not what Gnome seems to have.
Please excuse my ignorance of Gnome; I typically only use IceWM these days.
Problem with the “annoyances” that the author points out are mostly problems with the OS and not GNOME. Do people think that GNOME only runs on Linux? It doesn’t. It runs on lots of operating systems. ACL manipulation, filesystem metdata attributes are too OS specific right now for GNOME to support for the most part.
Some of his complaints are subjective annoyances, i.e. something he cares about but not necessarily what someone else cares about.
No! Please don’t polute GNOME. Just because Mac does it doesn’t mean we have to. It is not nearly as useable, i like having menus near my cursor, and a global menubar means more wrist movement.
I am against the Mac-like global menu bars. The concept is unpopular with more than 90% of computing using population. A general principle is designing user interfaces is never to surprise users. An overwhelming proportion of the people who will be using GNOME are Windows users, not Mac die hards. Hence, the global menu bars should be avoided in GNOME.
There is a great deal of research showing that the extra wrist movement caused by having the menubar at the top is greatly offset by the fact that you don’t have to be as precise to hit the target. Studies show that Mac users can hit the right item 5x faster than Windows users, because they can move their mouse much faster without fearing overshooting the target.
But how productive are users when they start using multiple monitors if they were stuck with the single menubar on the top of the screen? At the moment on OS X, the menubar remains on the primary monitor and this makes working with multiple monitors a pain since you need to move the cursor back to the primary monitor to access the menubar.
The single menubar paradigm may be beneficial if you’re running one monitor at a relatively low resolution (e.g. 1024×768) but if you’ve got a large screen and multiple monitors, it becomes a hindrance.
Show me this study.
is a waste of space and that means no more fitt’s law for the “close” button in window. Sorry, but I like my menus usable
Rayiner, the only research on that topic that I could find is a single experiment conceived and executed by Bruce Tognazzini when he was at Apple (and that must have been what, 20 years ago? ).
Do you have any other pointers?
> the only research on that topic that I could find is a
> single experiment conceived and executed by Bruce Tognazzini
> when he was at Apple (and that must have been what, 20 years
> ago? ).
Yes, evolution should have made man a better mouse aimer by now… Seriously, it has to do with the infinite height of widgets on the edges of the screen.
> that means no more fitt’s law for
> the “close” button in window
Wow, you close windows more often than you are using the applications menu?
Another vote for it but as a configurable option.
> Seriously, it has to do with the infinite height of widgets
> on the edges of the screen.
Of course, if you have more than one window open, you first have to click the title bar of the window you wish to see the global menu before you can use Fitts Law. One step (just clicking the menu) becomes two steps (click the title then navigate to the global menu). It sort of defeats the purpose.
It’s important to use the right methodology for the right circumstances. You don’t wear a parka in the middle of the Desert.
Fitts law was designed for a time when you only ran one app at a time and your monitors were low resolution so that moving between the global menu back to the app was a relatively short distance (once you’re in the global menu, you’ll likely want to come back). It still works well for PalmPilot devices, but it’s not as useful on the modern multi-app high-res desktop.
Let’s be systematic about this
At the moment on OS X, the menubar remains on the primary monitor and this makes working with multiple monitors a pain since you need to move the cursor back to the primary monitor to access the menubar.
That’s more a fault of OS X’s implementation, than the global menubar concept. In any case, 99% of users are never going to have multiple monitors, so throwing out an otherwise powerful concept for the minority is silly. It’s true that monitors are getting larger, but because of mouse acceleration, a 21″ monitor is not much larger in mousing distance than a 17″ monitor.
is a waste of space and that means no more fitt’s law for the “close” button in window. Sorry, but I like my menus usable
It’s strictly a savings of space. The surface area used by the menubar is less than the area saved by not having a menubar in each app. There is no way to get a loss of space using the global menubar, unless you’ve got a window in which the top is offscreen. And not having Fitt’s law for the “close” button is only a loss if you use the close button on full-screened windows more often than you use menu items in general. That’d be a very odd usage pattern!
Rayiner, the only research on that topic that I could find is a single experiment conceived and executed by Bruce Tognazzini when he was at Apple (and that must have been what, 20 years ago? ).
Fitt’s Law is a very highly developed HCI theory. Numerous studies have backed it up, and they show that the mathematical relationship Fitt derived is accurate to a high degree of correlation. The utility of the global menubar derives logically from Fitt’s Law, so studies with menubars themselves are not necessary.
Think about it: a menubar is something that is almost always accessed using a vertiical mouse movement, and is very narrow in that direction. If small things are hard to hit with the mouse, as Fitt’s Law says, then the menubar is pretty much the hardest thing to hit in a GUI. Making it bigger (which is what putting it at the edge does), is thus a net win.
There is a good site about Fitt’s Law, with pointers to articles:
http://www.answers.com/topic/fitts-law
Of course, if you have more than one window open, you first have to click the title bar of the window you wish to see the global menu before you can use Fitts Law.
Now that’s an odd usage pattern. Hitting a menu item in a window that’s not currently selected. Who actually does this, instead of clicking on the window to focus it, then going to the menubar anyway. More importantly, do they do this often enough to outweigh the gain of the global menubar in the general case. Remember, GUI design is all about making tradeoffs, and optimizing edge-cases is rarely a good tradeoff.
One step (just clicking the menu) becomes two steps (click the title then navigate to the global menu). It sort of defeats the purpose.
Mousing time greatly outweights clicking time. With the global menubar, you’ve got two clicks, but on two enormous targets (a window, and an infinite-height menu item). It’s likely to still be faster than having aiming at a tiny menu item. Remember, HCI research suggests a 5x improvement by putting something at the edge. Two or even three motions of 0.1 sec are preferable to a single motion of 0.5 sec.
Fitts law was designed for a time when you only ran one app at a time and your monitors were low resolution so that moving between the global menu back to the app was a relatively short distance
I don’t think you really understand what Fitt’s Law is. Fitt’s Law is an equation:
T = A + B log_2(D/W + 1)
Here, T is time required, A and B are emperical constants, D is distance to the target, and W is the width in the direction of travel. Research has shown the equation to be highly accurate in the real world. Now, notice the term D/W. Since menu items have a small W, in general, that makes them hard to hit. Now, when you put the item at the edge, you increase D, but you push W to infinity. That is because you can overshoot any number of pixels without missing the target. Now, even if time has caused D to increase by 2x, that’s still marginal compared to the massive increase in W.
It still works well for PalmPilot devices, but it’s not as useful on the modern multi-app high-res desktop.
Resolution is irrelevent, because mouse movement is proportional to monitor size. 20″ monitors were easily available on workstations back then. Do you think researchers only tested the 9″ toys home users had access to?
My take:
Make it possible, and an option, but for gods sake dont force it upon Gnome users just to please some Mac fanboys in the Gnome community.
If I ever wanted I global menu bar, and if I ever wanted to use an Apfel most of the time, I’d have one, so please dont start forcing OS X interface paradigms on non OS X users.
I’m in favor of making it an option, but only if the Windows-style menubar folks admit that their position is completely illogical and scientifically unjustifiable.
Thanks for the extended explaination, Rayiner.
If you have a global menu bar then fitt’s law doesn’t apply there anymore. Besides, I don’t see why menus are so important. It’s never, ever bugged me and I am so picky.
WInodws design isn’t so illogical, esp. since metacity themes still don’t use fitt’s law with the “x”.
No, the windows-style menubar folks will not admit that their position is completely illogical and scientifically unjustifiable, so there will be no global menu bar option.
“If you have a global menu bar then fitt’s law doesn’t apply there anymore” Like Rayiner already said, are you more likely to press close (on a fullscreen app) than you are to use the menu?
I don’t use the global menu bar (though I could in KDE) but it *is* faster. It takes some getting used to and I would never want to see it as the default but it makes a difference.
That’s why I keep my kicker narrow, so I only have one row of apps in the taskbar: same principle.
“Now that’s an odd usage pattern. Hitting a menu item in a window that’s not currently selected. Who actually does this, instead of clicking on the window to focus it, then going to the menubar anyway. More importantly, do they do this often enough to outweigh the gain of the global menubar in the general case. Remember, GUI design is all about making tradeoffs, and optimizing edge-cases is rarely a good tradeoff.”
I actually do this all the time. I think you will agree that it is more efficient.
my laptop connects with external large lcd through dual head config.
i dont want the menu bar resides on my laptop screen…
@Matt
I actually do this all the time. I think you will agree that it is more efficient.
More efficient than what? More efficient than clicking directly on the menu? Maybe. More efficient than click-to-focus, then click on global menubar? Unlikely, for the reasons I outlined in my post.
@Darn: There is no reason that an implementation of a global menubar need be so restrictive. It would be easy enough to clone the menubar on each screen, for example.
I would seriously wonder the usage patterns under which access to the close button on maximized windows (not all windows, obviously) is more common than menu access. I mean, even if you never accessed the menu because you used hotkeys, why would you then use the close button instead of the close-window hotkey?
The Mac setup is the way it is for a logical reason. Applications are designed so the context menu is accessed most often (if the user knows how to use it), followed by the toolbar, followed by the menubar, followed by various dialogs, followed by window decorations. Intuitively, you “do things” in a window much more often than you close it.
If you consider “efficiency” to be a function of how often each location is accessed, scaled by how long it takes to access each location, and you try to optimize this function, you arrive at the Mac setup. The menubar is where it is because it’s the second-most accessed location, but is very slow to access because of it’s limited height.
for efficiency, mouse gestures are great. Simple click and flick of the wrist lets me do all kinds of things in Firefox and Opera. Obviously not something everyone wants.
“ore efficient than click-to-focus, then click on global menubar?”
Yup
And I’ve used a global menubar in KDE, it is not faster for me for the above reason.
I am for global menu. It is elegant. MDI in windows tries to mimic it. Apps like GIMP will be much more useful.
The Mac setup is the way it is for a logical reason. Applications are designed so the context menu is accessed most often (if the user knows how to use it), followed by the toolbar, followed by the menubar, followed by various dialogs, followed by window decorations.
What’s the logic behind putting the second or third most accessed tool in the most accessible place ?
If, as some claim, the upper screen border is this most accessible place, and if the context menu or the toolbar is the most accessed tool, then it should be placed there.
This isn’t a matter of research, scientific postulations or academic experiments. The concept of a global menu bar is only understand by small group of people, mainly Mac users. To force a concept that is peculiar to majority of computer users upon them is a disservice to them.
I’ve seen users cursing at and fighting with Macintosh computers because everything, including the global menu bar, is foreign to them. Besides, how many applications would have to be rewritten to entertain this new paradigm? How many user interface guidelines would have to be redesigned? The benefits of the global menu bar certainly do not outweigh the costs. As such, nothing like a global menu bar should be introduced in GNOME, not even as an option[sic].
“I would seriously wonder the usage patterns under which access to the close button on maximized windows (not all windows, obviously) is more common than menu access. I mean, even if you never accessed the menu because you used hotkeys, why would you then use the close button instead of the close-window hotkey?”
In applications, where You don’t use menu too often (like FF).
Anyway global menu prevents You from using “focus folows the mouse” thing, wich I find much more useful then global menu. I was using global menu once and stopped for that one reason.
Again, MDI is not just copy of global menu, it is much more useful – it separates program workspace from the desktop and allow application to arrange windows in logical and context-sensible way.
No serious, I’m not trolling. The Mac UI wasn’t designed for multitasking. It took years for the Mac to support multitasking with System 6’s Multifinder (ignoring the buggy Switcher hack and Desktop Accessories). The UI remained almost unchanged with the transition to Multifinder, because it was still reasonably efficient, but it’s far from the optimal solution. It’s really depressing to see almost all Open Source desktop projects mimic Windows or MacOS when they could think of much more efficient UIs if they just thought about it for a little moment.
Is that your real name or did you take it from that really funny movie? 🙂
It’s already *option* in KDE. Why it couldn’t be option in Gnome? Does GTK suck _that_ much? Some people like it, and they should have it (I won’t even consider using Gnome until it gets it. KDE all the way. It does things _right_).
Needless options suck. Does OS X give you an option to use a nonglobal menubar? I thought so. So why do you insist GNOME should adopt a concept foreign to all but a small group of users. It doesn’t make sense.
“Wow, you close windows more often than you are using the applications menu?”
Actually, thinking about it, I probably do.
no, KDE doesn’t do things _right_, it does everything and lets you pick which thing you want to do. Out of 10,000 things. If making it an option is such a sensible idea, why doesn’t OS X have an option to turn it off?
If, as some claim, the upper screen border is this most accessible place
It’s not a claim. It’s an emperical fact supported by a theoretical equation.
and if the context menu or the toolbar is the most accessed tool, then it should be placed there.
Well, the fastest motion of all is no motion (the mouse is already there), so the context menu is in the fastest place. Now, with regards to the toolbar, you have to consider that the goal isn’t to put the most often used things in the fastest places, but to reduce the overall time required. It is only in general that ordering locations in that way reduces the total time. It is not a necessary condition.
Remember, accessing menubars is slow in part because they are so narrow (vertically). Toolbars are much wider, so they are faster to access. If you do the math, you’ll see that putting the menubar at the top is a net win if the ratio of menu access frequency over toolbar access frequency is greater than the ratio of toolbar access time / menu access time. Given a 3x difference between toolbar height and menubar height, the latter fraction is around 0.5-0.7. So if the toolbar is accessed less than 1.4x to 2.0x as much as the menubar, it’s faster to put the menubar at the top.
It’s not a claim. It’s an emperical fact supported by a theoretical equation.
Please note that Fitt’s law was a good fit for monodimensional experiments of aquisition of a target. There’s still not a natural extension of it in 2D or higher dimensionality (try googling about it).
That said, I’m quite sure that slamming the pointer into a corner or an edge of the screen can be done quicker than aquiring a thin menubar.
But nowadays, I’m not sure that’s the only time to factor in. As someone else stated those experiments about the mac-style menu bar were done in different times, when working with several windows at the same time was not the norm.
Besides the time to target the menu there’s also the issue of perception: the metaphore many desktops live upon, and that had in mac’s spatiality an example, is that windows are
objects of some sort. They have a set of properties ( in spatial case they are persistent properties and ubiquity is denied), they react to the users’ actions. The mac menubar is a modal piece of desktop that breaks this mental model. To execute any action on different windows I always have to act through an object that changes according to something I do on the windows (activating them). Frankly, are we really sure that working this way in a big screen with several applications at once doesn’t cause the loss in ‘distraction/confusion time’ of those split seconds you gain by slamming the pointer against the edge?
Besides, why should we measure it in time? The discomfort the user has to go through to execute an action should be the quantity to minimize, really. And while needing great time to pinpoint a thin menubar can increase this discomfort, a broken metaphore that causes “let’s slam the pointer up – let’s find the menu voice – oh crap, wrong window selected” errors may cause the same or even more…
I’m agnostic on the issue, really, as I don’t think there are recent studies of use cases. I just think that it’s more complicated than a magical Fitt’s law.
I’m not so sure that the context menu is the “fastest place”. I remember my mother when the was “forced” to work on the computer the first time and she had quite some trouble holding the mouse pointer steady. Clicking without movin is _complicated_ and requires training. I’m not jocking.
Actually, Fitts law has been extended to 2D.
http://www.yorku.ca/mack/CHI92.html
The question of working with different apps at a time is really irrelevent here. You’re only working with one app at a time, even if you have more than one running. You don’t generally switch windows continuously, only doing a single action in each window. Even if you did, you can pretty well show that it’s still faster to click to focus then click on the menu, then to hit a tiny menubar.
”
I would seriously wonder the usage patterns under which access to the close button on maximized windows (not all windows, obviously) is more common than menu access. I mean, even if you never accessed the menu because you used hotkeys, why would you then use the close button instead of the close-window hotkey?
”
It is for me. Alt+f4 is harder on my wrist than swinging the mouse to the right corner
Whoever said the ting about mouse gestures being efficient, but still not default gets my vote too!
It’s subjective. With a large high-resolution monitor, each window having its own menu bar doesn’t take up too much screen real estate. At a smaller 1024×768, it can save space to have one menu bar at the top.
The main advantae of a Mac-like menu bar is not that it saves screen space, but the it presents a larger target to hit with the mouse, you can’t miss the top of the screen. This makes it faster and easier to work with.
It would be great if Gnome and KDE could coopreate to make this happen on the free desktop.
It runs on lots of operating systems. ACL manipulation, filesystem metdata attributes are too OS specific right now for GNOME to support for the most part.
Most modern Unix file systems have support for ACLs nowdays, and the feature is very important for the enterprise desktop.
Not supporting them or at least not displaying them could be a potential security problem. E.g if a directory is shared by samba a windows user could set permissions that is invissible to the Gnome user.
If some file systems doesn’t support ACLs Gnome should revert to the old Unix behavior. In case this would prevent gnome from building, compile time options should be provided to fix this.
By the way, there is allready an ongoing discussion on how to support this on KDE and the development have started, so hopefully we will see it in KDE4, and KDE runs on more than Linux just like Gnome.
That’s exactly the paper I was thinking of. And as you see there’s no unique extension of Fitt’s law. Both the W’ and ‘lesser’ models give pretty good fitting results in comparison with the obviously botched status quo. But really, I don’t care much about exact quantification: as I said i am pretty sure that the mac-stlye menubar is faster to aquire, clicks or not clicks.
I still think that the price you pay for that is the disruption of a visual metaphore. Time of aquisition is not everything, otherwise why don’t you put _all menu voices_ in the contextual menu? That’s even faster, after all.
The reason all menu choices aren’t in the context menu is because the context menu is designed to be small enough to process at a glance. Putting all menu items in there would make menu access slightly faster, but would make context-item access drastically slower.
Again, it’s about minimizing total time, and that can often require segregating different sorts of actions into different locations. CPU caches operate on this principle, for example.