People may act before every chunk has arrived; those early actions have to be handled

What it is

Once ready parts are shown, people will act on them: tap a button that is already there, select a row that is already there, drag a link that is already there. Later chunks are still in flight. Early interaction is not a mis-tap. It is a legal consequence of chunked loading. The system has to decide what that click means — send it against the part that is already complete, queue it until a dependency arrives, or refuse it explicitly — and must not wait for people to sit on their hands until 100%.

Why it happens

Visible-therefore-usable is the default mental model. A button that has been drawn is taken as live. Progressive rendering splits “drawn” from “dependencies complete”: the price has not arrived, the buy button is already there; the permission bit has not returned, edit is already tappable. People act on the visible model; the request hits an incomplete state. Outcomes: a submit at the wrong price, a permission that later returns and declares the act illegal, or a click landing on coordinates that another control will occupy in a moment.

There are three ways to handle early interaction. First: every visible control has its dependencies met; the tap does the thing, and later chunks must not rewrite what that act meant. Second: dependencies unmet, the control is drawn unavailable with what is missing named, and early interaction is stopped at the UI. Third: take the act, wait for dependencies, then run it, and let people see it is queued. All three can be coherent. The disaster is a fourth: it looks tappable, and the tap enters an undefined half-state.

Where it stops holding

Read-only scrolling and copying text that has already arrived are almost always safe early; they need not wait for later images. Irreversible, paid, or deleting acts should not take “accept then queue” when a dependency is missing, unless the queue can still be changed or cancelled before execution. If a later chunk will insert a new control on the click’s coordinates, the early click may hit something that exists only in the future — kill that with reserved space, not by banning all early clicks. Assistive users may land on not-yet-ready controls earlier than visual users (focus enters a button mounted first); the disabled state must enter the accessibility tree, not live only as a visual grey.

Applying it

• List the chunks each tappable control depends on. Unmet: the control is unavailable, with a reason. Met: the click takes effect immediately and later content does not change its meaning.
• If queuing, show “will run when loading finishes”, and allow cancel before it runs.
• Do not leave the primary button in its default tappable look while price, stock or permission has not arrived.
• How to check: block the price endpoint and tap Buy now. If an order goes out at a default price, or into an unexplainable in-between page, early interaction was not handled. Block the rail and tap a main-column link; the main-column act should proceed, not wait for the rail.

Related

• Same group: I2.11.1 Progressive rendering must reserve space for chunks that have not arrived, or the layout will shift · I2.11.3 A presentation cadence that is too fast makes people think the content is complete and miss what still arrives · I2.11.4 Every step of chunked presentation should be a coherent usable state, not a half-built product
• Nearby: I2.03 Chunked loading · I2.06 Cancel during wait · I3.02 Optimistic updates
• Search terms: early interaction · partial page action · click before complete