The End of Pagination

Sometimes, the are no “relevant” items in a search, but the whole set of items is the only relevant unit. For example, in a lexicon or dictionary search, you may want to get a list of, say, all the words that start with “da” and end in “n” shorter than 10 characters, something like:

“lemma:dan length:[ TO 10]”

When every item of a result set is relevant, what kind of pagination would you use?

I think Alex Micek’s progressively-enhanced infinite scroll is the most impressive - doesn’t break the back button:

Endless pagination should not break deep linking.

I’m glad you mentioned this. I’d take badly implemented traditional pagination over badly implemented infinite scrolling any time.

For the worst of both worlds, take a look at Microsoft Connect. It combines traditional pagination with the dynamic-loading approach normally found in infinite scrolling implementations. Content is broken up into pages, yet the back/forward/refresh buttons are non-functional (and don’t even think about trying to open results pages in different tabs - all the links are JavaScript).

The only people who don’t like endless scrolling is the marketing people, because you get less pageviews.

Endless scrolling strains browser resources, and when the browser finally crashes and releases its memory, it has no record of the position you were in. Pagination doesn’t cost much on the server side (unless you try to keep an accurate count at all times, but that’s rarely important). Pushing the work to the client may be seductive because it’s the newer technique, but it doesn’t even provide increased responsiveness because web developers tend to completely disregard the costs of client-side inefficiency (particularly for memory, which sees a sort of tragedy of the commons).

With such endless pagination one could also provide a better real-time filtering.

By letting the user hide/remove those results that don’t have nothing to do with he’s search similar non-relevant results can be let fade away while scrolling. (And an half-second transition would let the user the ability to check that such fading results weren’t really helpful.)

When the dataset to be displayed is something unsortable “like default search results of Google”, I strongly agree with endless scrolling (actually, had created a tutorial about it few years ago: , simply I’m a fan of it).

But, if the dataset is something more like a list whose fields can be sorted (like a list of users, cars with their models-milage-seller’s city, etc), than pagination makes more sense as you can guess what may be listed in page 964.

It even gets better if hovering a page number in a pagination informs you about the records in that page (hovering page 968 can say: “Netherlands-Nigeria” if the records are listed by country) so you paginate without guessing.

They(Google) are doing some experiments with pagination in the gmail blog.

Nothing great, but is already something.

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?