The button recedes as content grows
Aliases: moving target button · end-of-list control
What it is
Load more is pinned to the end of the current batch; each successful append walks the button further down the document. A receding load-more button is a target that runs away: easy to hit the first time, and by the third time you have to cross the stretch that just grew. This is not whether the latch still preserves control, and not whether the pattern fits a footer-bearing catalogue. It is whether the next click is still in the hand.
Why it happens
Cost to a target grows with distance. The button always sits at “the bottom of what is loaded”, and “the bottom” is pushed farther after every successful press. Continuing means first consuming the new batch (at least scrolling across it) before the button can be touched again. For browsing that is reasonable — new content should be seen — but when someone has already decided to take three batches, or is hunting one item and would skip the middle, recession becomes an obstacle: they are forced to re-scan at append granularity and cannot treat the button as a stable “again” handle.
Layout shift adds to this. If a large block is inserted above the button, it slides out from under the pointer or thumb, producing a miss or a tap on the newly inserted last item. If the button vanishes during load and reappears farther down, the rhythm of repeated clicks breaks and some people conclude there is nothing more. When a virtualised list recycles DOM, the button can even cease to exist briefly during scroll.
Where it stops holding
When a batch is about one screen, the recede distance is close to a page turn and the runaway feeling is weak. When batches are very long, the next click can be so far that it needs a dedicated scroll-to-end, and the button is almost a hidden control. Pinning the button to the viewport (floating on the list’s lower edge) stops the runaway, but covers the last rows and is easier to miss-tap — trading occlusion for a stable place. Keyboard users who Tab to the button and activate it lose the next activation if focus is shoved out by the new content; recession then becomes “focus was crowded off”.
Applying it
- Keep the button at the end of the document flow, but do not remove it from under the pointer during load: occupy the same slot with an in-progress state, then move with the new end.
- Offer a continue path that does not depend on finding the button: a keyboard shortcut, “load another batch” while it is still visible, or a jump to the current bottom.
- If the button remains in the viewport after insert, keep its place relative to thumb or pointer so a click in flight does not fall on empty space.
- How to check: take three batches in a row and record how far someone must scroll before each press. Distance that only grows, with no other continue path, is a runaway. Also watch the instant of append for the button sliding out from under the contact point.