A common navigation pattern on websites is what I call “chunked pagination”: each page has a predetermined number of pieces of content on them. Page 1 shows items 1-10, page 2 shows 11-20, and so on to the end of the stream. Easy.
This pattern, though incredibly common, isn’t useful for navigation most of the time. The major issue is that it gives few hints about where those links will drop you in the stream. It’s an arbitrary chunking of how you actually display the content.
Pagination should provide accurate navigation points that reflect the overall ordering of the stream, and pagination based around fixed-length pages provide nothing more than arbitrary access into this ordering, where we have to use estimation and instinct about the distribution of the content in order to make a guess of where a link will send us.
Having a pagination scheme that closely models how a stream is sorted can give you both the casual browsing experience that the numbered pagination provides, as well as powerful navigation abilities that the numbered pagination can’t provide.
For example, take your average photo site that displays the content in a reverse chronological order: that is, newest to oldest. Let’s say your friend has posted 2000 photos to this site. The site shows the viewer 10 things per page. With our prolific user, this gives us 200 pages.
Going to the middle of this content takes us to page 100. What does this mean, beyond we’re at the middle? Not much.
Let’s say this user posted their first photo to the site years ago, but has just gotten back from a month-long trek through Europe where they took a thousand pictures. So our page numbers monotonically march back 10 by 10, but as we know this stream is sorted by date, and we want to go back in time on their photostream to a dinner you shared 6 months ago, we’ll just have to guess which page to start with.
Since we know our friend’s usual posting velocity, we think that ten pages should take us a few months back in time, so we go to page 10. On page 10, our friend is in Europe, looking at the River Seine, just 1 week ago. Let’s go back 10 more pages. Hm, our friend is still in Europe, admiring the beach at the French Riviera. This is frustrating, so let’s try 40 more pages. Click. Damn, our friend is still in Europe (good for him, but bad for your navigation).
After some clicking, we’ve got them figured out. We know that page 100 is right before their trip started, so our estimation applies again, disregarding the first 100 pages, we quickly find the dinner pictures.
But, now that our friend is back from their trip, they resume their normal posting volume of 2 or 3 things per week. So, after our friend is back from his trip for a month or two, the first two pages cover a few weeks, while the next 100 pages cover four weeks. The concept of “page 100” no longer means anything, as this link is very much a moving target as things keep getting posted to the beginning of the stream.
Lots of problems with the page numbers, it seems. First, we have to guess at our friend’s posting volume and frequency to even make a stab in the dark of how a particular page number relates to a point in time. Then, in an ideal world where URLs are meaningful, the page numbered link (to use Flickr as an example, http://www.flickr.com/photos/nolancaudill/page7/ is the seventh page of my photostream) doesn’t point to any specific resource, beyond that it points roughly to the 126th through the 142nd photos I’ve posted and will point to different photos on my next upload. This link is only “valid” as long as the dataset doesn’t change (which datasets tend to do).
Let’s look at the two main ways that people navigate a sorted list.
The first, as we discussed, is by seeking. You know where something happened in a particular sorting (by date, in this example) and you want to get to it. Page numbers do let us narrow it down, but it’s usually a guessing game. Go too far back and you have to click back. Not far enough? Click further. Repeat these steps until you narrow down onto the correct page.
The second way people navigate is by browsing, where there’s not a specific goal in mind beyond seeing some stuff. For this method, the page numbers are also not necessary. You either want to view the next page, or just jump to some point further in the list. For the former, a simple “next” link is adequate, and for the latter, you can provide this same action but in a way that makes sense for this case, but also for the “seekers”.
The way to represent this that satisfies both the seekers and the browsers is to have pagination that actually chunks based around how the list is sorted.
Some examples of this in real-life: dictionaries with the tabs on the page edges that show the alphabet, calendars (one page per month), and encyclopedia sets that have one (or more) books per letter. Dictionaries are actually a good representation of the problem of uneven distribution of the content, as the ‘T’ and ‘I’ sections are much thicker than the ‘X’ and ‘Z’ sections. Jumping halfway into a dictionary doesn’t mean much at all, but having those handy tabs on the edges give you a good head start. Also, even if lots of words are added or removed, jumping to the ‘J’ tab will always take you to the first ‘J’ word, regardless of changes in the vocabulary.
On the web, blogs usually have both the seeking and browsing navigation controls. WordPress, for example, has the ‘next’ and ‘previous’ links at the bottom of the main list views, but usually provides a separate archive page that lists all the posts split out by month. Aaron Cope’s parallel-flickr has an interface that shows all photos uploaded by your friends in the last day. Instead of using pages, the list is divided up by the uploader (signified by their avatars), which is helpful as I have some friends that post one photo at a time, and others that empty their entire memory card in one fell swoop, but I can successfully navigate both cases.
In all these cases, form and function work together nicely, with the pagination links reflecting how the underlying data is actually laid out, making both seekers and browsers happy. It also creates useful links such as linking to “January 2010” in a reverse-date ordered photostream will always be constant, regardless of how the data around it changes.
Since it came up on the Twitters, I should mention the concept of infinite scrolling as a pagination scheme. (Since blech has a protected Twitter account, I don’t want to write out his tweet verbatim, but I can summarize it for sake of context by saying he took issue with an instance of infinite scrolling, which can be easily deduced from my reply). Infinite scrolling is basically a pretty representation of the ‘next’ link that you ‘click’ by scrolling to the bottom of a page. I’ll leave whether or not it’s good user experience to others, but as a purely visual experience, I like it. If it’s the only source of pagination, that sucks,
and another navigation scheme should be provided if having your users be able to look through the list or find something is important.
So to wrap this up, how would one create pagination links for our reverse-date order example, which is an incredibly common view? The obvious way is by actually chunking around dates. I believe people that are much better at designing useful things than myself could adapt this into the same form that our current paginate-by-arbitrary-chunk format occupies. I think adapting the links you usually see in an archive view could be represented in a succint form that makes both seeking and browsing easy operations.
nolan caudill's internet house 