Rows per page

[gavinwye]

In some cases, we display 'Rows per page' under a table when there and fewer rows than the number in the 'Rows per page' component. See the screenshot below.

In that case, we should hide the component until there are more rows of data than the minimum default set for the component.
For example: If the number of available rows of data is 9 but the component is set to a minimum of 10 it would be hidden until there are 11 rows of data.

We should follow this logic until the lowest number (default) of rows to be displayed is 60 or more rows. In which case we may want to allow users to show less than the default to reduce complexity on the page.

Screen shot

Original issue: elastic/kibana#121755

[cchaos]

Thanks for opening this discussion @gavinwye. It's definitely a lot less controversial than the original ask of removing the actual arrow/number pagination.

I think it makes sense in the context of limited results to reduce the complexity of the UI to only what would actually affect the UI. In this case, changing Rows per page wouldn't actually affect the results in the table. This is especially confusing when there can never be more than the smallest option for rows per page (meaning they didn't search or filter to reduce the table rows).

However, I do want to discuss that particular scenario of when the rows have been reduced because of searching or filtering.

To talk it through, consider these steps:

1. User lands on Exceptions.
2. There are 300 total, showing 20 rows per page, with 15 pages total.
3. User changes "Rows per page" to 50 to see more.
4. Total pages are reduced to 6.
5. User types in a term which reduces the table row count to 40 rows.
6. Even though it's only one page, user should still see the "Rows per page" option because the smallest option is 10.
7. User narrows search term further reducing the table row count to just 9 rows.
8. The "Rows per page" option hides because the smallest option is larger than the resulting row count?

My guess is this makes sense because that option will no longer affect the visible data/UI. But I think it's worth testing out in a real prototype to see if it feels weird to have the button hide/show.

[gavinwye]

I agree that sounds sensible and it would be good to see it in a prototype.

[cchaos]

Can you explain further what you meant in your last paragraph?

We should follow this logic until the lowest number (default) of rows to be displayed is 60 or more rows. In which case we may want to allow users to show less than the default to reduce complexity on the page.

I wasn't quite following why the distinction specifically for the number 60.

[gavinwye]

I picked 60 a little at random. I wanted a big enough number to show a lot of results.

The point really was if the table is likely to have a lot of complexity in it users should be able to reduce that complexity. Although thinking about it again I'm tempted to say we should be doing the hard work for users to reduce this complexity. Not, adding features to the interface so they can reduce the complexity. I see something like this as an advanced feature and users very rarely use advanced features unless they are power users. 🤔

[gavinwye]

I've looked in more detail at the analytics for this element in Fullstory and created a segment called Rows per page clicks that shows there are 76 events for this element with less than 1% of users using it.

If there are so few people using the element I wonder if it's doing its job well enough? Is it that the number of rows per page is working for users or people can't find the element? Maybe something for some user research...

[snide]

@gavinwye Looks like your selector in you test was a little too specific. Using the tablePaginationPopoverButton test subject gives me about ~19% conversion when removing trials (which you should do anytime you analyze non onboarding UI). The more generic selector capture usage includes both data grid and table usages. Will send some links.

[cchaos]

Thanks for the explanation and I 100% agree we should not be requiring the user to reduce complexity and the system should try to be smarter. However, I still don't think that a single default number will work for all use cases. For instance, you could have more rows if the entire page is the table (like a list of Dashboards), but probably less rows if it's a table within Dashboard panel.

Which is why our UI library, specifically, can only do so much by providing best practices through guidelines. It's up to the feature team to decide the best defaults/options for their table instance.