
Pagination 101 - rayshan
https://gist.github.com/mislav/622561
======
Gracana
> 5\. Provide Previous and Next links

Wait! Give them better names. "Older" and "Newer" can be helpful on blogs and
such, when it's not clear whether "next" means "more recent" or "deeper into
the archive."

~~~
unicornporn
Honestly, I don't know where "Next" and "Previous" idiocy stems from, but
Older and Newer is what I've used too. Now that I think of it, perhaps I
should write Greasemonkey script to try to replace next and previous where
applicable.

~~~
dspillett
_> I don't know where "Next" and "Previous" idiocy stems from_

Next page and previous page.

It is usually the default wording because when making a generic paging routine
you don't know if things are going to be sorted ascending or descending, or if
they are in date order, numeric order, alphabetic, in the order of the
author's first pet's birth month, or something else entirely. Sometimes a
framework has no option for changing the captions, and sometimes we as devs
are lazy...

Where the ordering is obvious next/previous is fine, but as you say it is much
better to be more precise about what you mean if at all possible.

~~~
unicornporn
> Next page and previous page.

Yes, I understand that it has its roots in print. But on a screen that isn't
physically chronological it becomes more complicated.

> Sometimes a framework has no option for changing the captions, and sometimes
> we as devs are lazy...

I guess that's a good explanation :-)

------
chrismorgan
One related idea (to do with pagination itself, not just the pagination
controls) I’ve had that I’ve never seen actually implemented:

Where showing _n_ elements per page, if the last page would have no more than
ε elements in it, _merge it with the previous page_.

e.g. _n_ = 10, ε = 2, so a data set of 21 elements might go over two pages of
10 and 11 elements rather than three of 10, 10 and 1.

Sure, SQL LIMIT queries and all that, but it’d tend to be nicer for the user.

~~~
coolsunglasses
>Sure, SQL LIMIT queries and all that, but it’d tend to be nicer for the user.

You'd need to keep a count to do that and a lot of tables you'd bother to
paginate, a COUNT( _) is way too expensive.

Okay so lets say you keep a cache of the COUNT(_).

What if you're off? Now you have confusing, irregular behavior that throws the
user off.

Is this something you've tried in an actual application before?

~~~
Pharaoh2
Count on an indexed column is a pretty fast operation and it's always correct.

~~~
calpaterson
count(*) is a linear time operation (roughly to the size of the table) on
postgres. It does an index-only scan but with a sufficiently large table/index
it's still a problem. It's to do with postgres MVCC implementation. I don't
know if other SQL databases have this problem. MySQL doesn't seem to.

~~~
anarazel
It's a problem in mysql too, unless you use an engine like myisam, which isn't
realistic in most scenarios due to durability and concurrency concerns.

------
olalonde
Maybe add (2007) to the title? The article this is taken from is from 2007:
[http://www.kurafire.net/log/archive/2007/06/22/pagination-10...](http://www.kurafire.net/log/archive/2007/06/22/pagination-101)

------
jalfresi
Absolutely disagree with number 2; if the numbers are hyperlinks to other
pages they should be underlined. The underline on links informs the user that
it is a link to another page (i.e. they will be navigating away from the
current page), that the interface is page based, that clicking the link will
add the current page to the history and that their back button will work, etc,
etc.

Removing the hyperlink makes the numbers look like numbers. The user will have
to "learn" that they can click the numbers.

Oh, and make them blue!

~~~
seivan
It's a visual design issue really, and not just purely usability light the
rest. By now, most people are aware of how paginations work.

I agree with you, but I am just stating that at most, it only serves as purely
aesthetics. You could replace underlines, with hover with a transition effect
or animate on appearance (as going back or forwards), etc.

~~~
jalfresi
"..You could replace underlines, with hover with a transition effect or
animate on appearance (as going back or forwards), etc."

No, that misses the point. An underline has a very specific meaning. It is not
just aesthetics. If put a handle on a door that you push to open, people will
pull on the door on their first attempt. By doing this you've changed the
meaning of a handle to all users of the building. Now, a user can no longer
rely on the visual affordances provided by "door handle". They must navigate
and interpret each and every interaction with a door in that building.

Removing an underline remove a very important part of what an hyperlink is.
And I would argue that the colour of a hyperlink is just as important.

~~~
mikekchar
But an underline is arbitrary. Similarly the colour blue is arbitrary. You
only think that it makes sense because that's what is currently common.

If you had never used a computer before, there is nothing discoverable about
blue underlined words. They could be red italics and it would make absolutely
no difference. A handle is shaped to make it possible to open a door. It has a
discoverable purpose (some handles more than others).

If we decide that arbitrary UI representations should stay just because they
were historically common, then we will never improve our user interfaces. I'm
all for avoiding surprising the user, but saying that an underline has an
intrinsic meaning for a hyper link is just wrong.

~~~
jalfresi
"If we decide that arbitrary UI representations should stay just because they
were historically common, then we will never improve our user interfaces."

Putting aside the assumption that hyperlinks require improvement, you've
mistakenly declared that certain visual attributes were chosen arbitrarily and
therefor are fair game to change. But it is those very same attributes that
provide the visual affordance required for users to determine the function
they perform. That is, whilst the selection of those attributes, in the
beginning, may have been arbitrary, they no longer are. Consistency in
application is one of the best ways to pass on knowledge. Whilst blue
underlined text doesn't have anything that intrinsically suggests its action,
consistent application of that visual language builds up the affordance in the
user: all blue underlined text is a hyperlink.

Look at it this way; at some point in the past someone decided that the
highlight on GUI buttons should appear to come from the top-left of the
screen. This was a completely arbitrary decision. However, with the rest of
the GUI adopting the similar design decision, a cohesive impression is built
up. It became obvious to users that this meant that a button was raised and
could be clicked with the mouse cursor.

But if you design your GUI with the highlight coming from the bottom-right, no
matter home much better you think this will improve the GUI and how much more
sense it makes, your button will appear to be inset and selected. That is,
whilst the selection of those attributes, in the beginning, may have been
arbitrary, they no longer are.

And so it is with hyperlinks. Hyperlinks are underlined blue text because they
are. Unless there is some radical, obvious improvement to be made, any changes
to these attributes will be to the users detriment. Most often, these changes
are attributed to improving integration with the web page design, introducing
cohesiveness, but this is mistaking hyperlinks as elements of the design. They
are not, they are UI elements and as such should sit outside the style of the
web page.

With the politest of respect and IMHO of course :)

~~~
JoeAltmaier
Any 'detriment' will be temporary. We all play games with novel controls, and
are willing to learn that. Why not a new browser? In fact, something new could
get a cult following, if its actually even a little better in any way.

I'm in favor or innovation, even in user interfaces. Otherwise we'd not have
automatic doors (which had remained unchanged for 2000 years) or windows that
slide up and down. Or TV remotes.

------
joshmn
Something I absolutely hate: varying alignment.

When I'm trying to rip through pages to find something and I can't just sit
there and click, instead I have to move my mouse around (so lazy over here),
ugh, it drives me insane.

~~~
mercer
This is a good example of how important it is to work with actual data,
representative dummy data, or at least to try and simulate these things. When
pagination is built, the fixed-width page number links are often based on a
single integer, which of course breaks down once you get more content.

A huge amount of 'bugs' I run into as a front-ender are of this kind. For
example, someone designs a nice three-column layout with title, subtitle, and
text underneath each other. Each of these columns is fixed-height as well
(usually a bad idea in general, but it looks very ugly otherwise).

This works fine in the design phase, where titles are written to fit the
element, but once you start working with real data, you run into a problem:
one title might be three lines high, while another is only a single line high.
Since you want the 'columns' to be fixed height, you now have to add a lot of
whitespace underneath the one-line title, so that everything lines up with the
three-line title element.

Then you realize that you have the same problem with the subtitle and content,
so now you end up with ridiculous amounts of whitespace between title,
subtitle and body, depending on the length of the text within.

I've often tried to preemptively address these issues as a front-ender, but
aside from this not really being my job (that's where the value of a UX
designer comes in, I guess? Or at least a web-skilled designer), I can't
always predict these kinds of things either.

So the best solution I've found is to always try to work with real data, or
create enough 'random' fake data to fix these kinds of issues.

------
_RPM
One pagination that I really don't enjoy using is GitHub's "Newer" and "Older"
links when you're viewing the commit log. Luckly, the URI has a `page=`
parameter and I'm able to put in some arbitrary numeric strings to try and
guess which would be the last page. Because I like to see the first commit of
really mature projects when I'm just browsing sometimes.

~~~
gregory144
I know it would be nice to have it built in to GitHub, but you can try this as
well: [http://first-commit.com/](http://first-commit.com/) (and comments:
[https://news.ycombinator.com/item?id=10610065](https://news.ycombinator.com/item?id=10610065))

------
JoshTriplett
One other key: don't identify current position by index, because then you'll
miss or duplicate items when the list changes. If you show 1-10, then a change
in the background adds 5.5 between 5 and 6, the next page will show 10-19.
Worse, if a change in the background deletes 5, the next page will show 12-21,
missing 11.

So instead, when showing items 1-10, the link for the next page of results
should query for the next page full of items start after item 10.

That still lets the user miss added items (mostly unavoidable unless the list
is sorted by "things the user hasn't seen yet"), but doesn't miss items when
deleting seen items.

~~~
calpaterson
Doing it this way is known as the seek method/"keyset pagination" and it's
also quicker when you're quite deep in the list:

[http://use-the-index-luke.com/sql/partial-results/fetch-next...](http://use-
the-index-luke.com/sql/partial-results/fetch-next-page)

------
hamhamed
This was written 5 years ago FYI. Things look better today with bootstrap and
devs copying each other thus a unified UX among websites get crafted

------
WA
Years ago, I never used "Next" in Google's search results, because I thought
it would bring me to page 11. The next page after 10, because 1..10 were
clearly lined out.

Took me a while to understand that "Next" works differently and is somewhat
misplaced after "10".

~~~
oneeyedpigeon
I think the need for "Previous" and "Next" is overstated. Unless your
pagination is pixel-consistent from page to page (and at the top of the page),
it's going to be fiddly to repeatedly press anyway, and that's the only real
benefit. Normally, if you're scanning the pagination links, you'll reach the
next page by number way before you reach the "Next" link (obviously, that's
not the case with Previous, though!).

Same for Start and End, really, if you adopt the 'show the last page or two'
approach, so this is possibly better:

    
    
        [1] [2] 3 [4] [5] ... [19] [20]
    

You can then omit a whole class of concerns and just concentrate on the few
remaining elements relating to the page numbers themselves.

~~~
ajanuary
People don't scan linearly; they recognise the pagination controls as a block.
It's much quicker to jump to the end of the pagination block to find the
"next" link than to scan through all of the numbers to find the current page
and then find the next page.

Also, you're forgetting about the fact the bottom of the page forms a
boundary. If you're pagination is at the bottom of the page it is consistently
the same distance from the bottom after you scroll all the way down.

If you have a mousewheel you can take advantage of this on Google. After you
click next the first time, leave your cursor in the same position and use the
mousewheel to scroll as you scan the results. Once you hit the bottom, the
cursor is over the next link and you can just click.

Even if the user isn't advanced enough to use a mousewheel, they can still
become familiar with the position of the next link relative to bottom left of
the page.

------
jtwaleson
I built something cool for a client a couple of years ago. When sorting on
price (or title, or anything), it shows you the price range (or title..) in
that page ($100 - $350) on mouse hover in a tooltip. Surprisingly it's not
something I've ever seen anywhere else.

This way you can instantly jump to the price range you are interested in.

[http://blog.waleson.com/2011/03/design-pattern-pagination-
wi...](http://blog.waleson.com/2011/03/design-pattern-pagination-with-
useful.html)

I think no one does this because SQL syntax just gives you COUNT and LIMIT
primitives so those become the terms that developers think in.

------
kmfrk
This seems like it's aimed a general users, not users with screenreaders.

Also remember to use class="current" (or some such) and rel="next" and
rel="prev".

------
prawn
I remember a comment once that pagination could be a sign that you need to
provide better filtering or search options. Not so relevant for online comics,
but consider a store where you're in the Camping section and there are 800
results.

The user is likely to be better off with sub-category filters (tents, sleeping
bags, etc) or a nice, fat search box with auto-complete.

My pet peeve with pagination is when the default items-per-page is something
pitiful like 10 when it could be 50-100. NameCheap did this for a long time
when listing your products in the Control Panel - it was agonising!

------
kalonis
Pagination is an often overlooked aspect of search engine optimization.
Imagine you have a pagination like "<prev 1 ... 23 24 _25_ 26 27 ... 100
next>". As you can only reach the two pages next to the current page the 50th
page is 25 hops away from the first page. The depth of the paginated pages
would be in O(n) with a pagination like this. A pagination wich offers a
better crawlability would not only link to pages in the direct proximity but
to pages further away: "<prev 1 ... 10 ... 24 _25_ 26 ... 50 ... 100 next>".
In this way you may bring the depth of your paginated pages into O(log n).

~~~
Pharaoh2
[https://en.wikipedia.org/wiki/Skip_list](https://en.wikipedia.org/wiki/Skip_list)

------
dspillett
_> 4\. Space out page links_

This is particularly key when using a small tablet or phone. On many sites it
is difficult to hit the right thing without zooming first and many of the
sites I find "broken" in this way also somehow disable zoom. In these
circumstances I'm more likely to go look for the same information elsewhere
than persevere.

------
guard-of-terra
I had this innovative idea for working with datasets - show pagination like
this:

Page 1. Next 20>> Next 40>> Next 80>>

I.e. you can request larger pages right from pagination block if you think you
need them. (And on that page you will be able to downsize page or make it even
larger)

But I have to admit, load-on-scrolling does make it more or less obsolete.

------
gpmcadam
Previous discussion:
[https://news.ycombinator.com/item?id=4028623](https://news.ycombinator.com/item?id=4028623)

------
wereHamster
I was hoping for details about how to implement it on the protocol level :(

------
vatotemking
Which is better, pagination or infinite scroll?

~~~
pavlov
Infinite scroll is usually terrible with browser navigation. If you can assume
that the user stays within your page and doesn't need to navigate back and
forth, it may be a reasonable option.

But for something like Tumblr or Pinterest, it's awful. When the user sees an
interesting post, she clicks on it to open the page. Then she navigates back
to the main page. But wait -- the infinite scroll's contents have been lost on
reload. Now the page shows the top of the scroll, rather than the position
where the user actually was when she clicked a link. It may be a long, long
way to scroll back to where she was, with numerous loading progress indicators
along the way...

~~~
rawTruthHurts
And what about the scrollbar going haywire as you scroll down, or the
inability to go back to that fancy thing you found a minute ago, or the
browser performance hit, or just anything else related to it.

