Tag Archives: UX

What does Fitts’s law mean for web apps?

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.

Corners and edges are prime screen real estate. (Diagrams: smashingmagazine)

Corners and edges are prime screen real estate. (Diagrams: Smashing Magazine)

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.

Inline-editing

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.

In older Google Docs, you have to move your mouse so fart to complete the rename action.

In older Google Docs, you have to move your mouse so far to complete the rename action.

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.

In-place renaming in Google Docs

Dropdowns/popovers

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.

Pocket app uses a popover to confirm the delete action, which is much easier to target.

Pocket app uses a popover to confirm the delete action, which is much easier to target.

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.

Pocket app uses a modal for editing tags, which makes your mouse cursor travel longer than required.

Pocket app uses a modal for editing tags, which makes your mouse cursor travel longer than required.

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.

Recruiterbox popover form

Final thoughts

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.

References