Hacker News new | ask | show | jobs
by afandian 18 days ago
Infinite scroll evolved alongside algorithms that incentivise addictive content. So it’s “good” UX in that it’s effective for consuming addictive content…

When I’m trying to do something constructive, like search or browse, infinite scroll is IMHO disastrously bad. You can’t keep your place in the list, or jump ahead/back.

2 comments

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.
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.

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?
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 …
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.
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.
> 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.
If it's the only thing you make available. If you want other options you can add other options.
and places other than reddit dont need it
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.
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

Not if you’re on page 2
So you'd rather something like Slack was paginated? I think that would be disastrously bad.
Slack isn’t infinite. At some point there are no more old messages or no more new messages depending on which way you’re scrolling.

The problem is infinite content.

Pagination works just as well with infinite content.
Good. Use pagination instead.
What good does it serve to have to constantly hit 'next page' in the middle of a real-time conversation? That's a bad UX.
Maybe re-read the thread? A real-time conversation is not infinite content, it’s chronological and it ends when there are no more new or old messages. You shouldn’t use pagination, and I don’t expect this law or any similar law to enforce pagination on real-time conversations.