Later content must not shove what is already on screen

What it is

Once ready parts are painted, people are already reading and aiming at them. If a later chunk arrives by pushing those parts away, down, or into a new hit region, the first paint’s credit is cancelled by the second. The principle: geometry already presented stays stable for the user. Later content goes to space that is not yet occupied, or replaces a region still marked as a slot — it does not shove a region that is in use.

How to leave pits for chunks that have not arrived, and how to handle early clicks, are consequence problems in the progressive-rendering group. This leaf only installs “no shoving” as a constraint on load order.

Why it happens

The moment someone finishes orienting on presented content — where the title sits, where the first paragraph starts, the coordinates of a button — that orientation is working memory in use. A late image expanding above, an ad bar inserting, a comment block suddenly growing, voids every coordinate in that memory: the eyes re-find the line, the finger lands on a new owner, the sentence being read is pushed out of the viewport. Cognitive work that “paint first” meant to start early is interrupted by its own later arrivals. The net can be worse than waiting for the whole, because people were started and then driven off.

Shoving is not a bounced skeleton cheque. A skeleton bounce happens on one wait’s last frame, one cheque. Here several cheques are cashed over time: the first has already been paid out to someone using it, and the second rewrites the first’s layout. The constraint is therefore temporal: a late chunk has no write permission over an early one, unless the early one is still declaring itself a placeholder.

Where it stops holding

Changes the user triggered (expand, filter, rotate) are not later content shoving — the person is changing layout. Insertions in unread regions — a footer far below the viewport — do not interrupt current work, but they still spoil scroll-position expectations when the user gets there, so they are not free. Content that must land inside an already-presented region (an inline verification badge) should replace a slot rather than push neighbours; if there is no slot and insertion is mandatory, the “present first” principle yields — paint them together a little later rather than knife the text after reading has started. Animating the shove into a slide still drops the coordinates; it only looks polite.

Applying it

• Default late chunks to regions that are not yet reading or pointing targets, or into slots still marked empty. Do not insert unannounced at the top of an already-visible main column.
• Media that will appear inside the viewport must not enter by growing height from 0 to real.
• If shoving cannot be avoided, do not paint that chunk alone: bind it with the neighbours it would move into one presentation.
• How to check: let the main column complete, start reading or rest a pointer on a button, then release a large top image. If the button is pushed away or the line being read leaves the viewport, later content is shoving what was presented.

Related

• Same group: I2.03.1 Presenting what is already ready beats waiting for the whole · I2.03.3 Chunk order should follow importance
• Nearby: I2.11 Progressive rendering · I2.01 Choosing skeleton versus spinner · I2.05 Lazy loading
• Search terms: layout shove · stable presented content · late chunk insertion