Toolbar toggles need a different look from neighboring action buttons

What it is

Toolbars often put Bold and Italic (toggles) on the same row as Print and Insert image (actions). If both families share one shape, people treat a toggle as a one-shot—Bold flashes and pops back—or treat Print as a switch and click it twice. Toggles in a toolbar must look different from neighboring actions: a persistent selected well, a different chrome, or a group break, so it is obvious before the reach that this one will leave a value.

Why it happens

Controls in one row are treated as one class unless grouping cues break the row. Action buttons train “click and leave”; toggles train “click and see whether it stays lit.” When the chrome is identical, the motor programs cross: an action program on a toggle flips a value without checking; a toggle program on an action waits for Print to stay down and decides it did not fire. A divider, a different fill, a sticky fill on toggles and a ripple on actions, all draw a class boundary. Without a boundary the only cue is the later result, which on a toolbar often lives elsewhere (glyphs in the document), so the loop is long.

Studying it

Compare a mixed toolbar with a grouped one. Tasks include “turn Bold on” and “insert an image.” Watch for insert treated as a switch and Bold treated as a one-shot.

Independent variables: whether the two families share chrome, presence of a divider, whether selected toggles use a different well. Dependent variables: wrong-class operations (fire-and-forget on toggles, waiting for stickiness on actions), later ability to point at which controls hold state.

Experts know particular glyphs, so class errors run low. Include people new to that editor to see the cost of mixed chrome.

Where it stops holding

A format bar that is all toggles (bold italic underline) may share chrome because the class is consistent. A command bar that is all actions may too. Mixing is the problem. An overflow menu that ticks toggles as menu checks no longer uses toolbar chrome; distinction moves to menu convention. A touch editor that puts format on a bottom sheet and insert on another screen removes the mix in the architecture.

Applying it

• In a mixed row, give toggles a sticky selected look and actions a look that will not stick; do not share one background asset.
• Put a divider or a group label between the families; do not rely on icon semantics alone.
• Tooltips may say “on/off” versus “insert,” but only as backup; class should not wait for hover.
• Verify by greyscaling the toolbar and hiding tips: people mark “which ones stay after a click.” Every miss is chrome that did not separate toggle from action.

Related

• Within the group: E1.12.1 A toggle button uses pressed and unpressed to show the current setting · E1.12.2 Assistive technology must see a toggle as a switch-like state · E1.12.4 A toggle’s state must survive a page refresh
• Adjacent: E1.01 Button hierarchy · E1.14 Button groups and split buttons · D1.03 Selection and highlight
• Search terms: toolbar toggle · command versus toggle · grouped controls