Tangible interfaces are hard to undo and copy
Aliases: physical undo · token copy · irreversible grasp · snapshot sandbox
What it is
On a screen, undo pops a window back a frame; copy makes another without touching the original. A token pushed to a new cell leaves the last cell empty; “undo” means remembering where it came from and pushing it back by hand. Tangibles resist undo and copy because of uniqueness and inertia: one geometry cannot sit in two places, and a history does not restack itself. This is not a sync failure. Even when both copies of state agree, the editing primitives still lack time-travel and “make another.”
Why it happens
Digital undo stores a state vector on a stack; the display can teleport. A tangible’s state is the brick’s pose. If the stack lives only in software, playing undo does not walk the piece back—unless an actuator or a hand does. Copy is harder: one physical instance cannot split without introducing a new object. “Copy” becomes either a shadow on a screen (representation and control split again) or a demand for a spare avatar in the box. With several people it is worse: whose step should undo revert, and who grasps the second copy, with no window z-order to lean on. Tangible interaction therefore leans toward constructive, forward placement, not probe-and-revert editing. Probing needs a sandbox or a snapshot; a universal undo key will not appear by itself.
Studying it
Give tasks that need probing (lay out several schemes then pick one; recover from a misplacement) on tangibles and on screen objects.
Independent variables: software undo present, whether undo moves the piece back (actuator or hand), copy as shadow versus a second physical, whether a photo snapshot is allowed. Dependent measures: number of probes, recovery time after a misplacement, rate of abandoning probing for “think on paper first,” whether both copies remain operable after a duplicate.
Final-scheme quality misses process: the tangible group may probe less and commit once. Implementing undo as “software reverted, piece still in the new pose” measures desync, not the undo primitive.
Where it stops holding
Lego-like systems with enough spare parts make copy and revert a cost in hand time, not a missing semantic. Surfaces whose motors can deliver a piece back to a historical pose can approach screen undo, though latency and collisions make people wary. A display-only exhibition table that forbids probing does not need undo. Once the task is “compare three candidate layouts,” missing copy forces serial overwrite and dumps the burden on memory. If the screen side also lacks undo (some embedded panels), the contrast shrinks and the issue becomes the product’s editing model, not tangibility alone.
Applying it
- Do not promise universal undo on a sensed table with no playback hand. Offer an explicit sandbox, a snapshot key, or a short history the hand can push back.
- When side-by-side comparison is required, keep enough duplicate avatars, or freeze alternatives in a photo or projection; do not make people compare against a remembered, overwritten version.
- If copy can only produce a shadow, mark the shadow “look, don’t grasp,” so it is not taken for a second control.
- Verify: give a task that will go one step wrong, and watch how people recover—push back by hand, click undo, start over, give up. If software undo leaves the piece on the wrong cell, the primitive never landed on the tangible. Then ask them to keep two schemes side by side, and count how many avatars are still missing.