Laws of UX has a nice overview of the different laws that exist in user experience! Fitt's law: https://lawsofux.com/fittss-law
Principles of interaction design has even more entries and is quite detailed. Unfortunately, it’s a book that isn’t free!
Visualizing Fitts's Law (2007)
11–20 of 37 posts
Re: Visualizing Fitts's Law (2007)
#12How does this work with radial menus and touch interfaces?
Well, radial menus typically are displayed around your mouse cursor, so the proximity aspect is there. They also fill out the space, well, radially, so you can really just fling your cursor into a direction and will have the total width of the menu item to hit all the way.
With touch screens, there's two major differences compared to the desktop:
1) You don't have screen edges that you can fling your cursor against, so placing UI elements at the edge does not make them easier to hit.
2) Users are generally quicker to traverse the screen and hit something, but are much worse at hitting something that's small, so you often want to make UI elements bigger (which does result in them being more spaced out) and then put the UI elements on several screens instead.
Re: Visualizing Fitts's Law (2007)
#13Earlier quoted context omitted.
It was. I wonder, though: with modern monitor sizes, does that make as much sense as it did with a 9", 512×342 screen?
Depends on two things: 1. How fast can you get the pointer to the menu? 2. How easy is it to get the right item? If you have a "large" screen, I would contend that having a dedicated menu button on your mouse/trackpad/trackball/pen is the best possible thing for any user who isn't a complete novice. Don't wave the pointer somewhere else, make the menu come to you. If you can't do that for whatever reason, then having…
The 'make the menu come to you' approach would make sense for large and/or unusually controlled screens. Take game consoles and their directional controllers or old style mobile phones with numeric keypad for example, they made most menus pop up in context-menu style.
I imagine something like holding a menu button which acts like a modifier key that also pops up a menu on-screen. Then, using a physical layout on the screen that matches the layout of the buttons on your controller or pointing device to navigate/select items of choice without using x,y pointing systems such as the mouse arrow. This does however create a new problem: how to decide where the menu is going to overlap over the stuff you were working on?
Re: Visualizing Fitts's Law (2007)
#14IIRC this is one of the reasons the UI on the Mac opted for a fixed context-dependant menu bar at the top of the screen instead of the per-window one used by Windows (and Java). It's basically 'fling your pointing device at the top' and 'go left or right to get the button you want'. Due to the lack of borders/stops, this would be harder if it was sandwiched between a titlebar and window content.
It was. I wonder, though: with modern monitor sizes, does that make as much sense as it did with a 9", 512×342 screen?
"People for years have been explaining to me very patiently that in this era of giant screen monitors, we just have to do something about those menu bars way up there at the top of the screen" -- Tog, column 15, May 1990
He then describes an experiment where he used a 21-inch monitor and a 13-inch monitor attached to a Mac, and had subjects change the color of folders on one screen by selecting menu items on the other. Even compared to a pop-up menu right under the mouse, the far-off edge menu bar was still faster.
Objects on a 2018 MacBook Pro can be 70% further apart (D) than on a 1984 Macintosh, but the edges of the screen are still infinitely big (W).
Re: Visualizing Fitts's Law (2007)
#15IIRC this is one of the reasons the UI on the Mac opted for a fixed context-dependant menu bar at the top of the screen instead of the per-window one used by Windows (and Java). It's basically 'fling your pointing device at the top' and 'go left or right to get the button you want'. Due to the lack of borders/stops, this would be harder if it was sandwiched between a titlebar and window content.
You can however also argue against having such a global menubar with Fitts's Law, as it means that other UI elements can't be placed at the screen edge, such as the min/max/close-buttons (though there are also concepts where those are global, too) and nowadays also browser tabs.
While partially true, this could be solved by simply assigning priority to UI elements. Launchers/window managers often list their stuff at the bottom or sides (like docks and window lists) which allow for the same ease of navigation. There is of course only a 4-side box that you can use, and cluttering an environment with bars at all sides doesn't help a user.
The close/resize/etc buttons are indeed a different issue, while the controls are often duplicated (File or window menu on most operating systems and window managers have the close/resize/max options too). At some point I think Ubuntu had a default desktop environment where the close/max/min buttons were added to the top menu bar. I thought it was quite a nice idea, but the implementation never spread to other systems and sadly, support wasn't very universal across all applications.
Thinking along those lines, what if you added the title bar at the top too, you'd end up without a border/bar at the top of the window, making it harder to find something to 'grab' with your pointing device. Some operating systems use a modifier key + the mouse to turn all windows draggable and disable inputs while doing it, but that hasn't had much success (aside from it being the default on certain window managers).
Re: Visualizing Fitts's Law (2007)
#16Previous discussion : https://news.ycombinator.com/item?id=11208463
I posted this in previous discussion too, a much simpler explanation : https://www.youtube.com/watch?v=E3gS9tjACwU
Re: Visualizing Fitts's Law (2007)
#17The engineers way of thinking about Fitt's Law is as a human control system. We motion control our hands by using feedback (visual, tactile, proprioceptive). The servo time response to a step function (new location to click) of that feedback loop depends on the required accuracy and allowed overshoot. The larger the target, the higher a velocity/acceleration you can use to hit it without missing. You learn very quickly that large objects (like edge of screen) allow much more gross movements than single pixel target... and the farther you have to go the larger the time at a given tracking velocity.
What is at least as interesting is the cognitive load of tracking/pointing, clicking/chording . Mental load and apparent time appear to be the reason why typing can be slower than a menu system, but it feels faster. Similarly, people will report a feeling like a trackpoint (IBM keyboard nipple) takes longer than a mouse even when they're actually faster in hitting targets. Presumably, this is because they have to track the cursor to know velocity and position, while a mouse or touchpad uses your body's knowledge of hand position/velocity that is missing from a force based input.
What you're used to feels right in any case.
Re: Visualizing Fitts's Law (2007)
#18IIRC this is one of the reasons the UI on the Mac opted for a fixed context-dependant menu bar at the top of the screen instead of the per-window one used by Windows (and Java). It's basically 'fling your pointing device at the top' and 'go left or right to get the button you want'. Due to the lack of borders/stops, this would be harder if it was sandwiched between a titlebar and window content.
Used a Mac full time three years.
Having to
-move the pointer diagonally across two screens, then pick something in a submenu (carefully, I think the submenu disappears if you don’t hit the end of the first menu and instead tries to move directly to the item in the sub menu)
- and back again
is one of the things I never miss.
Re: Visualizing Fitts's Law (2007)
#19IIRC this is one of the reasons the UI on the Mac opted for a fixed context-dependant menu bar at the top of the screen instead of the per-window one used by Windows (and Java). It's basically 'fling your pointing device at the top' and 'go left or right to get the button you want'. Due to the lack of borders/stops, this would be harder if it was sandwiched between a titlebar and window content.
Used a Mac full time three years. Having to -move the pointer diagonally across two screens, then pick something in a submenu (carefully, I think the submenu disappears if you don’t hit the end of the first menu and instead tries to move directly to the item in the sub menu) - and back again is one of the things I never miss.
MacOS's dual monitor implementation puts the current window's menubar on the current screen now, so at least you don't have to go across two screens.
Re: Visualizing Fitts's Law (2007)
#20IIRC this is one of the reasons the UI on the Mac opted for a fixed context-dependant menu bar at the top of the screen instead of the per-window one used by Windows (and Java). It's basically 'fling your pointing device at the top' and 'go left or right to get the button you want'. Due to the lack of borders/stops, this would be harder if it was sandwiched between a titlebar and window content.
I remember this explanation too, but think it's one of those "good in theory, bad in practice" things --- going all the way to the edges all the time (and back!) is very tiring if you have your mouse set for high accuracy and have (a) huge screen(s).
This is something I remember very clearly since it was the explanation I was given when I first tried out the original Macintosh decades ago. Even with its tiny screen I had to lift and reposition the mouse, or otherwise move my whole arm, in order to go from one edge to the other. The other annoyance that stood out was menus that didn't stay open unless you held down the button, and a complete lack of keyboard navigation (I know about the keyboard shortcuts, but it doesn't compare to being able to browse through the menus with only the arrow keys, which could be done even with early Windows.)