Their missing Mile-High Menus and Magic Corners : Fitts' Law vs. Apple on Windows

safari.jpgWhen using software Fitts’ Lawa model of human movement, predicting the time required to rapidly move from a starting position to a final target area, as a function of the distance to the target and the size of the target – is in effect all the time. Microsoft understands the importance of this but Apple apparently doesn’t, at least not on Windows …

Fitts’ what now?

Mathematically, Fitts’ Law can be formulated as so (thank you Wikipedia):

fittslaw.png

where

  • T is the average time taken to complete the movement. (Traditionally, researchers have used the symbol MT for this, to mean movement time.)
  • a and b are empirical constants, and can be determined by fitting a straight line to measured data.
  • D is the distance from the starting point to the center of the target. (Traditionally, researchers have used the symbol A for this, to mean the amplitude of the movement.)
  • W is the width of the target measured along the axis of motion. W can also be thought of as the allowed error tolerance in the final position, since the final point of the motion must fall within ± W/2 of the target’s centre.

Basically it comes down to this: Fitts’ Law describes a speed-accuracy tradeoff associated with pointing, whereby targets that are smaller require more time to acquire and targets that are further away require more time to acquire.

When applied to computers it’s real easy: one tiny button on a whoop-ass resolution is cannot be acquired easily (tiny target, long distance (viz. lots of pixels) to cross). A whoop-ass button on a small resolution (big target, small distance to cross) can be easily acquired

Fitts’ Law vs. Software : Mile-High Menus and Magic Corners

A real interesting thing when applying Fitts’ Law to computers are Mile-High Menus and Magic Corners. I Read about this (and about Fitts’ Law) back in August last year on the blog of Jensen Harris, Group Program Manager of the Microsoft Office User Experience Team. In one particular post on the Office UI he gives a nice explanation on Fitts’ Law and Mile-High Menus and Magic Corners, so nice it would be a sin no to quote it (highlights added by me):

One of the most useful aspects of applying Fitts’ Law to computers is that screen size is bounded. No matter how far you move your mouse to the left, the cursor will never go farther than the left side of the screen.

In a Fitts’ Law sense, you can think of the edges of the screen as being infinitely wide.

Think about how long it would take you to move your cursor from the right side of the screen to the left edge of the screen. Now compare that to how long it would take you to move your cursor from the right side of the screen to a spot 2 pixels from the left edge.

Obviously, you would be much faster in the first case because you can literally slam your mouse to the left as fast and as hard as you want and you won’t overshoot. It’s infinitely wide.

This is the same reason that the Mac user interface has been said to have “mile-high menus.” The Mac menu bar is permanently affixed to the top of the screen regardless of what program you’re in. As a result, you only have to worry about targeting a menu horizontally. Because the top edge of the screen is essentially “infinitely” tall, you can acquire the menus very quickly.

The Windows taskbar is a mile-high the other direction: you can move your mouse to the bottom of the screen quickly and only worry about targeting horizontally. (If you resize your taskbar to be two rows high, of course, all bets are off.)

Wait, it gets even better. There are four places on the screen that are effectively both infinitely wide and infinitely tall. You guessed it: the four corners.

Regardless of how distant a corner is from your current mouse position, you can get to the corner in no time at all. Acquiring the corner requires very little fine motor control at all because the virtual target is so huge. In GUI terms, the corners are so good they’re often called “magic.”

The Start button in Windows is seemingly located in an ideal place for fast acquisition, and in recent versions of Windows that’s certainly true. Prior to Windows 2000, however, the Start button had a single “dead” pixel along the left and bottom sides of it in which clicking didn’t open the Start menu. The result: slower acquisition times and a startling number of missed clicks.

Fitts’ vs.any Windows application

windows-close.jpgWhen maximizing any Windows application you’ll have 2 magic corners fit to that window: the top left one, and the top right one. The top right one lets you close the application/window, even though the button isn’t visually stuck to the far outer corner. The top left corner lets you reach the previous format/minimize/close menu and a doubleclick on that corner will close the window. Really handy.

Now that I’m giving out tips: doubleclicking the titlebar (which is a mile-high / magic combo) a window can be restored to the non-maximized version if maximized, and the other way around of course too.

Fitts’ vs. iTunes (Windows)

Update: This info applies to iTunes6, in iTunes8 I noticed the same behavior as described in the next section (Fitts’ vs. Safari)

itunes.jpgIn iTunes on Windows, when maximizing the screen (which can also be done by using the doubleclick titlebar trick) you’ll notice that the menu isn’t a mile-high menu at all, something which Apple has been using in their OS for a really long time (see post by Jensen Harris). When going to the upper right corner to close the window by clicking that tiny close button (which isn’t that tiny after all as it should be a magic corner) you’ll notice that this won’t work: nothing happens. When going to the upper left corner to doubleclick and close you’ll notice that this won’t work either: again, nothing happens.

Pitty, but it could be worse!

Fitts’ vs. Safari (Windows)

Update: This got fixed as of Safari 3.0.4 beta

As a user being used to the magic corner behavior and being a genuine Unitasker (1 window, maximized) I noticed some really odd issues when automatically going to the upper left corner to doubleclick and close Safari. Instead of Safari disappearing, the window underneath closed. * oink? *

A little investigation led me to locating the problem and writing this post: the upper left corner and upper right corner in Safari on Windows are … non-existent! … All of the sudden I’ve lost my appetite in Rounder Corners :(

Just try it yourself:

  • Launch Windows Explorer (for example) and maximize it
    (doubleclick the titlebar, remember? ;))
  • Launch Safari and maximize it
  • Go the top left magic corner to close Safari (viz. click it)
  • Windows Explorer will be closed instead
  • Repeat all steps and try the same for the top right magic corner: Windows Explorer will be closed again.

Pinging Apple!

Dear Apple, as the behavior described above is complete odd for any Windows user out there, please fix this as it has – and I’m using some nice words here – been tickling me ever since I installed Safari. Maybe that’s something to put in Safari 3.0.3 beta? And oh, thanks for fixing those em and strong rendering issues on non-English XPs in the 3.0.2 build, now I can use Safari (in a non-user-friendly way though, but I have the feeling you guys are going to fix this any time soon).

B!

Another Dailie, Bramus!

9 Responses to Their missing Mile-High Menus and Magic Corners : Fitts' Law vs. Apple on Windows

  1. Bart says:

    Apple has many interface problems. E.g. the single mouse button in combination of the apple key (instead of right-click). Did they ever think about people with disabilities?

    On Mac, you don’t survive without the apple key. This problem can also be found in many of the Adobe applications. Compare Illustrator to Coreldraw. In Coreldraw you can copy, duplicate, scale, mirror,… your objects with smart mouse behaviours. In Adobe this can’t be done without touching your keyboard.

    I also don’t understand what’s so fun about launching programs not full screen and having layers of windows overlapping each other. Interfaces of underlaying applications appear through windows of overlaying applications. How confusing is that?

    But it seems to work. And user seems to get used to it.

  2. alphaindigo says:

    yes i agree this is an annoying problem i have noticed myself inedvertantly. Very interesting article. i will use some of these ideas in creating aps in the future…

  3. Pingback: Bram.us » http://particletree.com/features/visualizing-fittss-law/

  4. Pingback: Bram.us » Safari 3.0.4 beta

  5. Ragu Kattinakere says:

    Hi,
    The article applies Fitts’ law very nicely.

    I have noticed that Apple does not take in to account some of the obvious improvements. For example the Close,Minimize buttons are so small that it is hard to close the window.

    The menu bar at the top of the display in Apple Mac may not be as useful as it looks from the perspective of InfoViz. Mac disassociates the menu from applications, which is inherently an integral part of the application, introducing visual and motor discontinuity. Disassociating Menu from application also introduces unnecessary distance.

    Looking at the arrangements of menu in WinX, I see that placing Menu bar on top of the title bar will increase performance.

    ~rAGU
    UofS

  6. Pingback: Non-intrusive peel back ads « totallyMAd - The Blog

  7. Pingback: Bram.us » Fitts’ Law vs. Apple on Windows, continued

  8. Pingback: Bram.us » Fitts’ Law vs. Apple on Windows, continued, again

  9. Vincenzo says:

    Hello. Just a quick observation. I haven’t been using Windows for ages now, but as far as I remember, the Windows applications menus are not high-mile menus at all, as they have got the window title bar on top of them, haven’t they? So, you actually need to point the mouse to some pixels below the top edge of the screen, which is significantly slower than point the mouse to the edge (for the Fitts’ law, of course).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>