Fitts’ Law In The Touch Era
When I started writing the latest book, Touch Design for Mobile Interfaces, I would regularly find an interesting topic or tangent that led far into the weeds, and had to stop myself from pursuing it too far. I didn’t want to become a hermit who dies with a never completed fifteen-volume work on a constantly-shifting topic.
But many of these topics are worth exploring deeper. One that comes up occasionally is Fitts’ Law, and how it works with touchscreens.
That’s because a simple application of Fitts’ Law is known by pretty much all interactive designers. It’s the “bigger targets are easier to click” one. It also says that edges are infinitely deep so easier to click as well.
The problem is, that’s not quite what it says. Fitts’ work is rooted in industrial era assumptions about worker productivity, assumes rigid workspaces, and was designed to improve safety of aircraft controls.
It only applies in one dimension, like how precisely a pilot can move the thrust lever to a specific position, and how quickly. A lot of the derived lessons about mouse use are poorly modeled, and none apply to touch at all.
Moving From WIMP To Touch
Some tips and tricks, taking the current advice — good and bad — for applications of Fitts’ Law to mouse driven systems, and instead giving you the new best advice I can offer, especially for touch.
Convention Wisdom for Mouse and Desktop | Best Practice for Touch and Mobile |
---|---|
Lay out content top to bottom, left to right, with the most important in the top left corner. | People read and interact in the best and fastest way with the center of the screen. Put your key info in the big scrolling area in the middle. |
Watch for the fold, so users can see all the info they need. Distrust scrolling, as scrollbars are far away. | Everyone scrolls, because a gesture is easy and common. Make sure users know that there is more content, but expect them to discover it on their own. |
Keep all control options close for less mouse movement. ‘Cancel’ and ‘submit’ must be right next to each other. | Accidents happen, so keep disparate and especially destructive choices far away from positive actions. |
Guard dialogs (“Are you sure?”) protect from accidental activation well. | Avoid destructive actions at all, and when required make sure they all have undo methods (or fake undo), not guards before the action. |
People are focused on the task at hand, and want speed above all. | People live in the world, so are distracted. Don’t time out notifications or provide limited time to perform actions. |
Edges and corners are infinitely deep, so place menus there for quick access. | Edges and corners are the hardest to tap areas, but are great places to hide low use menus and anchored actions. But just a few; make them big to assure users can tap them successfully. |
Pop-ups are the best, because they can appear under the mouse, so less movement needed, compared to menus and drawers. | Pop-ups are terrible in so many ways, not least, they are disassociated from their context. Place items in the UI, or use drawers, accordions, and other contextual items to select. |
Provide the user with tools to select quickly, including jumping the mouse to the primary action. | Empower the user to make informed decisions. Give them enough information to make good choices. For consequential choices, the delay for moving to the action is good, and provides a moment to think if they actually wish to carry that out. |
Bigger is better, so feel free to pad buttons, and use very long labels for the most important buttons. | Make interactive elements like buttons only as big as needed for the expected location on the screen. Make labels clear and succinct, so users can read them. |
Radial menus are the fastest possible ones, as all options have equal distance from the initial point. | Radial menus loose much of their value when you get away from the cursor, and they are unexpected, so the learning curve gets in the way of their theoretical value. |
Be an Ethical and Deliberate Designer
We always must remember to not blindly accept pithy advice, or to copy what others have done. Instead, ask questions, and consider what particular guidelines and lessons mean to our specific users, in their technology and context, and how they apply to the products we design.