Hacker News Reader

Comment by xigoi | Hacker News Reader

On the contrary, pagination makes it impossible to keep your place in the list if it changes between page loads.

How are you going to keep your place if the order changes anyway? What is your place if the order has changed?

If the order changes, all bets are off regardless of pagination or infinite scroll.

When asked to load more items, simply take the entire list (which may have changed) and remove the items already shown on the screen.

How does that differ from 'when asked to load more items, simply take the entire list (which may have changed) and remove the items already shown on previous pages'?

The fact that, in general, you don’t know what was on the previous pages, if anything. The user may just randomly decide to open page 3 without having visited the previous two pages. Or they clicked “next” after having page 2 open on their computer for several days and meanwhile they used your website on a different device.

If implementing this idea, it wouldn't just be page 3 any more, it would be page numbered 3 excluding IDs 75833,6857362,2737,...

Reddit page links include both the number of the first item on the page (only cosmetic) and the last item on the previous page (which actually determines what is displayed).

That’s not “keeping your place” in an ordered list if the order has changed between the requests for pages 3 and 4.

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.

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 …

> On the contrary, pagination makes it impossible to keep your place in the list if it changes between page loads.

Well, that's obviously false. There are two styles of pagination:

    https://yourblog.zox/archives?page=4

    https://yourblog.zox/archives?before=2019-06-03&count=10

That second style will never change (unless you insert entries into the past). The first style will change. But it hardly makes it impossible to keep your place in the list; if you come back three years later, you'll find that that link goes to a random location, but if you come back next week, that link is going to go to a place that is very close to the place you left off, requiring minimal adjustment to find your place again.

The second style makes it impossible to sort by anything other than time.

and places other than reddit dont need it

If it's the only thing you make available. If you want other options you can add other options.

Ah yes, let me just look at Instagram for the ideal model of infinite scroll UX. You can't even scroll up to something you've actually subscribed to that you didn't mean to scroll past without it tossing it into the memory hole and replacing it with something you don't care about.

‹looks at hn›

Did you think HN has an unusable and bad interface? It seems to be a remarkably popular website despite having hard pages that change order on every refresh.

> Did you think HN has an unusable and bad interface?

In thems of pagination, yes, which is why I prefer to use https://hckrnews.com/.

Why is the list constantly changing anyway?

Because other people keep adding new posts (and upvoting existing posts, which changes their order).

While that's true I think that once the feed has been observed in a certain way the advantages of stability outweigh the advantages of showing a tweaked version the second time it is loaded.

The user expectation is that if you refresh the page, you will see fresh content.

Not if you’re on page 2

mine isnt?

if i refresh the page it should be almost the same. maybe a couple new things at the very top, but i should still be able to find the thing i was just looking at.

by comparison, facebook auto-reloads while you're halfway down a page, and wont show you any of the same things. its an incredibly poor experience

Yeah, this is terrible UX that we somehow normalized.

At the very least we should be able to scroll backwards after a page refresh to see previous posts.

I get frustrated by this so much, because sometimes I come across a post with a video or something I want to see, but I leave it for a few minutes to take care of something, and then when I come back it auto reloads and I can't find it anymore, the back button won't work, scrolling through the timeline is futile, it's just gone.

Reply on news.ycombinator.com