Pagination guidelines
Don’t rely on pagination for users to find what they’re looking for
For any results-style table, always provide ways to filter, search, etc for the thing that the user wants. Pagination is only helpful once the user has reduced the 1000+ results to just 100 (for example).
Don’t rely on pagination to indicate total results
When possible, always present a clear indicator of how many (and if not all results) have been returned. Just a simple count will do. Including a detailed summary of results at the top of the table or list goes a long way to signify what paging can’t.
Indicate indeterminate results
If you cannot provide a concrete number of results, you still have to communicate what the current results showcase. For instance, say "Showing first 100 results" or "Search results maxed at 1000" or "Results fetched at runtime".
Remember that not all users understand how your data API works. They just care about the data that's being shown to them.
Give users control of pagination
Providing a “Rows per page” option is often helpful enough to provide users control over the amount of data they see at once.
Keep the choices simple and only show “Rows per page” if there are more rows than the smallest option. For example, if there are only 9 rows and the smallest option is 10 rows per page, hide the selector.
Do: For shorter sets of data, you may want to include an “Show all” option.
Don't: Overload the user with choices, stick to only 2-3 options.
Optimize your defaults
Most users don’t customize the default view. Therefore, it’s vital that you provide optimal defaults and reduce complexity as the number of entries increase. This means choosing a default “Rows per page” that best corresponds to the total results. For instance, 1000+ results shouldn’t start with 10 rows per page, but rather 20 or 50.
Here are some samples of what controls to provide based on the number of data entries.
Total entries | Rows per page options | Pagination style |
|---|---|---|
Total entries 0 | Rows per page options Use EuiEmptyPrompt in place of table | Pagination style N/A |
Total entries Less than 50 | Rows per page options Show 10, but allow All | Pagination style |
Total entries 51 - 100 | Rows per page options 10, 20, All | Pagination style |
Total entries 101 - 200 | Rows per page options 10, 20, 50 | Pagination style |
Total entries More than 200 | Rows per page options 20, 50, 100 | Pagination style |
Total entries Unknown | Rows per page options Depends on what you expect the total entries to be | Pagination style |
If the total results are unknown, you can make a best guess based on the context of that specific table, whether there’s most likely going to be tens or thousands of results. From there you can decide to show 10 rows per page or 20 by default.
The complexity of the data will also contribute to this equation, which is why the table above is just a sample.
Preserve the user-customized state of pagination
When providing pagination, customizable display options, and data filters, always save the user’s state in some form. This is especially important if your data includes links that navigate a user away from the current view. There’s nothing more frustrating for users than going back to find their filters and pagination have been reset.
Below is a working example that utilizes localStorage to save the table’s state.
Don’t use infinite scrolling
Infinite scrolling, i.e. loading data as the user scrolls, is the exact opposite of being able to save the user’s pagination state. As soon as they navigate away from the page, their position in the list is lost. It’s better to increase the quantities of rows per page or provide a “Load more” action.
Do: Provide a direct action for users to initiate the loading of more data.
Don't: Use infinite scroll to automatically load more rows of data.