+ 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). +
++ 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. +
++ 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. + +
++ 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. +
++ 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. +
++ 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. + +
++ 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
@@ -216,6 +222,31 @@ export const PaginationExample = {
demo:
+ You can use EuiTablePagination to create a
+ combination "Rows per page" and pagination set, commonly
+ used with{' '}
+
+ tables
+
+ . If you pass
- You can use{' '} + Or you can use{' '} EuiFlexGroup {' '} @@ -234,8 +265,7 @@ export const PaginationExample = { EuiContextMenu {' '} - to set up this pagination layout, commonly used with{' '} - tables. + to set up your own custom pagination layout.
), demo:
@@ -167,5 +168,4 @@ export const TourExample = {
},
},
],
- guidelines:
| + + + Name + + + description + + + | +
|---|
|
+
+ Name
+
+
+
+ name1
+
+
+ |
+
|
+
+ Name
+
+
+
+ name2
+
+
+ |
+
|
+
+ Name
+
+
+
+ name3
+
+
+ |
+