Sliders, an unsolved UI problem.

Everybody loves sliders, and for good reasons. They are easy to understand, they provide useful hints regarding sensible ranges for values, they can display values both numerically and spatially at the same time, and —provided they are wide enough— allow one to change a value both slightly and drastically with the same amount of effort.

Text fields where numbers must be entered using the keyboard, up-down controls where every change requires a click, and dropdown lists where values can be selected from a finite set are far more cumbersome to use. I suspect the only reason we still see them a lot is because they each do one specific thing better than a slider. To wit, sliders have problems with:

• Incrementing/decrementing values by the smallest possible amount.
• Setting very specific values.
• Selecting values from a non-equally spaced set.
• Selecting values without lower and upper limits.

Today I decided that it was time to start work on the core slider class in Grasshopper 2.0, which is going to be a rather  ubiquitous interface element, as indeed it is in the current version, so I need to get this right.

I’m not going to wax on about implementation, or show off any solutions yet (it has only been a day, the GH2 sliders are barely functional), but here is a list of problems I expect good slider design to solve.

1. It must be easy to set a specific value. This problem has been solved in GH1 already, just start typing whenever a slider is selected (or double click a slider if you’re on the canvas) and it is replaced by a text field into which an exact value can be typed.
   The only improvement upon this I can think of is the ability to use voice recognition or stylus OCR to set the value.
2. It must be easy to move a slider to the next or previous allowed value. A slider has a fixed number of decimals, and it is entirely possible that the distance between 0.506 and 0.507 is less than one pixel. Possible solutions include zooming in (not always possible, depends on the UI context in which the slider appears), using arrow keys to nudge the slider left and right, or —again— voice/gestures. A more traditional approach may be to remap the mouse coordinates so that a one pixel motion translates to exactly one epsilon.
3. It must be possible to have preset values along the slider domain that can be snapped to. These presets must support custom names, so that a slider can be dragged from left to right while displaying {…, 0.48, 0.49, half, 0.51, 0.52, …} where “half” would be a named preset.
4. When dragging a slider across a preset value, it must always come to rest at it, so even when there are multiple presets very close together, dragging the slider grip across them must result in each one being visited. This is turning out to be a lot harder than it sounds.
5. Sliders that use small grips without numeric display, must still display the numeric values during dragging, and possibly on mouse-hover.
6. Slider grips must come in various shapes; small without numeric value, box containing numeric value, bar containing numeric value. Furthermore various positions of the box and bar will result in numeric values that do not take up the same amount of horizontal pixels. Specifically when minus signs or preset names are involved, or when using a font which does not have tabular digits, ie. 11.1 is a lot narrower than 88.8.
   While dragging, the width of the grip must never change so it must be big enough to contain the widest possible value.
7. When two or more sliders are stacked vertically, the width of their grips must be identical, or it just looks plain ugly. So it must be possible to bundle sliders together into aggregates and have them be aware of each other’s dimensions.
8. Sliders should have a uniform appearance across the UI, but it must be possible to override specific visual properties, such as fill, background, or font without having to then do all the drawing in a custom function.
9. Value change events need to be specific about whether the change is intermediate or final. If a slider value change is going to kick off a lengthy calculation, developers listening to the slider may want to ignore intermediate events that would occur during slider drags.
10. The user must be able to drag a slider without it broadcasting events all over the place, for example by holding down the alt-key while dragging. Such a ‘silent’ drag must be visually distinct from a ‘loud’ drag.
11. It must be easy for the developer to provide a bunch of meaningful defaults for a slider, and to offer undo/redo support.

The UI kits I’ve worked with in the past written by others meet 3, maybe 4 of these demands. I have yet to see software which treats sliders with the respect and gravity they demand, how is it that something as fundamental as this is still not working as it should in 20 fucking 16?