Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Apple studied this on a 512x342 1-bit display, on a machine architecturally incapable of multitasking more than one app at a time. It's just not relevant anymore, sorry.

The ease of aiming is a real effect, but lost on a 1920x1080 display. And the usability disaster of trying to figure out which of the three "main" windows is in the foreground (and thus owns the menu) is something that was not studied, nor accounted for by Apple in the 80's.



The effect is not lost at all. It's Fitts's Law: http://en.wikipedia.org/wiki/Fitts%27s_law -- the Mile High Menu Bar is still a mile high on a 1920x1080 display. http://joelonsoftware.com/uibook/chapters/fog0000000063.html


Sure, though in interests of full disclosure, on a large screen the menu bar is actually "a mile high, and a mile away". Still, global menu on the Mac is probably still at least a wash for all but the most expansive desktops.

With Unity, though, the global menu bar on a large desktop is "a mile high, a mile away, and invisible". You get to guess where you should be aiming.

Are you really arguing that hitting a target you can't see is easier than a target you can see?

All that said, I do prefer Unity over other options on my netbook. The savings in real estate is well worth the marginal cost in usability. I don't use the menu bar much, anyway.

That last bit is probably Unity's saving grace: most apps used by most people are no longer designed with the menus as the primary interface.

Since they're less used, it makes sense to optimize screen use by tucking them away at the top of the screen.

I wouldn't at all mind if the menu bar had an auto-hide mode, though. Actually, what I'd like is a partial auto-hide. Tuck away over to the top left, with only the window widgets and the indicators showing. I'd gain a line or two in any editor or term on the right side of the screen.


No it's not "a mile away", it's a few inches away. You're performing thought experiments instead of actually measuring, and that's a no-no. Your intuition is no good. The scientific method is. If you can prove your point that the menu bar is hard to hit because it is as far away as it is tall by a controlled experiment, then by all means, publish your work in peer reviewed journals, because a lot of professional HCI researchers will be astonished, and you will be very famous for proving something so counter-intuitive that breaks Fitts's law and flies in the face of all the other studies that have been done, and the hands-on experience of millions of Mac users.

To test your intuition (by quoting one of Tog's favorite puzzles): Name the five points on the screen that are the easiest to hit with the mouse.


It's a mile and four intervening windows all activated via focus-follows-mouse away.

On Macs, fer love of Pete, the Mile High Menu ... is on the other display.

Menus just f@cking suck anyway. I've canned my browser menus via Vimperator (on Firefox / Iceweasel). Sure, I'm a power user and I know what I want to do and I've got finger memory five miles deep (plus command completion). So suck on that teat.

Fipp's Law optimizes for one case: mouse navigation. Sure, it's nice to have a big fat landing zone, when you need it. But often you don't, and the optimization unambiguously and indisputably breaks numerous other optimizations. Which frankly I care a whole f@ck of a lot more for.

We're talking about desktop (or large laptop) displays here. For tablets and small-factor handhelds, there are other considerations. Which is why UI design is complicated and a task and disipline worthy of research and nuanced understanding.

The 1980s were 30 years ago. Go ahead and pop up a 512x342 window on your desktop. On my not-extravagant dual-head display, I can stack those up 6.5 across and three high. With window decorations.

Y'know, I credit Jobs with some good stuff, and he was nothing if not persistent in believing what he believed in. But some things really have to go.


Actually, with pie menus, it's quite easy to hit a target you can't see, because you can "mouse ahead" and be very sure of the direction you're moving, enough that you can reliably select between 8 different directions without looking at the screen. With four items it's almost impossible to make a mistake, unless you're holding the mouse sideways or upside down.


And no, I'm not arguing about Unity's invisible menu bar, or whatever it has. I haven't used Unity, and I have no plans on using Unity, because all of the X11 based Unix and Linux desktops have always sucked, and they always will.


The bar is a mile high, but each menu column is still only an inch wide - so distance matters, even if you have mouse acceleration so that a large vertical is painless.


Even with inch wide menu bar items, the fact that the menu bar is a mile high still completely overwhelms the cost of the distance of moving the cursor to the menu bar. And you can move back and forth while still moving up, to switch between menu bar items without losing the menu bar target. Do the math. Do the experiments. Measure the results. Read the papers. Thought experiments are no good.


"Do the math. Do the experiments. Measure the results. Read the papers. Thought experiments are no good."

Use the software.


Fitts's law (often cited as Fitts' law) is a model of human movement primarily used in human–computer interaction and ergonomics that predicts that the time required to rapidly move to a target area is a function of the distance to the target and the size of the target

How does that do anything but confirm the GP's point, that it's dumb to place a menu bar potentially thousands of pixels away from the window it applies to?


Because Fitts's law relates both the target size and the target distance to the speed and accuracy of hitting the target. Not just the target distance. You can move the mouse very quickly to cover the large distance, without worrying about the accuracy, thus reducing the negative contribution of the distance, because the target size is practically infinite. The target area of the menu bar at the top of the screen extends infinitely up above the screen, because when your mouse hits the edge, it stops moving and stays in the target. Try it yourself. It's EXTREMELY easy to move the cursor to the top of the screen, no matter how far away it is. The distance doesn't matter, because the target size overwhelms it. That's what is meant by the "Mile High Menu Bar" -- calling it a mile high is an understatement!

This is also why pie menus have improved time and error rates over linear menus: linear menu targets are very small, and increasing distances away from the cursor, but the pie menu items all start out adjacent to the cursor, and extend all the way out to the screen edge, so you can trade off increased distance of movement for increased target size. The target area of the pie-slice shaped wedges get wider and wider as you move out further away from the menu center. (I don't mean they dynamically change size as you move, I mean that as you move out, you're in a much larger part of the slice. So with a four-item pie menu, each target area gets about 1/4 of the screen real estate, and you can keep moving the mouse even further when you hit the edge and still be in the same target slice.) Pie menus also minimize the distance, but around the center, the targets are at their smallest, but you can always move out further to get more "leverage" and directional accuracy.


> How does that do anything but confirm the GP's point, that it's dumb to place a menu bar potentially thousands of pixels away from the window it applies to?

That menu bar is effectively a billion pixels tall. You can throw the mouse pointer to the top of the screen and only concentrate on accurate horizontal positioning, since the mouse will not leave the top edge.

Putting the menu bar at the top sells out the distance side of the function to dramatically increase the target size.


So now that you've thrown the mouse to that easy to find top of the screen mile high menu bar, and completed your mouse action, don't you now have to find your teeny weeny window over in some far off portion of the screen and move that mouse back into the window you're actually working in?


That is correct. And one of the largest consistent complaints by new OS X (and prior to that MacOS) users in terms of usability problems.

On multiple monitors, the menu can be 1 or more monitors away from your app window. It might not just be up at the top of the screen, it might be up at the top of 1 screen over and two up.


Fitts' Law is certainly not lost on large displays, set up Expose to use hotcorners and you'll be hitting infinite-width-targets hundreds of times per day.

Same for screen edges: Taskbar buttons or the tabs in Chrome on Windows are awesome, extremely easy to target, because they're on the edge of the screen. (The New Tab Button was recently made Fitts'ier as well: http://code.google.com/p/chromium/issues/detail?id=48727 )

The issue with the Menu Bar is that it's the wrong thing to be putting on the edge of the screen. The menu items are still extremely easy to hit... it's just that they're no longer useful. No need to have them any more. GUI advances such as the Ribbon or just the concept of removing useless features are leading to apps like Chrome having few menu items at all.

On modern apps the cognitive load of the "which-app-is-in-focus?" is the main problem, which you mentioned. But that's a ding against the usefulness of the menubar, not Fitts' Law in general.


> Apple studied this on a 512x342 1-bit display, on a machine architecturally incapable of multitasking more than one app at a time. It's just not relevant anymore, sorry.

... how do these technology changes render their results irrelevant? The menu bar problem sits at the point where a user's ability to aim the mouse in physical space on the screen interacts with how the menu is represented in physical space on the screen. I don't see how any of the changes you've listed affect that problem, except for screen resolution, which only seems to make it worse by shrinking the physical size of click targets.


It's now more of an argument over the usefulness of the menubar, not which is easier to hit. Of course the Mac menu bar is easier to hit. The question to ask is why do we need a menubar at all?

By not having a global menubar, Windows has permitted the development of infinite-width tabs-on-top in Chrome, the Office Ribbon, getting rid of the menubar entirely in Windows Explorer, etc. It's impossible to do things like that in OS X, because we're stuck with a menubar from the 1980s.


If anything, technological changes have made it easier to hit the target, because mice no longer have physical balls that get jammed with dirt, and they are much more accurate. The kid you're replying to has probably never had to pick the black ring of scum off of the wheel inside a Mac mouse, when it stops responding to movements.


I have had to do this. Although I'm absolutely thankful that those days are over, I'm not convinced higher precision mouse control alleviates enough of the problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: