Linked by Thom Holwerda on Thu 17th May 2007 18:54 UTC
Gnome In the GNOME bugzilla, there is an ongoing discussion about whether or not to include a patch into the default GNOME installation which would enable GNOME to (optionally) have a global application menubar, similar to that of the Mac OS and KDE (in the latter it is optional and off by default). Installation instructions and .deb packages, as well as a 60-page (and counting) discussion of the patch, are available on the UbuntuForums. Read on for a poll on this issue.
Thread beginning with comment 241199
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Why?
by miscz on Thu 17th May 2007 19:35 UTC in reply to "RE: Why?"
miscz
Member since:
2005-07-17

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.

Reply Parent Score: 5

RE[3]: Why?
by rayiner on Thu 17th May 2007 20:16 in reply to "RE[2]: Why?"
rayiner Member since:
2005-07-06

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.

Reply Parent Score: 5

RE[4]: Why?
by miscz on Thu 17th May 2007 20:33 in reply to "RE[3]: Why?"
miscz Member since:
2005-07-17

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

Reply Parent Score: 2

RE[4]: Why?
by Coxy on Thu 17th May 2007 21:05 in reply to "RE[3]: Why?"
Coxy Member since:
2006-07-01

'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.

Reply Parent Score: 1

RE[3]: Why?
by eosp on Thu 17th May 2007 20:47 in reply to "RE[2]: Why?"
eosp Member since:
2005-07-07

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

Reply Parent Score: 1