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 241185
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Why?
by rayiner on Thu 17th May 2007 19:21 UTC in reply to "Why?"
Member since:

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.


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.

Reply Parent Score: 5

RE[2]: Why?
by miscz on Thu 17th May 2007 19:35 in reply to "RE: Why?"
miscz Member since:

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:

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[3]: Why?
by eosp on Thu 17th May 2007 20:47 in reply to "RE[2]: Why?"
eosp Member since:

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

Reply Parent Score: 1

Rimmer's Law - to paraprhase Red Dwarf
by Coxy on Thu 17th May 2007 19:51 in reply to "RE: Why?"
Coxy Member since:

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

Reply Parent Score: 4

Ford Prefect Member since:

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.

Reply Parent Score: 5

ubit Member since:

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.

Reply Parent Score: 4

RE[2]: Why?
by Luminair on Thu 17th May 2007 19:56 in reply to "RE: Why?"
Luminair Member since:

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

Reply Parent Score: 2

RE[2]: Why?
by djst on Thu 17th May 2007 19:57 in reply to "RE: Why?"
djst Member since:

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

Reply Parent Score: 5

RE[3]: Why?
by rayiner on Thu 17th May 2007 20:08 in reply to "RE[2]: Why?"
rayiner Member since:

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.

Reply Parent Score: 5

RE[3]: Why?
by alexandru_lz on Thu 17th May 2007 23:05 in reply to "RE[2]: Why?"
alexandru_lz Member since:

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: ) to Xcode's: .

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

Reply Parent Score: 5

RE[3]: Why?
by nutshell42 on Fri 18th May 2007 13:41 in reply to "RE[2]: Why?"
nutshell42 Member since:

Microsoft got it right more or less (yes, yes, you may shoot me now ;)

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 =)

Reply Parent Score: 2

RE[2]: Why?
by stestagg on Thu 17th May 2007 20:07 in reply to "RE: Why?"
stestagg Member since:

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.

Reply Parent Score: 5

RE[3]: Why?
by rayiner on Thu 17th May 2007 20:12 in reply to "RE[2]: Why?"
rayiner Member since:

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.

Reply Parent Score: 5

RE[2]: Why?
by subterrific on Thu 17th May 2007 22:23 in reply to "RE: Why?"
subterrific Member since:

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.

Reply Parent Score: 3

RE[3]: Why?
by sbergman27 on Thu 17th May 2007 22:28 in reply to "RE[2]: Why?"
sbergman27 Member since:

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. :-)

Reply Parent Score: 2

RE[3]: Why?
by aent on Fri 18th May 2007 00:00 in reply to "RE[2]: Why?"
aent Member since:

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.

Reply Parent Score: 1

RE[2]: Why?
by dusanyu on Fri 18th May 2007 01:35 in reply to "RE: Why?"
dusanyu Member since:

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

Edited 2007-05-18 01:37

Reply Parent Score: 1

RE[2]: Why?
by nrlz on Fri 18th May 2007 05:29 in reply to "RE: Why?"
nrlz Member since:

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.

Reply Parent Score: 2

RE[2]: Why?
by shaunm on Fri 18th May 2007 15:37 in reply to "RE: Why?"
shaunm Member since:

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.

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.

Reply Parent Score: 1

RE[3]: Why?
by google_ninja on Mon 21st May 2007 15:21 in reply to "RE[2]: Why?"
google_ninja Member since:

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.

Reply Parent Score: 1

RE[2]: Why?
by dagw on Sat 19th May 2007 11:03 in reply to "RE: Why?"
dagw Member since:

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.

Reply Parent Score: 2

RE[2]: Why?
by phoenix on Sun 20th May 2007 05:44 in reply to "RE: Why?"
phoenix Member since:

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?

Reply Parent Score: 3