Direct manipulation and live feedback are treated as the default expectation

What it is

Under Apple’s touch conventions, the object is the interface. Drag a photo, pinch a map, slide a switch: the motion should become a visible change on the object with no intervening Apply. The direct-manipulation expectation treats this as default. People assume the hand is operating the thing itself, not issuing commands to a distant system. Live feedback is the proof of that assumption — the list follows the finger, the switch thumb follows the slide. Delay the feedback, and the object becomes a remote control.

This does not enumerate which gestures the system reserves, and does not discuss back-stack depth. It specifies a timing relation: input and object change should be short enough to count as one event.

Why it happens

Direct manipulation holds through perceptual causal closure: the hand moves, the object moves, the brain codes “I am moving this.” Delay, batching, or submit-then-refresh splits the closure; people switch to a send-command-wait-for-result model. That model is legitimate on a command line or an old desktop dialog. On a finger-as-pointer platform it violates the default.

Live feedback is not decorative motion. Motion can play after the action ends. Live feedback must start while contact is still down. Rubber-banding, a drag placeholder, a slider value that tracks the thumb — all prove, inside the contact window, that the object has been seized. An interface that jumps only after lift, even if the final state is correct, has already charged a “did I hit it?” confirmation cost.

Where it stops holding

Transactions that need a precise commit — a transfer amount, deleting a library, sending an unrecallable message — need a confirmation outside direct manipulation; “one slide sends it” must not be the default. Actions that cannot be zero-latency over the network degrade the expectation to immediate in-progress feedback (placeholder, progress, cancel), not a fake write. For keyboard and search, the objects of direct manipulation are the caret and the list, not the remote document. Hover preview on a pointer is a different channel; do not collapse it with touch-contact feedback.

Applying it

• For continuous gestures — drag, slide, pinch — change the object’s position, value, or preview while the finger is still down, rather than jumping on touch-up.
• For work that cannot finish in place, show in-progress in the frame of the press, and allow cancel or undo before the result returns.
• Keep Apply and Save for true commit boundaries. List reorder, switches, and zoom should not gate on a button by default.
• Verify by recording the device and replaying every continuous gesture in slow motion. Any stretch where the finger is down and the object has not moved is a broken expectation. On a debug build with injected latency, check that in-progress feedback still appears inside the contact window.

Related

• Same group: R4.08.1 Content comes before decoration; the interface yields to the information it carries · R4.08.2 Consistency is gained by using system controls, not by mimicking their appearance
• Adjacent: R4.01 Apple platform conventions
• Search terms: direct-manipulation expectation · live feedback · causal closure