According to Fitts’s law, the time required to move a pointing device to a target is a function of the distance to the target and its size. In simpler words, the closer and larger a target, the faster it is to click on that target.
When I first heard about it, I was really fascinated by the idea, though it sounds rather obvious in hindsight. I wondered what exactly it means for web apps. (If you are new to Fitts’s law, try this interactive demo).
Prime Pixels Not Applicable To Web Apps
One of the inferences of Fitts’s law is that the easiest areas to click on a screen are the corners and edges of the screen, as you can simply throw your cursor in that direction without overshooting.
But, unfortunately this cannot be applied to web apps, as the edges of the web browser are not always the same as the screen’s edges (unless the app is in full-screen mode).
Still, Closer Is Better
Still, there are other things in the UX that could be improved using Fitts’s law. For instance, modals (lightboxes, overlays or whatever) have been a common way of getting user inputs in web apps, probably borrowed from desktop apps. Though they are helpful when the action needs complete focus without distracted by other elements on the page, it’s an overkill for most lightweight actions.
For example, until a few months back, if you tried to rename a Google Doc while editing it, it would open a new modal box.
As you can see, this is not optimal, as you have to move your mouse from where you clicked on the name to the OK button in the modal (not many people use Keyboard shortcuts, even simple ones like hitting Enter to submit a form).
Thankfully Google has changed this behavior recently and now you can do the renaming right there, in place. This obviously feels much more lightweight and takes less effort from the user — no mouse movement and no extra click to save the changes.
Another way of avoiding modals — and hence the long mouse movements — is to use simpler UI elements that appear right next to the element that triggered the action.
In Pocket, when you try to delete an article, the confirmation dialog is shown as a lightweight popover that appears right below the delete icon.
To understand the benefit, you can compare this against the “Edit tags” UI of the same app. When you click on the tag icon, a modal box appears in the middle of the screen, with just an input box and a submit button. For such a simple form, a modal is an overkill.
You could use a popover very similar to Pocket‘s delete confirmation to show this form. Recruiterbox uses a popover-like UI for simple forms, where modal would be an overkill.
I’m seeing more and more places where modals are being replaced with lightweight and closer UIs. However, the legacy probably left by jQueryUI’s Dialogs and carried on by other libraries like Bootstrap is still haunting us in many places.
Even at Recruiterbox, we have been using modals extensively. Only recently did we decide to avoid modals except for a few actions that require richer forms. Hoping to see more things move in this direction.