This principle seems obvious, but there are too many interfaces that violate it. Thus, a blog post.

If an interface element exhibits some hover effect, the element should be clickable. If an element is clickable, it should exhibit some hover effect. The element’s hover and click areas should match down to a pixel.

Here are some of the mistakes I’ve seen:

• A website main menu is composed of links, each wrapped into a container. The containers style includes a hover highlight. The containers are slightly bigger that the links because of paddings. Within the paddings themselves, the highlighting works, but the links do not.
• A link underlining is implemented so that clicking precisely at the line itself does not cause the link activation even though there is a hover effect. In some cases, it happens the other way around, too: there is no hover effect, but clicking works.
• To dismiss a modal popup dialog, you can just click outside of it. When the dialog is shown, the hover effect of the elements around it continue to work, even though clicking them will just dismiss the popup and not trigger the associated action.
• An element’s action is disabled by a script, but the hover effect remains. For example, a form’s submit button is disabled because of an incorrect value in some field, however is still reacts to a hover as if it worked.
• A large box with a picture and a heading is clickable as a whole and exhibits some hover effect. In the box’s corner, there is a small icon that does something else, say, adds the object to “Favourites”. When hovering the icon, the box’s hover effect remains, even though clicking the icon will not trigger the action, associated with the box itself.

Here is my talk from FDConf, Minsk about feedback in the user interface:

A slider is a simple user interface control where you adjust some value by dragging a handle in a groove:

Most web developers can’t get it right. You may think that there is not much you can fail at with such a simple thing. But most sliders are bad. They don’t respect the Fitts’s law and don’t provide decent feedback.

I decided to write a manual. Let’s see what usually goes wrong and how to fix it. If you are reading this via RSS, please go to the browser to see the demos.

Fitts’s law

Common mistake is requiring to grab the handle to drag it. Logically, this makes sense. But a small handle is very hard to grab. Try here:

A tiny bit better is making the groove clickable:

But in this design the groove is so thin that it hardly adds anything — aiming is still a pain, particularly on a touch screen. Speaking of touch screens, some implementations would just forget about them and not handle the touch events.

You should be able to grab the handle from any point in the slider area:

Make this area at least as big as a comfortable button would be. Notice how the areas to the left and to the right of the slider also work, moving the slider to the minimal and maximal positions.

Feedback

In all the examples above the mouse cursor was changing to a pointing finger when you hovered over the draggable area of a slider. Sometimes this feedback is absent or inconsistent. Here, you can drag from anywhere, but the mouse cursor changes only over the handle:

Having no sign that the slider would work otherwise, many users would try to grab the handle. An even worse mistake would be requiring to drag the handle but displaying a pointing finger over the whole slider area.

Use feedback consistently, change the cursor over all slider area and make it all work:

The change of the cursor is the minimal feedback necessary for the user to understand how the slider works. But it’s better to also highlight the slider itself:

Notice how this one just feels nicer to use.

A small detail: the slider gets its red “hover” highlight, but also keeps it while being dragged, even when mouse is outside.

Continuous feedback

The slider should move continuously as I move the mouse. Some implementations would only repaint the slider when I release the mouse button:

Others would accept clicks in the whole slider area, but only move the handle to the click position instead of grabbing it (unless you grab the very handle):

Both feel broken.

The slider is usually there to control something else. In this case, the rectangle to the right of it. In some implementations, the slider would move continuously, but the external changes would happen only on release:

Everything should stay in sync: hover effects, the cursor shape, actual active areas; reaction to click and drag; feedback inside and outside the slider.

Feedback and slow data

Sometimes it may take noticeable time for the changes in slider to take effect somewhere else. You may need to make complex calculations or get data over the network. You may think you just can’t provide continuous feedback in such cases. But you must still aim to provide as much continuous feedback as possible.

In my examples, the slider controls the numeric value and the background colour. Let’s pretend they are slow to update.

In the worst implementations, the slider would get repainted only when the data is ready:

This is painful to use.

At least the slider itself should repaint continuously during the drag, no matter how long it takes for the change to take effect:

But we can do better. To fake continuous zooming, Google Maps shows at least a blurry map image (see my post on immediate feedback when data is unavailable).

What if only the colour is slow to update, but the number can change instantly?

Again, compare with the previous implementation — this one just feels snappier. So: always consider at least partial continuous updating. This is much better than waiting for a full update before making any change.

Notice that the data updates as fast as it can without the need to release the mouse button. If the data takes even more time to update, some progress indicator may be used, but the slider should never become unresponsive.

Reference implementation

There are too many sliders above. Which are the good ones?

This is the best, with full continuous feedback:

This is the second best, with partial continuous feedback when some data needs time to update (colour, in this example):

Please show this to your web development team.

Immediate feedback is one of the core principles of good user interface design. But what if the data is unavailable for the feedback?

When you increase the zoom level in Google Maps, you see the enlarged view of the data you had already downloaded:

And a couple of seconds later the view updates:

While blurry maps suck, having to wait for several seconds before seing anything would suck much more.

Another example would be Apple’s Safari on the first iPhone. The device had so little memory, it could not fit a whole webpage into it, so it had to render only the parts you were currently looking at. When you scrolled past the rendered area, you saw a checkerboard pattern:

And a couple of seconds later the page rendered:

While the pattern is not much fun to look at, this design is significantly better than if the browser would have to wait until the data was ready before responding to your touches.

Lesson learnt: when you cannot respond with a precise result immediately, show an approximation immediately, then the precise result a moment later.