Difference between revisions of "Pagination"
Jump to navigation
Jump to search
| Line 33: | Line 33: | ||
<li>In all in-between pages, both buttons are enabled.</li></ul> | <li>In all in-between pages, both buttons are enabled.</li></ul> | ||
===Prev/Next with item counts=== | ===Prev/Next with item counts=== | ||
This pattern consists of a Previous button to move to the beginning of a list of data items, a Next button to move to the next set of results, and in between a count of the items showing and the total number of items. | |||
====Use when==== | |||
<ul><li>Paginating through a data set where informing the user of the number of items in the data set (and which ones they're viewing) adds context.</li> | |||
<li>A minimum of 1 result in the data set is required to use this pattern.</li></ul> | |||
====Do not use when==== | |||
<ul><li>The content you're paginating is paged content (ie. paragraphs of stuff or single records). Use the Prev/Next only pattern in that case.</li> | |||
<li>If there are no results, display the no results message in the table and do not display the pagination.</li> | |||
</ul> | |||
====Behavior==== | |||
<ul ><li>On page 1, Previous is disabled (but displays).</li> | |||
<li>On the last page, Next is disabled (but displays).</li> | |||
<li>In all in-between pages, both buttons are enabled.</li> | |||
<li>Display the number of items in plain text.</li> | |||
</ul> | |||
====Optional addition==== | |||
Bracket the Previous and Next buttons with First and Last links if the user is likely to need to rapidly move to the front of the list. (If the user is more likely to go somewhere else 99% of the time, don't include these, because they're clutter if the use case isn't regularly exercised.) When on the first or last page, do not display those links (because "disabled link" shouldn't be a thing.) | |||
==Additional Resources | |||
<ul ><li>[https://uxplanet.org/ux-infinite-scrolling-vs-pagination-1030d29376f1 Infinite scrolling vs pagination] by Nick Babich on UX Planet. The summary: there's only a few places infinite scrolling is appropriate and not annoying. Don't overuse it.</li> | |||
<li>[https://www.smashingmagazine.com/2007/11/pagination-gallery-examples-and-good-practices/ Pagination - examples and good practices] by Sven Lennartz on Smashing Magazine. This one's from 2007 but the examples are still frighteningly valid.</li> | |||
<li>[http://uxmovement.com/navigation/avoid-the-pains-of-pagination/ Avoid the pains of pagination] on [[UXMovement.com]]</li> | |||
<li>[https://www.bennadel.com/blog/2951-the-user-experience-ux-of-pagination.htm The User Experience of Pagination] by Ben Nadel</li> | |||
<li>[https://www.nngroup.com/articles/item-list-view-all/ Users' Pagination Preferences and "View All"] by Jakob Nielsen on Nielsen Norman Group </li> | |||
<li>[https://gist.github.com/brajeshwar/2802235 Pagination Best Practices] by Faruk Ateş</li></ul> | |||
Revision as of 13:05, 1 June 2020
Pagination is an in-page navigation element that allows users to move between multiple pages of data for a single data set. It can also be used to provide multiple pages of an article, but that's not necessarily a best practice.
There are literally thousands of ways to display pagination, but good pagination has a few things in common:
- Page lengths are reasonable.
- Some users want to "view all" and that's a valid choice so long as it won't take down our servers or their browsers. Performance is a big factor here in both directions -- users might want to display all just so they only have to deal with load times once, and on the other hand the load times for "all" may be atrocious.
- For content, users would prefer to scroll down a page than click and wait for content to load.
- For data tables, or a list of products or items (aka Amazon) 25-75 items is reasonable for a list of products or items.
- Global search results for a website generally don't climb above 20.
- Items that can be visually compared (such as eBay search results) may range as high as 300.
- Infinite scroll is rarely the right answer for a website like Boomi's but for something like Pinterest, it may be the right answer.
- The controls are easy to tap or click. We want them easy to locate and easy to hit. If providing numbers for pages (i.e 1 2 3 4) make sure they're spaced far enough apart that they can easily be clicked.
- The current page is clearly identified. This is very important for data tables, but if paginating through multiple pages of content, the page's content will do.
- Provide "Previous" and "Next" links. Labels work better than just iconography, especially if it's small.
- Make sure it's keyboard accessible.
- Give the user an idea of the size of the results. For short result sets this might be done by providing clickable numbers between the navigation buttons ( <Previous 1 2 3 4 Next >) and for long lists this might be done by providing current location (<Previous Page 5 of 15 Next> or <Previous 1-15 of 30 Next >)
Nick Babich recommends against providing First and Last links in his article [href="https://uxplanet.org/pagination-best-practices-76fbd3f5a78d Pagination Best Practices], but I'mnot so sure he's got that one right.
Pagination design patterns
Prev/Next only
A Previous button to move backwards in the results, and a Next button to move forward.
Use when
- Paginating through content or a list of items where the number of items (or pages) is obvious through other means on the page.
- A minimum of 2 pages is required to use this pattern.
Do not use when
- Pagination is showing result sets of multiple items. Use the Prev/Next with Item Counts pattern instead.
- If less than 2 pages, do not paginate.
Behavior
- On page 1, Previous is disabled (but displays).
- On the last page, Next is disabled (but displays).
- In all in-between pages, both buttons are enabled.
Prev/Next with item counts
This pattern consists of a Previous button to move to the beginning of a list of data items, a Next button to move to the next set of results, and in between a count of the items showing and the total number of items.
Use when
- Paginating through a data set where informing the user of the number of items in the data set (and which ones they're viewing) adds context.
- A minimum of 1 result in the data set is required to use this pattern.
Do not use when
- The content you're paginating is paged content (ie. paragraphs of stuff or single records). Use the Prev/Next only pattern in that case.
- If there are no results, display the no results message in the table and do not display the pagination.
Behavior
- On page 1, Previous is disabled (but displays).
- On the last page, Next is disabled (but displays).
- In all in-between pages, both buttons are enabled.
- Display the number of items in plain text.
Optional addition
Bracket the Previous and Next buttons with First and Last links if the user is likely to need to rapidly move to the front of the list. (If the user is more likely to go somewhere else 99% of the time, don't include these, because they're clutter if the use case isn't regularly exercised.) When on the first or last page, do not display those links (because "disabled link" shouldn't be a thing.) ==Additional Resources
- Infinite scrolling vs pagination by Nick Babich on UX Planet. The summary: there's only a few places infinite scrolling is appropriate and not annoying. Don't overuse it.
- Pagination - examples and good practices by Sven Lennartz on Smashing Magazine. This one's from 2007 but the examples are still frighteningly valid.
- Avoid the pains of pagination on UXMovement.com
- The User Experience of Pagination by Ben Nadel
- Users' Pagination Preferences and "View All" by Jakob Nielsen on Nielsen Norman Group
- Pagination Best Practices by Faruk Ateş