Infinite scroll is frustrating on higher latency connections, which I have all the time being here in Australia.
Particularly when you want to skip towards the end of the list. YouTube has recently changed all their playlists etc to infinite scroll and it takes FOREVER to scroll 5 pages down to get to the bottom of the list. And they don't have a UI to reverse the list order or jump ahead.
They did recently add a list reverse to some places but it's still missing in others. Drives me bonkers :(
Of course it's not necessarily purely the fault of infinite scroll, there are potentially ways to combine them. But the basic pattern many places implement is painful for this latency and no skip-ahead combination.
I'm also Australian and didn't realise it was because of this. Actually, I'm still skeptical this is the main reason since it's like a 260ms round trip to East coast USA. Let's say the latency for someone not living on our big old island is 80ms round trip. I don't think the extra 180ms will make that big of a difference if the app is well designed. That's still enough time to detect scrolling and have the new data ready by the time the user turns the mouse wheel twice.
I should add that I've always suspected a lot of developers don't test their apps with latency in mind, so they make silly decisions like serial requests, etc. They never see how awful the experience is for someone not living next door to their data centre.
I like infinite scroll for streams of things like tweets or reddit posts where I only want to be fed stuff.
For search results (eg: Amazon) I can refine with filters and sort the results, but I can see why some people might prefer pagination here to feel more in control.
From a technical perspective, in many cases getting the total count required for formal pagination is actually extremely tricky. Even in postgres, the count operation on an indexed table is extremely slow. In cases where the query is doing something more complicated than hitting an RDBMS, getting the total count could be substantially more complicated.
Pagination doesn’t require a total page count to still be useful. You might remember Google’s UI in its first 10 years or so, which had pagination but not a total page count (if the number of pages exceeded 10 or so). You can use a ellipsis or a word like “many” and people will easily understand.
These day they just estimate the size of the resultset. It's pretty easy to come up with queries where it estimates the wrong row count until you paginate to a later page. I think the theory is just that approximately nobody clicks on more than the third page.
Example on first try: https://www.google.com/search?q=foobarfrak navigate to the last result. And you get a really misleading "No results containing all your search terms were found." page...
I agree entirely with the points made in the article and add one further issue: if you end up navigating away from a feed for any reason, and use the back button to return to where you were, you often lose the place in the feed. It wastes time, can cause janky loading, and is all round just really poor UX.
I got in the habit of middle-clicking on links in infinite feeds so that they'd load in new tabs, making it easier to pick up where I left off (since there's no page reload involved).
But then websites started breaking middle-click for no fucking reason.
Particularly when you want to skip towards the end of the list. YouTube has recently changed all their playlists etc to infinite scroll and it takes FOREVER to scroll 5 pages down to get to the bottom of the list. And they don't have a UI to reverse the list order or jump ahead.
They did recently add a list reverse to some places but it's still missing in others. Drives me bonkers :(
Of course it's not necessarily purely the fault of infinite scroll, there are potentially ways to combine them. But the basic pattern many places implement is painful for this latency and no skip-ahead combination.