Last night on Twitter, the very awesome Daniel Neighman casually asked if any of his followers had experience with Rails 3 and the will_paginate plugin. In true Twitter fashion, I replied with an overly simplified and entirely unhelpful “pagination makes baby dolphins cry”. Dan politely asked “what else should be used?” and Ben Schwarz went all out.
It’s not really about finding a better pattern, it’s about finding the right pattern. Pagination is one of those ubiquitous things on the web. It’s easy to see a pattern like that, apply it to your own “I have too much data to show on one page” problem and take the quick win. Everyone else is doing it, it’s a pattern, you should use it too, right?
Pagination really only has two things going for it:
- It’s ubiquitous. Everyone’s seen it before, everyone knows how it works.
- It’s a quick win. Too much data? Paginate it!
There’s a lot not to like:
- It’s usually presented as an busy set of tiny little links for moving back and forth through the pages, and a series of other tiny links to jump to some (but usually not all) the pages in the set.
- It’s an interface that’s optimised for use with a mouse. Mouses suck, especially when aiming for tiny targets placed closely next to each other. Easier navigation systems like scroll wheels, keyboard shortcuts, track pads and touch gestures are typically ignored by pagination interfaces.
- Other sites and search engines will link to “page 4” of your result set, but the specific items will shift to an adjacent page as new items are added.
- Search engines can penalise your site and ignore many of your pages because you haven’t spent enough time making each page in the set appear different enough.
There’s almost always an alternative design pattern you can lean on if you take a few minutes to think it through. Here’s some questions you can ask yourself and some ideas you might consider before implementing pagination:
Can you render more items per page, or all of them?
Pagination has a history on the web dating back to dial-up connections and 14k modems. Those days are long behind us, even in the mobile space. Why are we still rendering 10, 20 or 50 items on a page like it’s 1996? What would happen if you just rendered a page with more items? What if you rendered all the items?
For example, I recently took a look at my own archive for this website. I changed from 20 items per page to 500, and ensured that the pagination links are only rendered if needed. I have around 200 posts, so the pagination has effectively been removed for now. The resulting page with all 200 posts is around 85k. It took me six years to write those posts, so it’ll take me a few more to write another 100, at which point the page size might be 150–200k.
A few years is a long time on the internet. Bandwidth may triple. I might redesign the entire site and change it’s structure. Anything is possible. This kind of context matters — don’t invent a pagination requirement if there isn’t one.
How big will your dataset be next week? How about next year? What’s an acceptable page download for your target audience? Can you just render everything and revisit this problem later (when it’s actually a problem)?
Can you limit the number of items?
Let’s say you have thousands or even hundreds of thousands of results, like a Google search. Obviously you can’t just send all that down to the browser in one hit. The browser would explode with that many DOM elements and your database is already crying just thinking about it.
I’ve never looked at the 48th page of Google results. I rarely look at the second page and sometimes I don’t even scroll down past the first few results. A search engine is all about relevance, so the second page of results is almost irrelevant by definition, right?
Take a look at your server logs or analytics data. Watch people using your software. Understand what they do. If they aren’t clicking beyond the first page you might be able to ditch everything else, limiting the results and negating pagination. If your users aren’t looking beyond page three or page five, experiment with rendering more stuff on the first page and ditching everything else!
Can you find another way to break up the content?
If there’s too many items to render all at once, and it doesn’t make sense to limit the items rendered, try finding another more meaningful way to break up the items into multiple pages. Pagination is the lazy way, giving your users (and search engines) a fragmented view of your content.
Think about what your users are really trying to do. They don’t enjoy clicking though page after page of stuff looking for something specific in a series of non-specific pages. If you can find a more specific and meaningful way to break up the data, you’ll improve the user experience, you’ll improve your search ranking and you’ll have smaller sets of data to deal with. Smaller data sets give you more design options and reduce the need for pagination!
A chronological list of thousands of events in an activity log is a good example this. If the most important events are the recent ones, then breaking things up into groups like “today”, “this week”, “this month”, “this year”, “2009” and “2008” might work. Sure, you’ll probably still need pagination on the items in the bigger sets, but you should be able to avoid it for the more common use cases like “what happened this week?”.
If you’re working on a financial application, the groups could be relevant to accounting, like “this month”, “last month”, “this quarter”, “last quarter”, “this fiscal year”, “last fiscal year”, etc.
Let’s also keep in mind that lots of data is chronological, but most chronological data isn’t only chronological.
For example, many blog archives are broken down into years and months. If I’m trying to find something on your blog, I’m not going to remember that you wrote it in early June 2009, so a page containing all your posts from that month is kind of useless to me. I’m going to remember that it was related a topic like ruby, karate or bacon. Despite the chronological nature of a blog, it still makes much more sense to me to break up the content by topic (tags, keywords, categories, whatever), resulting in smaller data sets that can probably be rendered without pagination.
Can you implement an endless page?
If all else fails, consider implementing an endless page like the one found in Google Reader and many other modern web applications. When you load the reader, a limited number of articles are rendered on the screen by default. Let’s say it’s 100 articles, enough to fill the screen. As you scroll down the page, more results are added to the page dynamically through an AJAX request. Keep scrolling down, keep seeing more and more articles.
Technically, this is still pagination under the hood, but the end user never sees the pagination interface’s awkward cluster of tiny links.
You may have noticed Twitter also does something similar. You have to click a giant “more” link at the bottom of the page, so it’s not quite as magical as Google Reader’s endless page, but it’s still a whole lot better than all those fiddly links and fragmented pages of related content.
Think for yourself
Pagination is still a valid design choice in the right context, but it’s just one option you should explore. Forget about the data schema, the code and the SQL queries for a few minutes and think about your what your users want to achieve. If you really have thousands of items that can’t be broken into smaller groups, and if your users really want to click through it all page-by-page in small chunks, got for it!
What are some alternative patterns and interfaces you’ve used instead of pagination? How did you break the data down into smaller chunks? What’s an acceptable page size these days? What are some examples you’ve seen where pagination really is the right answer? Send them to @justinfrench.
Updates, Tweets, Questions and Answers
Wondering what @justinfrench & @xshay think about ‘next’ and ‘prev’ links without the 1234567… pagination in between.
It depends! Assuming pagination is your only real choice (not convinced, but whatever), and there’s no real need for your users to jump to “page 7” in a non-linear path, then yes, get rid of those numbered links!
you are right about pagination on the searches, but maybe it is the only option on forum thread because pages are “static”
Forums are a good example that probably needs to be paged through. However, forums get over used for a bunch of very different use cases (because they’re “cheap”) — everything from endless unfocused discussion through to questions and answers on a focused topic. It’d be interesting to think about some interface alternatives based on what people really use a forum for. I’ll write a follow-up post on this I think!
If you have a geo-localized data, you can think of displaying all of them on a map
Absolutely, a map is another great example. Geographical information opens many new ways to break up the data, and you can add more data points as you zoom in on a smaller area. Countries and regions are obvious, but there’s bigger opportunities like “near me” or “near the hotel I’m staying at next week”, that can be combined with zooming in for more data.
@CorinCole tweeted his dislike of “endless pages” and Twitter’s Ajax-powered “more” button because they make it hard to directly link to something on the Nth page. This is true if a lazy developer doesn’t provide a unique URL for the “page” you’re viewing, but like I said, this is really just pagination with a slightly different UI (scrolling, or a single button). Pagination is a “if all else fails…” thing. I’m pretty sure you can do better.