Independent bimanual operation requires separate onset, offset, and engagement state machines
Aliases: per-hand state machine · independent onset · bimanual engagement
What it is
For the two hands to operate independently, they cannot share one “gesture started / ended” flag and one “engaged or not” switch. The left hand can keep pinching an object while the right still opens a menu or confirms, without clearing the left hand's hold. That requires a state machine per hand for onset and engagement, not a global lock that queues whoever is busy. The issue is isolation of state, not permanently pinning functions to a side: even if both hands have the same role, simultaneous work still needs two machines.
Why it happens
Mid-air gestures have no hardware interrupt analogous to finger-up. Onset and offset are the recognizer segmenting each trajectory. If the implementation has one isPinching and one engaged, a release on the second hand is written as “the pinch ended,” and an in-flight drag commits or cancels. If engagement is also global, dropping one hand is treated as the person leaving, and the other hand's continuous adjustment is cut off. The sound model is: each tracked hand owns its onset, hold, offset, and engagement; the global layer handles inter-person arbitration or application transactions, and does not merge the two hands' instantaneous state. Two machines also mean two timeouts and two undo granularities: releasing the left hand should end only the left hand's stroke.
Studying it
Design overlap in time: the left hand holds a slider while the right fires discrete commands during that hold. Compare a global single-state implementation with per-hand state. Dependent measures include whether the left-hand adjustment is interrupted, false commits, and whether users report “I was still pinching—why did it jump.” Add a condition where one hand briefly loses tracking and see whether the other hand's state is reset with it. Do not test only alternating hands; that task cannot reveal missing isolation.
Where it stops holding
When both hands always do one symmetric job (a shared scale, jointly cradling an object), the need is coupling, not isolation; two independent machines split one object into two. A hand that is only bracing the body and not inputting does not need its own engagement. A headset that adds a third stream (controller plus empty-hand tracking) becomes three machines; an undeclared third stream is a common leak. Multitouch on glass already isolates by contact ID; moving that assumption into mid-air without a lift event means isolation has to be built.
Applying it
- Keep onset/offset and an engagement flag per tracking ID. Forbid a single boolean for “the user is gesturing.”
- State explicitly what happens to the other hand's in-flight operation when one hand is lost or released—continue, freeze, or commit—and make that policy visible in the UI.
- Regression-test with “left hand stays down, right hand taps three times”: the left-hand value must not jump or commit; the three right-hand taps must count as three, not one.
Related
- Same group: C4.18.1 Some systems bind functions to the left or right hand, giving the other hand a different role · C4.18.2 Hand-role binding requires continuous correct left-right identification; errors swap functions · C4.18.4 Handedness differences mean default left-right bindings may not fit left-handers
- Adjacent: C4.03 Gesture onset and offset detection · C4.15 Conditions for entering engagement
- Search:
bimanual state·per-hand engagement·gesture onset offset