Infinite Scroll

Back when lists were cut into numbered pages, finishing a screen meant hitting a page number in a row of small links at the bottom. On a desktop screen that was fine. The problem surfaced once small touch screens became the default. Every twenty items you had to land your thumb precisely on a tiny number, and a miss took you to page 5 instead of page 3.

The break was worst for people browsing rather than searching. Someone who came in to see what's there, without a specific item in mind, was forced into a small decision every twenty rows. Riding a train one-handed, missing the number, and rereading the same page was an ordinary experience.

Infinite scroll removes that decision. Inside interaction design it belongs to the input branch — how people operate a screen — alongside gestures and drag and drop. The difference is that those two turn a hand movement into a new command, while infinite scroll hangs loading off a movement people were already making. Nothing new to learn is a large part of why it spread as fast as it did.

An invisible marker sits somewhere below the last visible item, and the moment that marker enters the viewport the next batch is fetched and appended to the end of the list. To the reader the list simply grows; underneath, short lists are being stitched together.

One cycle has four steps.

1. Load the first batch, usually twenty to fifty items. Sending all thousand up front costs seconds of blank screen, and the reader looks at the first ten anyway. The batch size also sets how often the next three steps repeat, so it gets tuned against how fast the server answers.
2. Watch for the marker. Put it a screen or two above the true end rather than at the very bottom. Placed exactly at the end, fetching starts only after the reader has already run out of content and is staring at nothing. Fetching just before something is needed is called lazy loading.
3. Show a placeholder while the request is out — a skeleton UI that draws grey outlines where rows will land, or a small indicator. With nothing there, people read the pause as the end of the list and leave.
4. Append the new items and move the marker to the new end. If existing rows shift position while this happens, the line being read jumps, so scroll position gets pinned during the append.

The last piece is handling the actual end. When there is nothing left, say so once — a line like "that's everything" closes the list rather than leaving it ambiguous. The same goes for a failed request, which needs its own message and a way to retry. Swallow a failure silently and the reader takes it for the end of the list, walking away without knowing they saw half of it.

It suits lists with no fixed end that people enter to browse: social feeds, photo grids, notification inboxes. Nobody is hunting a particular row in those, and nobody needs to return to item 47. Items in such lists also tend to be short and similar in shape, which is what makes reading one long ribbon of them comfortable.

Three situations fit it badly.

1. Lists where items get compared before one is chosen. Weighing three products means moving back and forth, and going back in an infinitely scrolled list means scrolling down from the top again.
2. Screens with fixed content underneath the list. Support links or terms parked at the bottom become unreachable once the list keeps extending.
3. Screens where the count is part of the decision, like search results. "234 results" plus page numbers is what tells someone whether to narrow the query.

Accessibility problems come attached. Accessibility means designing so the product works regardless of disability or circumstance, and someone navigating by keyboard has no way past a list that keeps growing to whatever sits below it. The common compromise is a load-more button: two or three batches append on scroll, and everything after that waits for a press.

"Feed goes infinite, search results stay paginated."

Browsing screens and searching screens get handled differently.

"If we go infinite scroll, assume the footer is gone."

Nothing in a fixed region below the list stays reachable.

"Without scroll restoration, every trip into a detail page dumps you back at the top."

The list-to-detail-and-back flow breaks.

At Pagedeck the argument landed on the document list. Noa brought a scrolling version, and Theo's first question was how the position would be restored on the way back. Opening a document and returning to the list happens more than ten times in one session on that screen, so bouncing to the top each time would be worse than the numbered pages had been.

Mia drew the line by screen purpose. Recent documents is a browsing list, so it scrolls. Search results needs a count and a position, so it kept pages. Remembering both the scroll offset and how many batches had loaded became its own ticket, because restoring the offset without restoring the batch count lands the reader at a position the list hasn't filled yet.

The most common mistake is expecting infinite scroll to keep people around longer. Removing a click should mean more items seen — a reasonable guess, and on a feed built for endless browsing it often holds. For someone who arrived with a purpose it works the other way. Once they scroll past what they wanted, the only way back is scrolling up, and after that happens twice they switch to search or leave. Applied to every list without checking what the screen is for, it raises exits rather than time on page.

Reading it as the modern replacement for pagination is almost as common. These aren't two generations of the same thing; they are two purposes. Page numbers also carry information — which slice you're on, how many there are in total — and on screens where that information matters, numbers are still the right answer. Choose by what looks current and readers lose their place in the search results.