The apostrophe comes at the very end only when the s has been added to a word to make it plural. You don't add an s to make a word plural and another s to make it possessive. If you write about the wealth of Donald Trump, it's "Trump's money" but the wealth of the Trump family (i.e. multiple people) it's "Trumps' money." There is no singular "Fitt" so Fitts's Law is correct, same as "Laura Poitras's films."
The apostrophe also comes at the very end when "es" is added to make a word plural, e.g. "fishes' spawning ground."
Was about to post 'there are so rules!' because my SO's design students often claim this is true of apostrophe use in general resulting in much gnashing of teeth, but I checked and stone me if you aren't right in this particular case.
Whilst maybe not strictly accurate, I've always strongly associated Fitt's Law with two things that OSX gets tragically wrong. I really cannot fathom why these bugs (they are, undoubtedly bugs, unless anyone can argue otherwise) persist.
1. Menu items. Pull down the main menu on OSX, and find a menu with a separator - a line between groups of related actions. The separator itself isn't a target - it doesn't lead anywhere - but clicking it dismisses the menu. So, miss your intended target by a few pixels, and frustration ensues.
2. Window edges. This one is a side-effect of OSX's poor support for full-screen windows. Even if you 'maximise' a window, moving your pointer to an extreme edge does, for example, allow you to move the scrollbar, but persists in offering the 'size window' action. So you need to go all the way to one edge, then move ever so slightly back again, which reduces the target area from infinite to very small. Full-screen addresses this, whilst introducing other 'flaws' (like your global menubar no longer being visible).
Also the corners at the bottom do nothing. I never understood why the dock just floats stupidly in the middle, rendering stuff to the left and right of it unusable for anything, especialy the corners of the screen.
Form over function, I guess.
Yes, the dock is terrible - I autohide it to avoid problems. Newer versions (I'm still on 10.9) use a more two-dimensional dock which would be well suited to 'framing' the main window area, at full-width, much as the global menubar does. Then I'd be able to have my ideal setup - dock permanently visible (but probably quite short), and ability to have windows fully maximised, in-between the global menubar and the dock.
The corners can be used as hotspots however. For example, bottom right to lock the screen. Not brilliant but not without function.
The dock is terrible. I edited a config file to have mine as small as possible and then auto-hide it. Also never use Mission Control or whatever the launcher grid screen is called. Spotlight set only to show apps and client directories does everything I need.
Since there seem to be an increasing number of “menu bar extras” (that are increasingly greedy about taking up space), it seems overdue to turn the Dock into another option for status bars.
Those useless Dock corners could be really nice for displaying square widgets that might otherwise want a chunk of the menu bar.
Agree. OTOH there are elements on OSX that play better with Fitt's Law than on other OSs, like the menu bar on top or the customisable hot corners (which I don't think are as common on Windows). So I guess it's difficult to come up with the perfect UI.
My problem with the argument that menu bars should be at the top is when you have to return the pointer to where you are. Thus I prefer only using context type menus for everything, 0 movement of the mouse is infinitely better anyway. And you save screen space.
True, but there are some minimal Linux desktops like that (everything is launched from a right click context menu), and they never feel right. They are certainly the least intuitive to use when you first try them. There is nothing to left click.
Sure but hierarchal text menus are widely regarded as absolutely terrible for usability, if your user is forced to use them often enough to actually justify giving them an infinite target* then you've basically failed in UI design (granted that's not always avoidable there's a reason we still have menus despite their awfulness).
*of course due to the wide screen nature of monitors they aren't actually infinite because you'll almost always have significant horizontal velocity by the time your pointer gets there causing you to have to stop and carefully move your mouse just as much as if you had window-attached menus and often further if you've rammed into the corner furthest from your desired menu. The RiscOS/NeXT approach of putting the menus in the context menu is arguably best for acquisition speed although probably worse for discoverability because you have to take an action before you can see even the top-level of the hierarchy.
I thought it was just me - most (no, All) Mac Users I've mentioned issues like this to have just looked at me like I'm crazy. I've always wanted to like OSX (I'm not deeply technical, but did a lot of playing around with Linux when it wasn't straightforward to install), but always found the UI frustrated me, and whenever I've tried discussing it (particularly as I work in Music Tech) I've just been shut down by Mac-philes.
I think that Windows 10 is similar - there are window-edge issues which don't (to me) appear to be present in W7 that make it more frustrating when resizing, etc.
I don't think the window edges violate fitt's law. To use the scroll bar, you slam your courser to the edge of your screen and then move a known amount over, which are two things that don't involve fine grain hunting.
I haven't noticed the menu divider issue. You already have to wait until your menu item is highlighted before clicking, so that is what you focus on. It is an odd choice though.
There's definitely a connection; see this article [1] by legendary Apple UI designer Bruce Tognazzini. You'll have to scroll down just below halfway (or ctrl-f) to the section titled "Fitts’s law". Looks like Tog hasn't quite understood the UI implications of adding the ID attribute to headings ;-)
I don't understand No 2? If the right side of a window extends to the edge of the screen, I can slam the cursor right and start dragging up/down for scrolling. It does show the resize left/right cursor, but the scrolling works.
I'd never realised this before but, somehow, that behaviour appears to be application-specific. Finder scrolls, Sublime Text does nothing, Chrome moves the window. This does not make me any happier.
This issue is rampant in OS X and not just with mouse behavior - many keyboard shortcuts are different depending on what type of app it is... i.e. in some cases the go to the beginning of the line action is bound to 'fn + left arrow' and in some cases is instead bound to 'ctrl + a'
Mac OS is about easy entry-level accessibility whereas windows/linux are more suited to power users for this reason. Much, much easier to be a pure/power kb user in windows/linux.
This is due to hysterical raisins and has to do with OS X's mixed carbon/cocoa legacy. You can make ctrl-a, e, etc work in almost all proper Cocoa-based apps.
Who still scrolls by actually grabbing the scrollbars, and why?
They are hidden by default in OS X, and you can just use swipe gestures on trackpad/Magic Mouse or the mouse wheel on other mice to scroll, while the cursor is anywhere over the window..
Although I love the scrollwheel and you couldn't pry it from my cold dead hands, I use the scrollbar every day (in Windows 7, which has them) for two purposes:
- Moving a whole page up or down by clicking on the grey bar, which is similar to pressing Page Up and Page Down, but it's much faster on screen when I already have the hand on the mouse and the window maximized (because of Fitts's law, the scrollbar has infinite width, while the keys are small).
- Dragging around up and down in a long page to a different part of the document, in almost instant time. I HATE with all my strength how mobile browsers and apps have eliminated that option. Dragging a moderately long page to find a particular section (in, say, a Wikipedia article) with the touchscreen's physical scroll is a pain in the ass, and slow as molasses because the max speed is also capped at a low value. Is it that hard to show a drag handle after the drag event has started, and hide it when it ends?
Scrolling by Magic Mouse/trackpad swipe gestures in OS X is also incredibly fast; you can go through very long pages with just 1-2 swipes, and you can stop the scrolling at any time by tapping the source.
I donot understand your point. As a SW engineer who focuses on UI design and implementation, my desk has three screens. One screen dedicated to execution, one dedicated to code, and one dedicated to spreadsheets or design documents, etc.
My Fitts's law analysis happens on a target platform and not my development system.
The problem with multiple monitors is that it becomes harder to acquire UI elements placed at the corners. Like for example the "Close" button, "Start" button, "Show Desktop" button, scroll bars etc.
I remember how long it took Microsoft to get this right. The first few versions of the Start menu and task bar items had a couple of pixels of space separating them from the edge of the screen. It was like snatching defeat from the jaws of victory, such a profound reduction in usability over what was probably someone’s arbitrary aesthetic choice.
My friends and I have a word for violations of Fitts' law. We call it "pixel spearing". It is incredibly frustrating to have to spear exactly the right pixel in order to get something done on the GUI. The original Mac had this right. Gnome used to get this right. What is it with GUI designers that they think pixel spearing is OK? It's like trying to thread a needle some times.
One rule of thumb which abides by Fitts' Law that I try to follow is: "the user's attention should not be squandered". [3] (So I apologize for being so verbose.)
My goals have been enabling designers and users to easily create and edit their own pie menus, and providing smart editors, automatic layout, and support and guidance to help humans come up with easily memorable, Fitts'-friendly designs.
This demo of an old OLE/ActiveX implementation of pie menus in Internet Explorer [4] shows the weakness and complexity of the traditional desktop gui MFC based approach to creating and editing pie menus with typical property sheets, scrolling lists and tree editors.
When editing a scrolling list or tree of items, it's difficult to visualize the directions, which change when you add or remove items. As the antithesis of direct manipulation, it takes far too much pointing and clicking to indirectly edit a pie menu via a scrolling list or tree control.
Entering an indented outline into a text editor is an easy way to quickly define and edit a tree of pie menus and submenus, but it doesn't give you a good way to edit properties of each item. Of course describing menus in XML is great if you're a web server, but not fun for human beings.
I tried to combine these different techniques of editing pie menus in a tabbed dialog, with a scrolling list and controls for editing items, a tree of nested items and a graphical preview, a text editor for entering nested items as an outline, loading and saving XML.
But the result was a horribly unwieldy Frankinterface's Monster, difficult for a professional UI designer to use, and impossible for end users to use.
These jQuery pie menus have a more evolved, web friendly design, but I haven't made an editor for them yet. Here's the documentation [5] and free open source code [6].
In the newer jQuery version, one change from previous designs is that I'm de-emphasizing the idea of "menus", and just calling them "pies", because I believe that framing pies as menus has too much historical baggage, does not emphasize their gestural, direct manipulative qualities, and precludes thinking of them more like a directed graph or geographical map, instead of a hierarchical tree.
The jQuery and Unity3D [7] versions also differ from previous designs by modeling pies as containing directional slices, which themselves contain linear items, instead of pies containing items directly, and laying out all items in different directions, which change whenever you add or remove items.
I want to like pie menus, because it's nice that all the entries are equidistant from the cursor. But I just can't seem to like them.
Maybe it's because they don't lend themselves to scanning and sorting. It's easy to sort a list of items alphabetically, and it's easy to scan a list by moving my eye down across it, requiring nearly no horizontal eye movement to read the words. But a pie menu does not lend itself so naturally to alphabetical sorting, and scanning requires circular eye movement, which is less economical.
It also has seemed to me that pie menus don't lend themselves as well to memorizing where entries are, perhaps because of the sorting issue. I can remember that a word starts with A and is at the top of a list, but remembering where a word belongs on a compass or clock face doesn't seem as natural, unless the associated action is itself directional (up/down/left/right, north/south/east/west etc).
Here's an example which comes to mind. Team Fortress 2 has quick-access voice lines which can be played with two keypresses, one to open one of three menus, and another to select a line from the menu. They are displayed in a compact list on the left side of the screen.
A newer game coming out soon, Overwatch, also has quick-access voice lines, but they are accessed through a pie menu that covers the entire screen, and items are selected with the mouse.
When I haven't played TF2 for a while, I can be running around the map playing the game, hit one of the keys, and scan the list of commands to find the one I want so quickly that I don't even have to think about it; my eye can sweep across the list in one motion. I just open a couple of the menus and then hit the key, all while running around the map, turning my character with the mouse, etc.
In Overwatch, this doesn't work at all. If I don't remember where a command is on the pie, I have to move my eye in a circle the diameter of which is nearly the entire height of the screen. This takes significant time and effort compared to scanning a list. It also blocks the screen, and it prevents the mouse from being used to control the character.
So, for actions and menus that are primarily directional in nature, and limited in number, I can see pie menus being a natural choice. But for menus that are non-directional, and especially ones that don't lend themselves to memorization, pie menus seem objectively inferior to simple, vertical lists.
All very true! Pie menus aren't good for dynamically generated lists, or very many items.
To handle those inevitable cases, the jQuery pie menus (and other implementations [1]) can support a hybrid mixture of directional pie items and traditional linear items, by simply adding multiple items to the same slice.
Multiple items in the same slice are just laid out vertically (or horizontally, or even diagonally) in the slice direction, and they can track based on entering/exiting rectangles just like a linear menu, or by the distance (like a pull-out font size menu, etc) [2].
I've also tried various forms of spiral scrolling [3], paging [4], and weird springy things [5]. And also limiting the maximum number of pie items, so the first eight "most important" items are assigned to different directions, and subsequent items are laid out below or above the menu as linear items.
44 comments
[ 95.6 ms ] story [ 1194 ms ] threadThe apostrophe also comes at the very end when "es" is added to make a word plural, e.g. "fishes' spawning ground."
Rules 1b and 1c http://m.grammarbook.com/punctuation-rules/apostrophes.aspx
[1] https://en.wikipedia.org/w/index.php?title=Accot-Zhai_steeri...
1. Menu items. Pull down the main menu on OSX, and find a menu with a separator - a line between groups of related actions. The separator itself isn't a target - it doesn't lead anywhere - but clicking it dismisses the menu. So, miss your intended target by a few pixels, and frustration ensues.
2. Window edges. This one is a side-effect of OSX's poor support for full-screen windows. Even if you 'maximise' a window, moving your pointer to an extreme edge does, for example, allow you to move the scrollbar, but persists in offering the 'size window' action. So you need to go all the way to one edge, then move ever so slightly back again, which reduces the target area from infinite to very small. Full-screen addresses this, whilst introducing other 'flaws' (like your global menubar no longer being visible).
The dock is terrible. I edited a config file to have mine as small as possible and then auto-hide it. Also never use Mission Control or whatever the launcher grid screen is called. Spotlight set only to show apps and client directories does everything I need.
Those useless Dock corners could be really nice for displaying square widgets that might otherwise want a chunk of the menu bar.
*of course due to the wide screen nature of monitors they aren't actually infinite because you'll almost always have significant horizontal velocity by the time your pointer gets there causing you to have to stop and carefully move your mouse just as much as if you had window-attached menus and often further if you've rammed into the corner furthest from your desired menu. The RiscOS/NeXT approach of putting the menus in the context menu is arguably best for acquisition speed although probably worse for discoverability because you have to take an action before you can see even the top-level of the hierarchy.
I think that Windows 10 is similar - there are window-edge issues which don't (to me) appear to be present in W7 that make it more frustrating when resizing, etc.
BetterSnapTool and alike help, though.
I haven't noticed the menu divider issue. You already have to wait until your menu item is highlighted before clicking, so that is what you focus on. It is an odd choice though.
[1] http://asktog.com/atc/principles-of-interaction-design/
Mac OS is about easy entry-level accessibility whereas windows/linux are more suited to power users for this reason. Much, much easier to be a pure/power kb user in windows/linux.
http://www.hcs.harvard.edu/~jrus/Site/cocoa-text.html
https://developer.apple.com/library/mac/documentation/Cocoa/...
They are hidden by default in OS X, and you can just use swipe gestures on trackpad/Magic Mouse or the mouse wheel on other mice to scroll, while the cursor is anywhere over the window..
- Moving a whole page up or down by clicking on the grey bar, which is similar to pressing Page Up and Page Down, but it's much faster on screen when I already have the hand on the mouse and the window maximized (because of Fitts's law, the scrollbar has infinite width, while the keys are small).
- Dragging around up and down in a long page to a different part of the document, in almost instant time. I HATE with all my strength how mobile browsers and apps have eliminated that option. Dragging a moderately long page to find a particular section (in, say, a Wikipedia article) with the touchscreen's physical scroll is a pain in the ass, and slow as molasses because the max speed is also capped at a low value. Is it that hard to show a drag handle after the drag event has started, and hide it when it ends?
This is why I gave up my second monitor.
My Fitts's law analysis happens on a target platform and not my development system.
Could you elaborate?
Fitts' Law inspired my work with pie menus [1] and gestural direct manipulation user interfaces over the years. [2]
[1] Pie Menus on Wikipedia: https://en.wikipedia.org/wiki/Pie_menu
[2] An Empirical Comparison of Pie vs. Linear Menus; CHI'88; Callahan, Hopkins, Weiser, Shneiderman: http://www.donhopkins.com/drupal/node/100
One rule of thumb which abides by Fitts' Law that I try to follow is: "the user's attention should not be squandered". [3] (So I apologize for being so verbose.)
[3] BayCHI '98 talk: Natural Selection: The Evolution of Pie Menus: http://www.baychi.org/calendar/19981013/
My goals have been enabling designers and users to easily create and edit their own pie menus, and providing smart editors, automatic layout, and support and guidance to help humans come up with easily memorable, Fitts'-friendly designs.
This demo of an old OLE/ActiveX implementation of pie menus in Internet Explorer [4] shows the weakness and complexity of the traditional desktop gui MFC based approach to creating and editing pie menus with typical property sheets, scrolling lists and tree editors.
[4] ActiveX Pie Menus: https://www.youtube.com/watch?v=nnC8x9x3Xag
When editing a scrolling list or tree of items, it's difficult to visualize the directions, which change when you add or remove items. As the antithesis of direct manipulation, it takes far too much pointing and clicking to indirectly edit a pie menu via a scrolling list or tree control.
Entering an indented outline into a text editor is an easy way to quickly define and edit a tree of pie menus and submenus, but it doesn't give you a good way to edit properties of each item. Of course describing menus in XML is great if you're a web server, but not fun for human beings.
I tried to combine these different techniques of editing pie menus in a tabbed dialog, with a scrolling list and controls for editing items, a tree of nested items and a graphical preview, a text editor for entering nested items as an outline, loading and saving XML.
But the result was a horribly unwieldy Frankinterface's Monster, difficult for a professional UI designer to use, and impossible for end users to use.
These jQuery pie menus have a more evolved, web friendly design, but I haven't made an editor for them yet. Here's the documentation [5] and free open source code [6].
[5] jQuery Pie Menus Documentation: http://www.donhopkins.com/mediawiki/index.php/JQuery_Pie_Men...
[6] jQuery Pie Menus Source Code: https://github.com/SimHacker/jquery-pie
In the newer jQuery version, one change from previous designs is that I'm de-emphasizing the idea of "menus", and just calling them "pies", because I believe that framing pies as menus has too much historical baggage, does not emphasize their gestural, direct manipulative qualities, and precludes thinking of them more like a directed graph or geographical map, instead of a hierarchical tree.
The jQuery and Unity3D [7] versions also differ from previous designs by modeling pies as containing directional slices, which themselves contain linear items, instead of pies containing items directly, and laying out all items in different directions, which change whenever you add or remove items.
[7] Uni...
Maybe it's because they don't lend themselves to scanning and sorting. It's easy to sort a list of items alphabetically, and it's easy to scan a list by moving my eye down across it, requiring nearly no horizontal eye movement to read the words. But a pie menu does not lend itself so naturally to alphabetical sorting, and scanning requires circular eye movement, which is less economical.
It also has seemed to me that pie menus don't lend themselves as well to memorizing where entries are, perhaps because of the sorting issue. I can remember that a word starts with A and is at the top of a list, but remembering where a word belongs on a compass or clock face doesn't seem as natural, unless the associated action is itself directional (up/down/left/right, north/south/east/west etc).
Here's an example which comes to mind. Team Fortress 2 has quick-access voice lines which can be played with two keypresses, one to open one of three menus, and another to select a line from the menu. They are displayed in a compact list on the left side of the screen.
A newer game coming out soon, Overwatch, also has quick-access voice lines, but they are accessed through a pie menu that covers the entire screen, and items are selected with the mouse.
When I haven't played TF2 for a while, I can be running around the map playing the game, hit one of the keys, and scan the list of commands to find the one I want so quickly that I don't even have to think about it; my eye can sweep across the list in one motion. I just open a couple of the menus and then hit the key, all while running around the map, turning my character with the mouse, etc.
In Overwatch, this doesn't work at all. If I don't remember where a command is on the pie, I have to move my eye in a circle the diameter of which is nearly the entire height of the screen. This takes significant time and effort compared to scanning a list. It also blocks the screen, and it prevents the mouse from being used to control the character.
So, for actions and menus that are primarily directional in nature, and limited in number, I can see pie menus being a natural choice. But for menus that are non-directional, and especially ones that don't lend themselves to memorization, pie menus seem objectively inferior to simple, vertical lists.
To handle those inevitable cases, the jQuery pie menus (and other implementations [1]) can support a hybrid mixture of directional pie items and traditional linear items, by simply adding multiple items to the same slice.
[1] Pie Menus on Python/GTK/Cairo for OLPC Sugar: http://www.donhopkins.com/drupal/node/128
Multiple items in the same slice are just laid out vertically (or horizontally, or even diagonally) in the slice direction, and they can track based on entering/exiting rectangles just like a linear menu, or by the distance (like a pull-out font size menu, etc) [2].
[2] Pull-out Font Pie Menu: https://youtu.be/R5k4gJK-aWw?t=2m10s
I've also tried various forms of spiral scrolling [3], paging [4], and weird springy things [5]. And also limiting the maximum number of pie items, so the first eight "most important" items are assigned to different directions, and subsequent items are laid out below or above the menu as linear items.
[3] Scrolling NeWS Pie Menus: https://youtu.be/kxkfqgAkgDc?t=2m34s
[4] Paging ActiveX Pie Menus: https://youtu.be/nnC8x9x3Xag?t=4m44s
[5] Weird Springy Thing: https://youtu.be/mOLS9I_tdKE?t=2m49s
Some people remember things spatially, and other people don't. The Greeks invented a spatial memorization technique called the Method of Loci. [6]
[6] Method of Loci: https://en.wikipedia.org/wiki/Method_of_loci