Real pagination vs Next and Previous buttons

Question

By real pagination i mean something like this when in page 3:

<<Previous 1 | 2 | {3} | 4 | 5 |...| 15 | Next>>

By Next and Previous buttons i mean something like this when in page 3:

<<previous Next>>

Performance wise im sure the Previous and Next Buttons are better since unlike the real pagination it doesn't require over-querying the database. By over-querying the database i mean getting more information from the database than what you will need to display on the page.

My theory is that the Previous and Next Buttons can drastically increase a site performance as it only requires the exact information you will need to display on a page, please correct me if im wrong on this.

so,

do users really have preference when it comes to this two options?

is it just a Developer preference and its convenience?

Which one do you prefer? why?

*Note: Previous and Next Buttons are usually labeled Newer and older.

Answer 1

In my experience, it just depends on what the client asks me. And when I have my own choice, i go for what you call real pagination because it is more user friendly.

<<Previous 1 | 2 | {3} | 4 | 5 |...| 15 | Next>>

Answer 2

do users really have preference when it comes to this two options?

Yes. I don't want to press Next 12 times if i just want to get to page 15.

Answer 3

If done correctly, doing numbered pagination shouldn't be any hit on performance. remember that the number of queries performed on the database are a much bigger factor than the amount of data the query is returning. In both cases, you should be able to get what you need in one query.

As far of ease of use, it's debatable, and it depends on your app/users. just using previous/next is simpler, but the other provides more options and can make it easier to skip around. I prefer the numbered pagination most of the time, but it's still a matter of personal preference.

Answer 4

You shouldn't need to fetch more than a single page's data when doing real pagination either; you just need to know the count of all of the records (and the number of records that will fit on each page.

From a usability perspective, having direct links to the pages is a huge win, especially if the user knows which page he wants to go to. If you have a large number of pages, you may want to truncate it somewhat, byt presenting links like this (suppose you were currently on page 7, and there were 99 total pages):

1 2 3 ... 6 7 8 ... 97 98 99

Answer 5

If you aren't getting total count of possible pages from the database then you may end up with an inconsistent user experience if a user goes to click next and there isn't anything more to show. They may think that the site is broken or something is wrong. I would stick with showing page numbers using the tried and true template:

 [first, [#], [#], ... [previous|#], [current|#], [next|#] ... [#], [#], last] 

Answer 6

When I was inexperienced, I made a site and opted for Next/previous. I happened to work on that site yesterday, and that was one of the things I considered a novice mistake. There shouldn't be a performance difference, and if there is it's negligible compared to your users frustration a the extra clicks required to go down the list.

Your users experience is way more important than saving a few cpu cycles. You may say, "But what if the site gets insanely popular and goes down because of my resource intensive pagination links?" my reply would be, "How did a site that is hard to use get so popular?" (I would also suspect that the pagination was not the real culprit)

Answer 7

I suppose in user term, if the item doesn't show up on the first two pages, they don't click "Next" for infinite pages but rather make a whole new query.

This can be expensive in terms of database queries. Let's suppose there is a car website and I type in, "2010 Ford Ranger." Now my expectation is that on the first page, I would see 2010 Ford Rangers. If I see other year or other companies, I would most likely go back and attempt to search again using different terms or what not.

So I think the first step is to get back the correct results for a user on the first few pages, assuming that they're searching for material.

Then for pagination, I suppose the biggest question is how you want to do it. You can use a memcaching where you store the total results into memcache, then simply store a unique id.