to page or not to page
Last week I wrote a little introduction to web design patterns. Apart from introducing the benefits to front-end development I simply hoped to give the whole concept a little extra attention with all the html5, css3, ... hyping going on. New patterns are slowly emerging from this period of experimentation and like everything else in this world, new doesn't necessarily equal better. As a starter I'd like to take a closer look at the increasingly popular pagination alternative.
A couple of days ago James Mansfield asked himself if pagination is dead. His article is a good introduction to the popular alternative but his conclusion is a little hasty, maybe even a bit sloppy. While in many cases oldskool pagination is far from the ideal option, in many others it is still the best alternative available.
hi, I'm a pager
A pattern is always a solution to a specific problem. In the case of pagination the problem is excessive amounts of content appearing on one single page. This could be in the form of an overly long article, a product result list or any other situation where the content of one single page cannot be logically transformed or spread across multiple pages. Usually the content follows a certain order and can't be categorized under different sets of themes. If that is the case it might be better to look at a tabpane.
Pagination exists in many different forms, but the core of the pattern is a numbered list of links pointing to each separate page. You can include extra navigation (first, previous, next, last), a result indicator, an instances/page indicator and even a little sort form can be present, all depending on the data inside the pagination pattern. They are all aids to improve navigating the separate pages, making it easier to find what you were looking for. In some very specific cases it might even be possible to remove the numeric pager and only keep the next/prev links.
When it was first introduced pagination caused some confusion among web developers as it blurred the concept of a "webpage". Is each link in the pagination referring to a different page or is it all the same page with a pagination component showing different states? That question became easier to answer when AJAX took off and many pagers where converted, eliminating the need for a page refresh just to reload the content of the pagination component. The links would just refresh the content part making it faster though often a little less accessible to screenreader users.
new horizons
This last year some popular services (like Facebook, Twitter and Bing Images) have been using alternative patterns nullifying the need for a pager. Recently Google Images jumped on the bandwagon, truly launching this new pattern into the mainstream. The idea is that when a user reaches the end of the paginated content, the pagination component will load the "following" page. This can be done automatically, sometimes an extra action is needed to trigger the content load.
For some applications (like the image search) this works wonderfully well. No more going back and forth between pages trying to remember where this one particular image was located, you simply scroll up and down to find what you need. Getting more images is done by scrolling down, the gallery will then load new images all by itself without any extra action from the user.
why it won't kill pagination
While this pattern is becoming more and more popular and has many advantages over oldskool pagination, there are some limits to its use. The most important one is that you can't skip to a particular page anymore. You have to go through all the content in sequence to reach a specific part of your information. For content that isn't predictable (the Bing and Google image search) this is no big deal, but Facebook and Twitter are balancing on a tightrope.
A numeric pager gives you an indication of how much content there is. Based on that information you can decide which page you want to go to. If one page of Facebook updates equals a day and you want to travel back a week in time, you can jump to page 7 or 8. It's never exact, but you don't need to cycle through all the other pages first. With the new pattern in place this is not an option anymore.
That's exactly the reason why I haven't implemented the automatic content load yet on my blog. I could very well remove the pagination on the archive page but from personal experience I know that I don't always go through the list in sequence. In the end, this should be the main reason for deciding whether to use the new automated pattern or to use the oldskool pagination pattern (or maybe a smart combination of the two wouldn't be all that bad either).
conclusion
Common sense is a good start to determine what pattern is your best option. If that isn't enough, some statistics might be useful. If you notice that people use the pagination in sequence (they start on page 1, then 2, then 3, ...) it might be good to switch to automatic content load, but if you notice that people are skipping through your content it's probably best to leave the old pager intact.
So while I applaud new ideas and patterns, it's always good to take a few minutes to consider in what circumstances a particular pattern would benefit your needs. It's not because it's popular that it's any good (just see what happened to the tag cloud). That said, I love the automatic content load as it makes navigation a lot easier if a numeric pager isn't needed. I just fear that it might be used in places where it isn't needed.