Many web sites and applications paginate their content. Often this makes them harder to use.
Partly it’s because site-provided pagination interacts poorly with the browser’s built-in scrolling, because the content on any given web page usually takes up more than one vertical screen of space, and you have to jump back and forth between site pagination and browser scrolling, hunting down their controls each time you do so.
Sites compound this problem by moving their pagination controls around, so you can’t leave your mouse over the Next Page button and assume you can simply click the mouse button repeatedly to jump to subsequent pages.
And pagination control click targets are small, which makes them hard to hit. Page-specific targets are often a single number (1, 2, 3), while the Next Page target is sometimes a single character (>).
Finally, pagination confounds searching through content using a browser’s Find in Page feature, since it requires you to switch back and forth between searching for the content on the current page and navigating to the next one until you find the text you’re looking for (and beyond, if you’re looking for multiple occurrences of it).
And it similarly confounds any other activity in which you want to engage with all the content in an application, like when I wanted to turn off tracebacks/pingbacks for all 56 posts in a WordPress blog, which is a six step process, and I had to repeat those six steps four times each because WordPress’s list of posts only lets me see 15 at a time.
Nevertheless, there are legitimate uses for pagination:
- sites whose content is computationally intensive to generate (like search engines) use it to reduce load and cost;
- those with large quantities of content that strains server, client, and network resources to display all at once (search engines again, the Personas gallery) use it to improve responsiveness;
- those whose content cannot usefully be browsed in its entirety much of the time (search engines a third time, messaging applications) use it to reduce the cognitive overload of providing all their content at once;
- and those with an ad-based revenue model (you guessed it, search engines, but also online news and many other sites) use it to show more ads.
For those kinds of sites, pagination makes sense, although doing it right still matters, like giving its controls large click targets and putting them in the same place on every page.
And, for content that spills across multiple screens, including the pagination controls at both the top and bottom of the content, the two scroll positions at which users often find themselves when they want to change pages; or positioning them absolutely, so they’re always visible; or only loading a screenful of content at a time, so users never have to both page and scroll; or using endless/infinite scrolling.
Are there even better approaches, and are there ways for the web platform to support them so that web sites don’t have to roll their own? Perhaps browsers and servers could collaborate to provide content in screenfuls with integrated scrolling and paging controls that play well together and don’t change from site to site.
What do you think?
My first reaction on news sites is to look for the “print version” link so I can just read the article without going through all the silly pages.
One of the use cases that you didn’t mention is page analytics. Some companies will paginate simply so they can analyze the level of engagement that a viewer has with the article.
I’ve been a proponent of trying to use JavaScript mouse events to try to perform this kind of analysis rather than forcing the user to go through unnecessary pagination.
Those pagination elements are used very often, yet most of the time they are super tiny: typically less than 10 pixels wide!
The "Next" and "Previous" buttons should be huge. There should also be a way to denote them as such, a bit like <link rel="prev"> was supposed to, but it's not implemented by anyone anymore.
I really like the twitter style single ( more ) button that adds more to the current page. I can understand that always adding results into the current page doesn’t scale to handle lots of paging. But at the same time making people do lots of paging seems like the wrong kind of experience anyway. Either you are searching and probably want to filter the results down to fewer or are just browsing and you want the auto-river-of-results style.
For what it’s worth, Opera actually does this well — even though it’s very hidden to the end user.
When loading a page, it looks for things that are defined as “Next Page” using the link rel=”” tags, links having the words “next” or “previous” in them (in multiple languages).
Then you can use mouse gestures, the forward button, or keyboard shortcuts to go to the next page, even if you don’t have the “next page” link on the screen.
I like how Google Reader does it; it automatically loads and appends to the end of the document new content as I scroll down to it. So I can just keep scrolling down to see new content.
The problems you mention all stem from bad implementations of the basic idea that are easily circumvented by:- repeating the pagination controls after the content; putting the page number in a container and making that clickable; allowing the user to specify results per page; etc.
There’s a bigger problem with many instances of implementation though, that you don’t mention: list order changing between page loads. Lists of article ordered by some kind of popularity algorithm are a good example – places such as Stack Overflow, Digg etc. You read through the first page and then click to the second, only to see a few results you’ve already read on the first page mixed in amongst the fresh results of the second page. For each one, there’s a result now in the first page that you have missed(1).
If the user is not aware of this behaviour, they’ll miss some of the results completely. If they are aware, they still have to click backwards and forwards to catch ’em all.
One solution is for the database to cache pointers to all the results, and the page to allow you to paginate through the cached results. But, this means heavier load on the server for the first page, more temporary data in the database to deal with, and the issue of deciding on a suitable duration for the cache etc.
Pagination is the absolute perfection of an example of an iceberg problem. I’ve been using it as a discussion point in interviews for years 🙂
(1) or a later page, where it may or may not still be when you get there.
On Firefox, you can have similar functionality as Opera with the Link Widgets extension. You can add buttons to the toolbar, or use Alt+PgUp/PgDown for prev/next page.
The infinite scroll approach is interesting but in practice it fails at providing landmarks for returning to previously viewed content.
This should be pretty easy to address with a numbering scheme or visual indicator of depth.
The more homogeneous the content is the more critical it is to provide additional cues about the current depth.
So, for image search, this is almost not a problem as the content is super varied in ways that are cheap to perceive. Google Reader is somewhere between image search and web search as at least the posts vary more dramatically in content and size than search results.
Then you can use mouse gestures, the forward button, or keyboard shortcuts to go to the next page, even if you don't have the "next page" link on the screen.