I’ve had some disparate thoughts regarding pagination lately, so I thought I’d attempt to organize them in a post. That’s how blogging works right?
Consistent Positioning
If there is any way to make sure your pagination buttons don’t move, do it. It’s such a nice experience to be able to just click-click-click (or tap-tap-tap) and the same thing happens each time. And when you get to the end, a subsequent click doesn’t all the sudden to something different (because you’re now clicking on a different button, or nothing).
If one button depends on the other for positioning, perhaps you could disable one and like opacity: 0.5;
it to indicate its disabled-ness or even visibility: hidden;
to hide it but still have it in the document flow.
Vertical positioning is important too. It’s nice if the pagination buttons don’t jump around based on the height of arbitrary content. If that’s unavoidable, because, say, they are positioned below the bottom of arbitrary content, perhaps they buttons could be on top instead. Or in addition to, which is nice for content the requires scrolling.
Of course all situations are different, but perhaps even position: fixed;
for some pagination elements would be useful to ensure those positions remain stable.
Text or no?
What is the pagination pagination past? (say that 10 times fast). The text in the buttons could help make that clear.
“Older”
“Newer”
“Next page”
“Previous page”
Mayyyybe. But what about:
“Less Relevant”
“More Relevant”
“Less Popular Content”
“More Popular Content”
While that may indeed be what the pagination is doing, that’s kind of a bummer to say. I would tend to say: if the reason for pagination is fairly obvious or non-imperative, just use arrows.

One caveat to not displaying text is directionality. Will people enter your site on a page in which it is possible to paginate in either direction? If that’s the case text might be appropriate, to orient people who didn’t get the benefit of starting at a page in which you could only paginate in one direction.
Directionality
Speaking of arrows, which direction is most appropriate? I tend to find that most pagination begins with an arrow pointing to the right. (ala Google Search Results) I’ve heard this hotly debated with good points on both sides though. If you think of a timeline, that’s almost always left-to-right and so paginating through time you’d think the arrow would point left if viewing the most recent content. But left arrows are associated with the back button, which is highly used and generally understood by users to mean going back to a previously visited area.
If there is a good chance a user might enter your site on a page in which you can paginate in either direction, I’d error on clarity and label the buttons.
URL Structure
Pagination often happens with URL’s that go like:
website.com/page/1/
website.com/page/2/
That’s not awful – at least it’s clean. The trouble is that the URL doesn’t contain any information about what is being paginated. But worse, the content on those pages can change. What is on page 1 today might be on page 3 tomorrow. That’s super common in date-based pagination.
I’ve mused about this before.
Us web people are always really concerned with keeping URL’s alive and hate it when URL’s break. But isn’t a URL that shows totally different content than when it was last referenced broken? It depends, and it might not be a fixable problem depending on the type of pagination being done. But it probably is fixable for date-based pagination. The current design of blogs on the Gawker network has pagination buttons that get you to URL’s like:
lifehacker.com/?startTime=1411848000454
lifehacker.com/?startTime=1411749900413

Those URL’s are more likely to have the same content on them over time, since it references content based on the publication time.
Depending on the publication frequency of your site, perhaps your pagination buttons could be months, weeks, or days, rather than arbitrary pages. Paginating back from a homepage of content might be like:
website.com/blog/
website.com/blog/2014/09/
website.com/blog/2014/08/
Then those URL’s would always have the same content on them over time.
Even if you prefer using arbitrary chronological integer based pagination, wouldn’t it make sense to reverse the numbers? Instead of 1, 2, 3 going back in time, have the numbers start at the highest for how much content you have.
website.com/blog/
website.com/blog/page/523/
website.com/blog/page/522/
I wonder why it’s seemingly never done that way. Perhaps it involves the stress of count queries on older database systems?
Indication of how many, or no?
Speaking of count queries, should you indicate how much content there is to paginate through? In order to do that, you need to know how much there is, which involves some kind of count at some point.
<- Page 1 of 302 ->
Is that useful? I might argue it is if the number could reasonably be useful. Either because you could look through it all, or because it gives you a sense of the breadth of your search, or because you might need that for use in an API, or something like that. It’s probably not particularly useful somewhere like Google where it tells you it found eleventy-gillion results and it’s really just showing off.
Other than just how many, should you be able to jump along further in the pagination?
[<-] [1] ... [5] [6] [7] … [302] [->]
I dunno. I’ve always kinda baulked at pagination like this because it seems overly complex and marginally useful. Not to mention harder to honor consistent positioning. It does offer a way to jump to the start or end of pagination, which I could see being useful. It’s just the longer versions that allow me to jump ahead like 4 pages (but not 6!) seem like they let a programmer little too close to the front end =).
Ajax
Pagination is the perfect kind of thing to do without a full page refresh, because it’s highly likely the only thing changing on the page is the stuff being paginated. But this introduces some new complexities:
- Do you append new content to the bottom of the current content area?
- Is there a risk of so much content being added that the DOM weight slows down the page? Can you remove content at any point?
- Do you replace all the content with new content?
- If you do, should you scroll to the top of that new content? How do you do that across browsers?
- Are you “losing” pageviews this way? Does that affect your business? Can you track this or do the same things that pageviews would have done for you anyway (e.g. rotate ads)?
- Do you refer to the pagination differently, like “Load More Content”? Or is that inside baseball that only web workers care about?
- Do you offer pagination in both directions this way?
- Do the URL’s change?
- Can it be approached with progressive enhancement so pagination always works no matter what?
WordPress.com themes are leaning this way. I checked out a number of themes and they tend to have an “Older Posts” button that brings in new stuff Ajax style.

In this particular “Eighties” theme, there is no pagination at all without JavaScript. You can get to the content because there is links to the different months of content in the footer. Seems a little half-baked of an approach to me.
Consistency
Whatever you choose, be consistent about it across your entire site.
Lawd knows I need to implement some of these things of this across my sites.
Re: your “Text or no?” point…
I think if you’re pairing pagination with sort, the arrows would indicate that you’re moving down the list of sorted results and wouldn’t require text. So “Price: High to Low”, page 2 would be a set of lower priced options than page 1. This is obvious to the user, but only if the sort option is clear.
Interesting thoughts Chris.
I make mass-market tumblr themes and have tried so many different options, usually just settling with right and left arrows, but the things I’m working on now have a mashup of ajax and traditional arrows (because it seems there are plenty of people that hate infinite scrolling and plenty that think it’s the best thing since sliced bread). I’m going with the first page having a ‘load more’ and a right arrow, then if the user clicks load more it’ll ajax in all future pages without asking again, and if the user clicks the arrow they’ll go to the actual second page that has ‘older’ and ‘newer’ buttons. That’s my best of both worlds :)
RE: Indication of how many.
If you are shopping, this is really important – especially on sites like Amazon where a fairly general search will give you thousands of options. If 14,920 items match my query, then I know I probably need to be more specific.
And if there are more than 10 pages, yes I would like to be able to jump forward. Not pretty to implement I know, but helpful if you aren’t sure about an appropriate price point. For example – researching housing costs in a particular area. I want to know the full range – but if there are 25 pages and 1-4 are all $1M plus, I need a way to skip to the middle to get an idea of the price distribution.
I don’t really like pagination for copy though. It feels like you are still trying to make the web into a book.
And knowing how many is really important if you are giving me the choice to switch to infinite scrolling. Infinite scrolling is great for 300 items. 1,000 – not so much.
On your example of wanting to jump into the middle of 25 pages of search results, I think that really proves the case where simply having page numbers isn’t particularly useful. Wouldn’t it be better to have another search field where you could narrow the results by price?
In general: Yes, you should provide a way for someone to jump into the middle. But use meaningful signposts so they know where they are going. For blog posts, if you’ve got more than a few pages of results, and the assignment of posts to pages changes with every new addition, there’s really not much meaning of “Jump to page 17”.
Instead, it would be useful to have a link to an organized archive list, which would be grouped by year/month.
For different types of lists, there would be different equivalents to “Archive”, but in any situation it should be a way to see an organized, easy to navigate, list or hierarchy of content.
[<- Newer ] [1] [2] 3 [4] [5] [ Older ->]
[<<- Latest Posts ] [ Archive ->>]
It’s a nuance. I don’t want to always go to page 10 – page 10 will be different every time. But sometimes I want to quickly browse through results instead of just narrowing a search and getting a whole new set of pages.
That’s just a personal preference for me as a “customer”. As a developer I don’t like pagination ever. ;^)
Totally agree – and the same is true for a lot of other situations as well.
Imaging f.e. an alphabetically ordered list – and you want to skip to the entries starting with a certain letter. With “typical” numbered pagination links, this requires a bit (or a lot, depending on the amount and distribution of data) of trial-and-error to find the correct page.
How about a title attribute (or other form of tooltip) to improve this? Hovering over the link to page X could show “Houses from $950.000 to $775.000” for your example, or “entries starting with Fo to Gh” for my alphabetical one.
Of course, this might require a little extra database work (but we’re caching such things anyway, right?). And it might be less useful for large data sets, where we leave out links to result pages as in “1 … 136 137 138 … 1768″. But still, I think it could be an improvement in certain situations.
Spot on, Rio. As a consumer, the only time that I really care about pagination is when I’m shopping large result sets & viewing by price.
For example, a place like Zappos will give you 9000 results for women’s boots. I could narrow the results with their nifty filters, but on some days, I might not really know if I want grey or brown or black. Or maybe red.
Fuel UX put a text-input so you can type a page number.
http://exacttarget.github.io/fuelux/javascript.html#repeater
My ideal pagination control would be similar to theirs, but maybe with a hybrid of text-input/select for choosing page numbers in the middle.
thanks for sharing all your’e thoughts on pagination,
I think when it comes to usability and the viewers experience – what they are used to?
… look at the sites with long lists like social sites “more option” vertical solution.
so an intuitive vertical solution – up and down for older newer is what I would go for rather than left or right.
Personally, I more more controls is better. Something like << < 1 2 3 4 5 > >> or even an input field to go to a specific page even though this can be done using the url bar.
Good summary of many of the frequent implementation problems with this design pattern.
I’d add another: keyboard access. It’s a pain in the arse for the developer to implement, but it’s a pain in the arse for many users if you don’t.
If you’re going use left/right arrow buttons, or any thing that generally equates to forward/back arrows, please react to the arrow keys. It’s a frequent frustration. If there are more than 3-4 things to flip through, I don’t want to have to grip my mouse and hold it in one place, I want to sit back and just tap the keyboard leisurely.
If you’re going to trigger new content on scroll, please also make sure it works on page up/page down (this isn’t usually a problem with continuous loading site, since these buttons trigger the normal scroll events, but just this morning I got stuck on a fancy scroll-to-start animated site that wouldn’t do anything on page down).
My thoughts on the text aspect is if you’re not doing something like numbered pagination or “Go to page 2” or something of the sort, you should always use “Older items” or something more descriptive of where the user is going. Too many times I’ve visited sites where I hit what seems to be the next arrow, and it takes me to the wrong place because they just used arrows. Now I have to navigate two more times to get to the place I want to go.
Also I’d like to say if you’re doing numbered pagination, for the love of all that is binary please please please make your numbers the appropriate size. A numbered pagination with small letter spacing or non-uniform width can really cause issues. Not to mention font size. The amount of 9px paginations out there is crazy.
I recently discovered Microsoft’s IE-only “flip-ahead” browsing. It is quite an awesome pagination solution. In your HTML you point to the “next” and “prev” pages, which will be picked up by the browser. Next, you can swipe left or right to navigate, or get this on-screen next button in case you use a mouse. It solves the problem of users having to hunt down the next link.
Unfortunately, it’s IE only, and even worse: also has to be manually enabled by the user.
Even if you prefer using arbitrary chronological integer based pagination, wouldn't it make sense to reverse the numbers? Instead of 1, 2, 3 going back in time, have the numbers start at the highest for how much content you have.
Now you mention that, it seems like a no-brainer. I’m not sure if WordPress can be configured this way?
Something needs to be done about infinite scrolling. It causes severe problems in the following cases:
Infinite scrolling may work on Pinterest, but I really wish designers would stop implementing it willy nilly without considering its usability cost. For the most part, there’s nothing wrong with traditional pagination, and I kinda feel like infinite scrolling is sometimes just an excuse to intentionally make the user load more by accident so that they also load more ads.
I think an arrow to the right means “show me content I haven’t seen yet”, whereas an arrow to the left means “show me what I’ve previously seen”. I also like the idea of infinite-scroll where top/bottom means respectively new/old.
Interesting thoughts though. To me it would just feel weird starting on page 321 (or whatever) working my way through to page 1.
Excuse the crude example but I quite like this approach. You get the best of both worlds with simple–single step pagination but you can jump to a specific page
Prefer infinite scroll, especially for responsive.
How many results per page for phone?
Hate pagination.
I think pagination has its place – the most annoying thing for me though is only showing a small number of results per page. It probably depends on the context as news/blog articles are more likely to become less relevant the older they get but in an e-commerce environment a ‘show all’ (or suitable large number) is a must.
On the topic of infinite scroll, I think the hybrid approach works nicely where you click to load more, but its still ajaxes into the same flow and updates the url. Best of both worlds.
Same here, I hate pagination, even more with actual numbers, who clicks on more than 5 anymore? I think that if what you are looking for is not in the first three pages/results/view areas/etc your problem is not your pagination but your search engine(hi Amazon!) or your navigation. That’s why Pinterest is different, you are looking through a gallery, is not a search result, same thing with timelines, browsing is different from searching.
I prefer infinite scroll, the same way, 3 infinite scrolls, and then prompt the user; of course no footers and if you can do the “bounce” edges to load more, even better.
The problem with infinite scroll is that browsers, even the latest ones, buffer everything in memory and eventually get bogged down and crash, lock up, or something else that’s ugly.
I think it is quite OK to initiate a discussion about the given subject.
When I read your blog Chris, I sometimes think “what am I doing here?”
I am just a beginner in the fast evolving world of website development.
When I read the comments and the replies, I think “what are they talking about?”
But today my status as a browser of the web can help to provide you of some useful information.
Why would anyone want to go through many pages (pictures/articles etc.) just using some next or previous arrow or button?
When the next or previous option is provided to walk through a limited number of pages (as a result of a previous search f.i.), then it can be acceptable.
My opinion though: never use those arrows unless there are no mere than (let´s say) 5 pages involved.
Tesco’s Blinkbox does an excellent job of dealing with this. You scroll to the bottom of the loaded content, then click to load more. This updates the URL to include a page number.
You can navigate to that ‘page’ (or any other) whenever you want to and it will instantly jump to that content, and only load previous data when you scroll back up.
It really is very well executed.
+1 for this solution
In my opinion, putting text in pagination links is almost always necessary. users want to know in which page they are and many of them don’t look at page url.
also it is really useful when users want to jump for certain number of pages.
What do you think about Paginator 3000?
I always thought of smaller pagination as a scheme to get ad views. It’s painful visiting sites with only 5 things on 1 page, but 40 pages.. But with no pagination, users are lost “it was on the third page I think” — it’s a delicate balance.