Implementing a slider well

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.


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.

You should follow me on Twitter, here

Jun 21   feedback   user interface

Mimic 2.0: The client’s feedback

I’ve recently designed the new user interface for Mimic, a web developer tool for mocking server responses in a browser. Ilya Gelman, one of the Mimic’s developers, comments on working with me:

Ilya is of that rare kind of designers that seek to find solutions to problems instead of matching colors and shadows. He asks the right questions, concentrates on important things and understands that real products aren’t just beautiful pictures on dribble. He helped us redefine our tool to make it simpler to use and easier to understand.

Working with local Israeli designers, we usually communicated by real-time channels like Slack, WhatsApp or phone. It was a bit different with Ilya because we had to communicate mainly via email and had to schedule our calls ahead of time. Part of this was the difference in time zones and part of it was Ilya’s principle of managing his own time, which I can fully understand and respect. All in all we never had an issue of lack of communication and everything was always delivered on time.

What I liked about Ilya the most is that he was able to explain the reasoning behind his design decisions, and that he knew how to work together with us to get our tool released on time.

Apr 1   feedback   projects   quotes