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?