Q:

Pagination Best Practice

I am not sure on the best way to handle some pagination I need to perform on a table that could potentially get very big (5,000 rows plus).
My first question is should the amount of rows shown per page be dictated only by the layout, or should the amount of pages also come into consideration. For example should I say < 1000 show 20 rows, >= 1000 show 30 rows?
The next question is how best to navigate between the pages, assuming the user has filtered the table as much as they can and they are left with 50 pages of information, should they get an input box to jump to page 45? Or should skip(1) skip(5) buttons suffice?  At this time I don't know how the end user is going to use the tables so I am unsure as to what option to let them try first.
Finally, does anyone have any good examples of pagination done right they could share? I am always looking for good reference material!

A:

This may or may not be pagination done right, but here is how I do pagination in my web app:
|< First, << Previous, Page [5] of 12, Next >>, Last >|

The outer four options are links, while the Page [5] of 12 is a form, with the [5] as an input field. For users with JavaScript enabled, I hide the submit button and submit the form on the unfocus event or enter keypress. The user has the option on how many rows they want to display, which they can select from a dropdown menu: 10, 20, 50, 100, All. I also provide sorting and filtering of the results in addition to pagination, though that may not make sense in every situation.
Edit:
Here's a snippet from a mockup of our web app to give you a better idea. In this version, the words have been omitted from buttons, but appear as a tooltip on hover after a slight delay. However, you may find that keeping the words will result in a higher level of usability. 

A few other things to point out: 

The "First" and "Previous" buttons
have been disabled because it's the
first page.
The blue indicates active buttons (I
will have to run this particular
theme through a color checker to make
sure that colorblind users can tell a
difference).
The buttons always remain, even if
they are disabled. This gives the
interface consistency.
I chose an input field rather than a
dropdown select box because of scale.
If you have 3000 pages, you don't
want to scroll down to find page
The pagination is grouped in a
singular visual component to indicate
similarity in purpose.

A:

Sorry for such an answer, but it depends. What type of content do you have and what the user is looking for? What are user's goals? Is it a website or an application?
In many cases you could avoid pagination at all using infinite scrolling for example (see search results of Google image search).
The problem with the pagination is that pages itself have no meaning. Why should I go to page 45? Why not 38? If the content is sorted, you may try to give pages meaningful names (like letters of an alphabet or dates range or anything else which makes sense). The amount of rows per page should be as big as possible because scrolling usually provides much better experience than navigating through pages (however it's not a general rule and there are some exceptions).
And for the examples and good practices here's a great article.

A:

In general, number of items per page is something you determine based on the following criteria:

What kind of data am I displaying and how long would a given number of items make the page?
What consequences do X items on the page have for performance of the app?
Do I want to allow users to customise the number of items displayed per page?
If I care about interpage navigation (for instance, will a user care about going to specific page no. 512?), how will the number of items per page affect the navigability of the pagination?
What pagination controls are available to me?

If you answer the above questions they'll lead nicely into answers for your second question. Pagination is a product of the data you have and the number of items you're displaying. My advice is to determine whether your users want to specify which page they want to view. You can figure this out by doing user testing as well as thinking about what kind of information is being listed. For instance, search results are rarely specific enough to be able to say "I want to go to page 47" since they're usually sorted by a cryptic, opaque algorithm. But if you're listing, say, names in alphabetical order, going to page 47 can be very intuitive.
Similarly, the data type you're displaying can also affect navigation and you may want to consider the faceted navigation design pattern to simplify things. In the example I just gave about alphabetical names, you might consider pagination by using letters (A|B|C|D etc) and pages within each letter if you have a lot of data.
Concretely:

I don't recommend giving users too much specific control unless you know for a fact that's what they want
Instead, offer padding around the current page (1 .. 7 8 [9] 10 11 .. 28)
Include the first and last pages if you're sorting algorithmically, unless you can't for performance reasons.
If sorting algorithmically, consider various sorting options (such as reversing the sort order) - depends on data type

Examples of pagination done right:

Flickr - clear differentiation between selected, inactive and link state; accessible colours; padded links with good click targets; good padding around the current page; not overly complex. A personal favourite.
Funda.nl - Dutch real estate website with great, simple, easy to read design which is also reflected in the pagination
Bing - no BS, minimalist typography design meaning that the pagination is very subtle but simultaneously easy to use
Google (obviously) - sort of gimmicky, but despite having a lot of options, still feels simple and even brings a smile to your face
Chris Messina has a few good shots of pagination in his design patterns album on Flickr.

