Monday, September 14, 2009

Pagination is dead

Pagination is the feature for displaying a long list of entities in a web application: a division of them per page and a list of link to the various pages. Today there are better solutions to this classical problem, and some of them were always available even in the first days of the web.

The typical scenario solved by pagination is to allow the search of a particular entity from a list, by displaying it a chunk at the time. Particularly in web applications, where page size is limited by bandwidth, the maximum amount of items contained in a page is fixed in less than an hundred:
The problem with pagination is how often do you look to page 2?
I google many times a day, so many that I now use the search bar of firefox instead of loading the homepage and entering the query in the input field. I usually found the first or the second result to be the most reliable resource for the query I entered since Google ranking is legendary: it's Google that decides how popular an article on this website will be and the only thing that competes in popularity with Google ranking is social network one.
Thus, I never went to the 2nd page of a Google search result. I bet you neither have done the same more than once or twice this month, and probably refining your search terms would have put the link you were looking for in the first position of the first page. Since the first link is almost always what you will be clicking some seconds later, Google main page even feature the I'm Feeling Lucky button which does this work for you.
In my opinion, Google pagination is rather useless.

In the early years of the web, pagination was the killer feature: LIMIT clauses for databases were everywhere and calculation of its argument were spread all over an application. This blog, hosted on the Blogger platform, also implements pagination: but do you prefer to scan my archives five posts at the time or to use the search box on the right?
Although all the content is available in a list of pages, a blog is not a book and it is not sequential: articles are often found by visiting a particular label or by a Google result. Honestly I sometimes look to the page 2 or 3 of a blog to form an idea on what content is posted there and decide whether to subscribe to the atom feed, but I think the author would rather have me look to a search on a tag, to a collection of popular posts or to its about page.

What about different kind of lists to paginate? Wikipedia lists are often very long: sometimes pagination is not adopted, like in the link, and the result is a unfocused and difficult to navigate page. But if you refuse to paginate there are other ways to manage this big pack of data:
  • showing results on demand a la Dzone: thanks to ajax requests, when an user reaches the end of the list or is at the last items, another chunk is lazy loaded to fill the empty space between the list and the end of the page.
  • better search system: as we have discussed earlier, Google does not need pagination since it is the best search system and you'll find your desired result in the first 10 links. Provide a mean to search a big list instead of spitting it all out, leaving the burden on the end-user.
  • real time filtering: a dojo grid presents a pagination similar to the Dzone one, but different filters can be attached to modify the query. The result is similar to google suggestion while typing in the text field, as when you add characters to your search string the filtering is performed instantly.
These are only examples of what can be done if you force yourself to not paginate. The question which I repeat here is always the same:
Who will have the patience to look at page 2?
If you keep in mind this problem, finding another user interface to substitute pagination will be at the top of your todo list.

The scroll at the top of the page shows you a continuos source of pages that reminds of pagination sliders where you can go only to the next and previous page. It was very inefficient, but ancient monks did not have Google search capabilities...

9 comments:

Ariel Arjona said...

"Who will have the patience to look at page 2?"

Anyone who is not looking only for a handful of results out of millions.

Pagination is not any more dead as a feature than the command line as a control interface.

Showcase Web Sites said...

I agree with the poster. Pagination is still very useful, both for technical/performance reasons and from a UI perspective.

I think maybe your article is more about "traditiona" pagination user experience, not the idea of it altogether. I do agree with you that ajax, search, and other new tricks vastly reduce then need for it, but that doesn't mean it's dead.

Giorgio said...

Of course the pagination infrastructure will never cease to exists since other options like dojo grid and lazy loading on Dzone requires to provide pages dynamically to be inserted in the content, as rows in the former case and as html in the latter.
What I'm advocating is another approach for the management of a collection of items, not sequential but search-based: refine a search is cleverer than scan more than several pages. That's what Google (maybe incidentally?) does when suggesting you queries while typing, narrowing down the set of result so that only a few pages have an high rank.

Jose said...

Linear searches will not work best for all knowledge domains, that's true, but it's hardly a dead concept.

As Ariel suggested, you are making an observation out of how you use something and imposing that view on how others use it. There are many times each week where I find myself on page 5+ of a Google search.

Many other alternatives exist, such as tag clouds, user rankings, etc, as you mentioned. Google itself has another option: "I'm feeling lucky", where it'll just take you to the top result. But these will supplement traditional search and will likely never replace them for many knowledge domains.

whyjava said...

i think it depends on what you are doing like in case you are looking for a specific topic or query you might not require pagination as the you can get the results in first few results but there are many times you are required to show to the user the number of links like if you are reading a site which has interview questions on java you will dont want that user should be populated with all the questions in your database. You have to provide pagination in this case both for performance as well as UI. for google searches your point may be valid but not for all cases..

Rob said...

The problem with losing pagination in favor of "better searching" is that you don't always KNOW what you're looking for enough to narrow it down.

Suppose you're trying to find a song where you only remember a tiny bit of the lyrics that isn't very unique. Chances are you'll be paging through a lot of results in the hope that you'll chance across the right thing.

Or suppose you're looking for a customer with a common last name (and an unusual first name you can't remember...) in your company database... you have to just page through.

Likewise with much content that's intended to be browsed -- unless you know already what you're looking for, you may just scan through pages of material like you'd browse a newspaper sequentially (instead of using flipping to specific pages or sections).

Giorgio said...

I think classical pagination can be replaced in this case by the lazy loading of pages sections, like explained in the article. Twitter and Facebook do it and the link can be degradable to favor accessibility by bots; if I have to go to page five of a result I would prefer to load page 2,3,4 and 5 sequentially in the original page, as for instance this way I can use the Find browser button. Though, there are more complex cases where this will not succeed, such as going to page 100...

Jason Hemmingway said...

Do you prefer to read a book in 1 long page or 500 seperate pages?

test said...

please replace holy script that written in Hebrew by scroll that written in other language for religious people feelings.

ShareThis