I must say I utterly disagree with the views and conclusions in this article. There are definitely areas where endless pagination can be a good idea, but by mentioning fuzzy web search results as an example, I think you’ve already pretty much exhausted that space of applications. And even there, power users might be very annoyed with endless pagination, e.g. in case the results are, though fuzzy, ordered according to some sorting criteria.
As for the problems of endless pagination that you mention yourself, fixing via JavaScript the issue that you lose your position in the list after leaving the page and returning to it, is more irritating than anything else. The browser will go through several iterations of jumping to the bottom of the page, loading more results and jumping on, depending on how deep into the list you were. If the jumping stops, there’s no quick way to tell whether you’ve reached your previous position, or there’s just a pause because of latency. Also, I’ve noticed that for about 90% of endless paginations I see in the wild—and on big sites, too, such as Twitter—the developers obviously didn’t understand the simple fact that you mention: people won’t be able to reach footers anymore. It makes a site look very unprofessional. Well, at least for Twitter, if you’ll excuse my rant, it fits the rest of the site then. In my opinion, if you know where a specific piece of information would be found on a site (e.g. for Twitter, username and date of a tweet), but you still can’t get to it without using external tools (i.e. Google), that website is an utter failure in both the design and programming departments. Twitter is one of those cases and really needs to either get their act together or just call it a day.
Anyway, once you get away from thinking just about fuzzy search results and to pretty much any other type of content that needs to be delivered in list form, such as posts in a discussion thread, or a list of a user’s uploads on a site based on user contributions, these entities are ordered, usually chronologically. Endless pagination breaks a user’s ability to jump ahead or back a given number of pages if they know where approximately in the list the information they’re looking for is to be found. Take for example Soundcloud. They recently rolled out a redesign, where they replaced real pagination with endless pagination everywhere. I am following an account that uploads around 50 audio releases a week. Recently, I was looking for a certain upload from early last year. Good luck! Endless pagination means that while on the old system I might have jumped to page 50 or whatever, or clicked the “Last page” to start from the other end (since the account hasn’t been active for much longer than a year), endless pagination meant that the same task would take several minutes of wearing out my poor mouse’s scroll wheel. Luckily, Soundcloud still offers users the option to revert to the old site layout, which I had to do for the sole reason of endless pagination (missing out on a lot of great new features because of it). Not all your users are stupid, or entirely clueless about where their information is to be found. If you take (a) the information about the total number of results and (b) the possibility to jump to a certain part of the results directly away from them, you’re stealing their time, you’re generating an insane, unbearable amount of friction for them, and will probably lose them for good. That’s why no serious database query system uses endless pagination. It’s just not workable in real-world use cases.
As sort of a reconciliation, I would say that real pagination is not only necessary to accomodate crawlers, but that the option, should you then decide that endless pagination is workable and a good idea in your specific situation, should also be left open to users who want to switch over to that method.
. If so you might be able to hear it make the scratchy dial-up ‘carrier’ signal sound of a modem; fun.