The End of Pagination

I can see both sides to this. On one hand, I really do enjoy the experience of endless pagination (especially on mobile devices). There are edge cases I can see for having pagination in some form. A random example of one of those edge cases would be something like a list of Royal Navy Ships throughout history. In that case, as a user, I would prefer to be able to jump to a specific page (by letter of the alphabet, not numbers) to find the one I’m looking for. However with the same use case, if I were just browsing the list, I would prefer endless pagination.

This brings up an interesting thought. In writing this comment I would say that both are still a fit, it just depends on the users’ intention. I wonder what would be a good UX to solve this? Providing endless by default, with an option to jump to a page? Thought provoking.

The stupid tiny ‘next page’ buttons in so many forum designs is one of the main things that make my own forum software with nice big easy-to-click buttons:

I used buttons because as some have said, auto-loading stuff can be a bit annoying, and feels like you’re not really in control of the app/page.

Regarding an earlier commenter’s point about overloading on HTML elements, I don’t think removing elements from the front of the queue would be a particularly arduous task, and browsers are pretty good at handling large numbers of elements, though obviously it depends on the complexity and content of each new ‘page’ of items – for a forum consisting of mostly plain text, I would guess a user would get bored long before putting any significant strain on the rendering.

I actually use pagination some times to click on a page and then “Ctrl-F” and search within that page. aka search within search.

I have even done this with google at times. Often times its for strange meta-data that is not clear how you would get the search engine to bring it up.

Ctrl-F does not work with infinite scrolling however I’m kind of a weird user.

Here’s the thing - I really dislike the “No Pagination” thing. Why? Because sometimes I need to send a person to a set of search results rather than a single link - but I would also like to say “It’s the third one down on page 3” rather than “Scroll down a few pages and it ought to be in there somewhere”.

I agree with everything Kamran Ayub said and think the idea of having small menus based on context (year/month/price/whatever) is a great solution to the ‘where am I’ and ‘how do I get to page 2000’. The prime example for me right now is with Google Groups. They changed to endless scrolling in their test product and it is now impossible to get back to early 90s posts in busy newsgroups. It renders the archive practically useless. Still scrolling without broken up pagination is great, just need that extra navigation and permalink feature in there.

I think this is a clear example of “I know what is best for you”. This kind of no-pagination is really nice if you are looking for some very specific context and easily breaks down when doing anything else.

Example: Sometimes I look for some tweet that I saw in my timeline a while ago. Can’t use search (that sucks btw) because I don’t know the specifics of the tweet but I know that I’ll recognize it when I see it. So I scroll, and scroll, and scroll… until I get bored with the extremely long page (if only i could skip the first hour and jump directly to the page 10?), or even worst, some problem happens and I have to start over again.

Also, like @Timothy Collins said, good look when trying to send the link to someone: it just doesn’t work.

Some comments say that if no-pagination doesn’t work is because everything else is badly implemented. Well, pagination might not be perfect but it damn sure helped to circumvent those problems way better than the infinite scrolling gimmick.

For the record you should say “Bing’s image search”. Google implemented their version quite a while after Bing had it in place.

@sbrandwoo: Exactly the opposite.
The focus needs to go to the people who come to buy things, not the people who come to window shop.

Big buy buttons and good reviews, not the chance to use up bandwidth flicking around results.

@Isomorphisms: Actually, what you’re looking for there is not 3 pages, but one pages that compares all 3 restaurants, like a reliable review site.

Fully agree on the friction argument. I’d like to throw in another element of friction that is loosely related to pagination: the “more” link. And with that I mean a paragraph of text that is trunked to show x characters, and where “more” needs to be clicked to see the full comment, paragraph, or whatever it is. It can be useful on really large sections of content, but when applied to shorter paragraphs it drives me insane.

By the way, I do not agree that you should continue to feed traditional paginated views as well for the sake of SEO. Pagination is friction for both users and search engines. Instead, as you already suggest, a sitemap without pagination is much preferred imho.

When I am on mobile net, especially if the connection isn’t all that great the infinite pagination can be frustrating on image searches and the like, especially if I want to load something else concurrently too.

In my opinion the best solution isn’t doing away with pagination, but rather it should be supported by the browser. If I could visit a new site and I would just have to hit a UI button or a hotkey instead of looking for the (usually small) page controls, that would be awesome. Another addition is, that if the scheme would be supported by the browser, than you could start preloading the content of the other pages (hopefully only the textual) once the current is finished so you could search those pages too with the browser’s search feature.
I don’t know, this sounds really utopistic and I think it would require W3C implementing a new standard. Maybe in the next decade…

Search on the web may be difficult, but a lot of lists can have a logical grouping. If the scrolling speed is maximized for a certain time interval, the list should shift to scrolling through the grouping. If you are scrolling through a list of 500 contacts, at some point, the letters of the alphabet should appear. This makes jumping to a new “page” more practical. This can be done by dates or numerical value. If my search/filter has too many results, shouldn’t there be a way to limit the list further?

with Facebook, Twitter and Pinterest effectively all using infinite scroll I have wondered how much that feature alone is a contributor of their engagement in the same way “related videos” were to YouTube in the playing viewport of embedded videos. It’s unlikely that Google will defer to infinite scroll, at least while Marissa Meyer comments are considered: See

I can’t tell you how many times I was reviewing a paginated result set and said to myself, “Wow, this sucks because of all of these pages.”

Wait, nevermind. I’ve never said that to myself.

I understand and I agree with your points. But I don’t see a better alternative for pagination.
You are right, when you are having thousands of pages, then Pagination becomes meaningless from a user’s point of view (but not from SE).
I wrote a pagination tutorial for WordPress users without a pluging:
Paginate comments:

Paginate posts:

Thanks for this great post.

What about cached ajax pagination with detection of scrolling ?
It’s more complicated to implement on one’s site but it would be nice.

Pagination was the single most annoying thing that happened to the web during the 90’s, that is, until people started doing the horrible AJAX ad-hoc page loading.

The whole idea of arbitrarily feeding a user small chunks of data somehow doesn’t smell right.

The user should be the one to decide if they want to see those 200k hits on one page.
I don’t want to get back to my browser just to see it hasn’t loaded everything, and that I still have to wait if I click somewhere.

A single hit might not be enough, maybe the user needs all those hits for their search?
Remember, searching is just a hack to work with unstructured information, designed to prolong our inevitable fall into the chaos which is the web.

I work for a VERY large online retailer. I can’t tell you how many websites have missed out on some very lucrative advertising dollars from us because I can never reach the “Advertising” link in their footer because of their never ending page. My rule now is, if I can’t reach the footer in two attempts, I’m moving on.

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.

Reading some more comments, I agree very much with Kamran Ayub that much of it is down to bad implementations—on both real and endless pagination. And most of the time this is due to the reluctance of developers to give (power) users the functionality to search for what they’re looking for.

For my Soundcloud example from above, I wouldn’t have had that problem if it allowed me to search or filter by date. The same thing fixes traditional pagination. You can, for example, sort YouTube search results reverse chronologically, but not forwards chronologically, or search by a specific date range. This is one of my main annoyances with most sites out there. They don’t give me enough power to search, to mine, to filter and drill down.

So far, when we’re talking about advantages and disadvantages of either method here, we’re talking about users having to “hack” their way around limitations because they can’t tell the search script what they are really looking for. I very much agree with the article’s author in that. If you could search by the criteria you actually have in mind (YouTube, show me all videos from February 2011 that are between 2:00 and 2:30 and in Spanish), then the question of real or endless pagination becomes rather moot.

So in the end I must say I agree with Mr. Atwood’s analysis. If the results are relevant, no one will have to browse thousands of results. I still don’t agree with the conclusion though. Endless pagination solves nothing. It just transforms one set of problems into an entirely different set of problems, and—my main concern in the post above—the new set of problems are harder to get around for power users (such as by manipulating URL parameters).