K4.03.1occlusion-free rotary inputdesignresearch

Rotary input does not occlude the display

Aliases: Digital Crown · bezel scroll · off-screen rotary

What it is

A crown or rotating bezel puts the finger beside the glass, so the row that is changing stays visible while a list moves or a continuous value is tuned. Touch cannot do that. On a ~40 mm face the pad covers the very item that must be read; people lift, look, then move again. This entry is only about occlusion. It is not about which data rotary suits, and not about which way clockwise should map.

Why it happens

Usable area on a microdisplay is the same order as a fingertip. A tap already eats a large patch around the target; a swipe walks the pad with the content, so feedback happens under the finger. Control becomes intermittent: move, lift, look, re-aim. Rotary moves the actuator to the case or the bezel; the display only displays. The loop becomes continuous: content moves while turning, and the eyes can watch the target row travel to center. Rotary is not “more precise.” It splits perception and execution off the same patch of skin. Without that split, larger hit targets still cannot save “I cannot see what I am selecting.”

Studying it

Compare the same list under touch-drag versus side rotary. From video or capacitive footprints, overlay the pad on the selected row and compute occlusion ratio. Then see whether selection finishes in one continuous motion or needs lifts to look.

Independent variables: input (touch / crown / bezel), row height, case diameter. Dependent variables: fraction of time the selected row is under the pad, look-lifts, selection accuracy, completion time.

Lab index-finger taps occlude differently from a real raise with the thumb; measure on the wearing hand. Do not read “rotary is faster” as “rotary does not occlude”—speed can come from mapping habit. Occlusion has to be argued in covered pixels.

Where it stops holding

If the crown is missing, gloves are on, or the strap covers the rotator, the channel is gone. Touch remains the fallback, and occlusion must be solved another way (keep the selection clear of the finger, float a loupe elsewhere). Pure confirms (start, stop) are one tap; rotary has no occlusion to fix. A square face has a little more tappable rim than a round one, so the ratio drops slightly, still in the “covers the current row” regime. Children and wide pads occlude more; do not accept with the designer’s own hand.

Applying it

  • For long lists and values that must be watched while tuning, put primary control on the crown or bezel; do not require a drag across the content to finish.
  • Keep touch for selecting the current item, going back, and buttons. Do not stack “swipe to browse” and “tap in the same place.”
  • Draw selection across the full row, fully exposed while rotating. Do not use a thin focus ring that only appears under the finger.
  • Verify with slow-motion from the wearer’s viewpoint during a scroll-to-select. If the selected row is invisible until the finger lifts, the path is still using touch for a job rotary should do.

Related

  • Within the group: K4.03.2 Rotary fits linear lists and continuous values · K4.03.3 Rotation-to-scroll mapping must stay consistent
  • Adjacent: C2.05 Finger Occlusion · C1.11 Scroll Wheel and Inertial Scrolling · K4.05 Information Compression
  • Search terms: occlusion · rotary input · Digital Crown

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/K4.03.1