E3.04.2mixed switch checkbox timing errordesignresearch

Mixing them causes misjudged timing

Aliases: timing misattribution · mixed toggle and checkbox · commit confusion

What it is

If a switch and a checkbox on the same flow speak different clocks, people will paste one timing onto the other. That is timing misattribution: a slider nearby makes a tick look already written, or a page of ticks makes a slider look as if it still waits for save. The error is not failing to see the glyph; it is keeping only one commit unit after two were placed on the same decision surface. The fallout is skipping save when save was required, or skipping an immediate check when the write already happened — client and server one beat apart.

Why it happens

Working memory will not hold two parallel nows. People grab the visually stronger clock as the global rule — a slider’s motion transient is stronger, so the whole page is often read as immediate, and footer save becomes optional. Conversely, a long form of boxes with one inserted switch has that immediate write read as “noted on the form,” gone when the page is left.

The misread also lags across pages. A settings screen trains immediate, and the next checkout form is still treated as immediate — or the reverse. Glyphs become a conditioned clock. When the conditioned clock fights the actual write, people do not slow down and read; they act on the reflex and then blame the system.

Studying it

Have the same people complete a settings screen and a form in sequence, with no briefing on the clock difference. Binary controls on the two screens stay consistent, swap, or mix.

Independent variables: whether the two screens use the same type, the slider-to-box ratio when mixed, presence of footer save. Dependent variables: after leaving settings, whether unsaved items are believed applied; whether another device is checked before form submit; missed saves; match between spoken clock and logs.

The operational definition is when the first “go verify” happens: after the throw, or after save. Early or late verification is the misattribution.

Where it stops holding

Administrators who live in one back office and switch clocks daily misattribute less, not never — a new feature still rides the old reflex. Splitting immediate and submit into labelled zones (live state above, draft below) can blunt mixed use if the headings are actually read. Assistive-tech users follow role and state, so mixed looks hurt them less — unless a switch is mis-exposed as a checkbox, in which case the error changes pipes: they hear a tick and meet an immediate write.

Applying it

  • Do not let sliders and boxes share a decision surface unless a heading states “already in effect” versus “pending submit” in a sentence that cannot be skipped.
  • Keep clock habits across pages: settings flows all immediate, fill-in flows all submit, cut by navigation rather than glued with the same card style.
  • If mixing is unavoidable, let failure speak the clock: sliders snap back, checkboxes stay drafts and point at save.
  • How to check: after a mixed screen, ask which values are already on the server. Each wrong point is a clock dragged by the other widget.

Related

  • Within the group: E3.04.1 Use a switch for immediate effect, a checkbox for submit-with-form · E3.04.3 The two semantics should not overlap on one page
  • Adjacent: E3.03 Switches · D1.01 Immediate operation feedback
  • Search terms: timing misattribution · mixed toggle and checkbox · commit confusion

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E3.04.2