C10.05.2tangible-digital state desyncdesignresearch

Physical and digital state can fall out of sync

Aliases: token desync · stale tangible · physical-digital split · tracking loss

What it is

The token still sits on the harbor; the database’s ship has sailed. The fader still reads −6 dB; the software has recalled another scene. Tangible–digital desync is one object with two bodies walking apart: the geometry the hand sees is no longer the copy the system treats as truth. The premise that representation and control are bound splits here. This is not “the piece is awkward to grasp,” and not undo difficulty as such. It is which copy is in charge, and which side people trust once they diverge.

Why it happens

Digital state has almost no inertia: recall, a network update, someone editing on another screen can change the value without the object being touched. Physical state must beat friction and pose; it can also be misplaced, knocked, taken away to charge. Sensing misses: vision fails to see a move, and the system still thinks the piece is where it was. Three rifts follow—the system changed and the object did not; the object moved and the system did not see; the object left the sensing volume and the system kept the last value. People default to the geometry in the hand, because grasp is faster than reading a display; when that geometry is stale, later actions run on the wrong world model. Bidirectional sync needs actuators to push pieces, and most tangibles only sense—they have no hand that can walk a block back to the “correct” pose.

Studying it

Stage the three rifts on purpose and watch which side people trust first, how long until they notice, and how they repair.

Independent variables: rift type (software recall / missed move / object off-stage), presence of forced registration (lights, magnets pulling the piece back), whether on-screen numerals may be viewed. Dependent measures: actions taken on stale geometry, time to notice the rift, repair by hand versus by clicking, whether it rifts again.

Natural observation yields sparse rifts; the lab has to script recall, occlusion, and removal as repeatable events. Satisfaction scores miss “I never noticed.” Eye tracking helps show whether the noticing glance went to the display or to an empty cell.

Where it stops holding

Purely mechanical objects with no digital twin (an analog console that cannot recall) have no such rift, only the mechanism’s own pose. Surfaces driven only by actuators, which a hand cannot pose, invert the rift: the display may be right and the haptics get corrected by motors. Short demos where pieces never leave the sensing volume and never recall hide the problem. With several people each on their own object, a rift may hit only one token while the table “looks synced.” Power-off then power-on after the pieces were tidied almost guarantees a split.

Applying it

  • Any operation that changes digital state without moving the object (recall, remote edit, auto-calibration) must either signal “this piece is stale” strongly, or refuse to run until registered.
  • Treat sensing dead zones, charging removal, and occlusion as lawful states: off-stage becomes explicitly untracked, not a reuse of last coordinates.
  • If an actuator can walk the piece back, register that way; if not, give an explicit one-shot choice: “trust the object” or “trust the software.”
  • Verify: run one scene recall, one occluded move, and one removal; count how many actions run on stale geometry before the rift is noticed. If people must always notice for themselves, the sync policy is not working. Test power-on after the pieces were moved as its own case.

Related

  • Same group: C10.05.1 A physical object is representation and control at once · C10.05.3 Tangible interfaces are hard to undo and copy
  • Adjacent: C10.06 Shape-Changing Interfaces · C10.13 Mode Problems in Multifunction Physical Controls
  • Search: state desync · tangible tracking · physical-digital consistency

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/C10.05.2