Selected and hover states must be distinguishable
Aliases: selection state · persistent state · transient state · pointer hover
What it is
A selected state means that an object belongs to the current selection, scope, or persistent view. A hover state means only that a pointer is presently over it and disappears on departure. Both can make an element prominent, but they answer different questions: selection asks what has been committed; hover asks what is being pointed at. Reusing one fill, outline, or popover for both makes it unclear whether moving the pointer changes an outcome and which objects are actually selected.
Why it happens
People infer command consequences from visual state. Hover is transient and exploratory, often previewing clickability or extra information. Selection persists across pointer movement and may be consumed by a later command. Identical appearances turn a momentary perception into an apparent system state. In lists, maps, and toolbars, people can mistake a hovered item for the target of delete, share, or batch edit—or think selection vanished once the pointer leaves. The ambiguity also denies keyboard and touch users an equivalent account of state.
Studying it
Ask participants to hover for information, move away, select, and then execute a command. At each stage, elicit which objects they believe will be affected; record wrong targets, hesitation, and undo. When comparing styles, control density, pointer speed, single versus multiple selection, and command consequence. Static preference review is insufficient: test dynamic cases where the pointer crosses selected items, focus changes, and tooltips appear.
Where it stops holding
Controls without persistent selection semantics do not need a fabricated selected state. Conversely, touch and keyboard interaction lack mouse hover, so critical information cannot live only in that change. The difference should not depend on a single perceptual cue or make the states look like unrelated components. Editors may also have focus, active item, preview, and disabled states; define how each changes command behavior rather than calling every emphasis “highlighting.”
Applying it
- Specify the lifecycle and command consequence of each emphasis: whether it disappears on pointer exit, survives focus movement, and receives batch operations.
- Give selection a cross-input persistent cue and hover a transient exploratory cue; both must remain legible when concurrent.
- Provide touch and keyboard routes to equivalent information, such as selected-item summaries, focus indication, or explicit preview.
- Test real batch actions after pointer movement. Any prediction that treats a hovered item as selected is a state-design failure.