Hacker News Reader

Comment by afandian | Hacker News Reader

The challenge is to retain an ordering over the result set. How would infinite scroll behave any differently in this case? The changing results seems to be an orthogonal concern to pagination/infinite scroll.

View on HN

Infinite scroll makes the problem much easier, even if it’s still a problem. The only action you need to support is loading more results, which you can do by loading all results and filtering out those already shown. With pagination, the user may say “give me page 3” and you have no idea what was on pages 1 and 2, if they were even loaded.

If page 1 and 2 were 10 each you load results 21-30

Same as if you are scrolling and have reached result 20 And want to load more.

But the underlying table changed since. I'm not very familiar with these myself, but it seams to me that the best solution is to keep a session cursor for the user, and these are a lot simpler when you only ever move it forward.

It's slightly different but I don't see why there should be a notable difference in difficulty. You need to somehow represent what you saw so far and act based on that.

With infinite scroll, “what you saw so far” is in the client. With pagination, it exists only in the user’s mind.

Is the client sending that info back to the server every time it requests more posts? You can do the same thing with pagination. Embed a list of post IDs into the next button.

There's potentially a difference if the server's sending repeat posts and you're doing client-side filtering of what to show next. But do any sites work that way?

(And of course these issues only exist when your list of results changes order. It the list merely grows then you can paginate with start=xxx)

IMO "pages of search results" is one of the problems where the closer you look, the more potential problems and inconsistencies you see until you realize it's a leaky abstraction, and sometimes it gets too leaky.

We want visitors to imagine that we just plopped a binder of sorted results down in front of them for their page-by-page perusal, but the suggests permanence and invariants we don't want to provide (because it's harder.) For example, the assurance that page 2 will always have the same items on it unless they "search again", and the last item on page 2 will not not duplicate itself on the top of page 3 as they page forward.

By way of contrast, imagine a system where a result-set was not just a UI metaphor, but real domain concept. Do a search, and you get a Result which is a limited-size listing generated at time X for user Y and will be cached for Z.

I mean sure, if you do it that way. But its easy to encode the page starting index and pagenate from there. Its even exactly the same algorithm as infinite scroll.

You can implement pagination exactly the same way. It's a UX decision that has nothing to do with underlying queries, although it typically maps.

The typical infinite scroll that I've seen implemented does not work the way you describe though, it's just pagination without controls. The reason it works is because it's pushing content you never asked for anyway and it just keeps pushing. Without any sense of pages you'll never know the difference.

Just use really long pages and require them to hit next page after viewing 100 items, then start showing the next batch of feedslop. How is that changing anything?

Users know that they are scrolling endlessly, they just don’t care. Adding a “more” button every now and then isn’t going to change that.

Just use cursor based pagination. How is this any different whether it’s infinite scroll or separate pages?

I guess the argument is that, while it's the same whether the user asks for "give me page 3" or "give me scrollbar Y coordinate 2160", the user is more likely to do the first or at least to care about the correctness of its result?

Why does the user need to see a page number? You could just show a “forward” and a “back” button. Keep records of what they’ve seen recently so you can replay prior pages. If they view too many pages just silently drop earlier pages; it’s a feed, not a perfect paginated list.

Cursor based pagination only works if the items are sorted in strict chronological order. Otherwise, the problem remains. Consider the list

  [A B C] D E F G H …

where the brackets represent the first page. If the user clicks the next page button (asking for the next page after C), but meanwhile the order changed, they get this:

  A D C [B F E] G H …

Notice how they now see B twice and completely miss out on D. In constrast, infinite scroll will take the new infinite list and remove A B C, leaving D F E …

Reply on news.ycombinator.com