I have a table of data pertaining to stores. The user has the ability to group the data by Store Name, which will display the Store Names in a collapsed view with a (#) that indicates how many rows that Store has. The user can expand the Store Name to view the data related to that store.

The max number of rows that we currently show on one page is 100. When the rows are grouped by Store Name, should the pagination occur based on individual rows or based on the count of Store Names?

For example, if the max number of rows is 100, let's say when we group by Store Name, the last Store in the list has 10 rows but that would bring the total count to 105.

enter image description here

What is the most intuitive option for the user?

a.) Display the first 5 records of that store with a note to the user that the records are continued on page 2

enter image description here

enter image description here

b.) Don't display this store at all on Page 1, leaving the total number of rows on page 1 equal to 95 rows. Display this store on Page 2.

c.) Any other approaches I can try?

3 Answers 3


(c)! My clear preference (and recommendation) is to always use continuous scrolling instead of pagination - precisely because of such problems. The design issue is caused by a development/architecture decision, and the dependency should be the other way around (UX defines requirements for architecture to solve). There are techniques like "lazy loading" etc. which will of course cost more development time, but eliminate this UX issue.

(b) is tricky: Why is the "Sweet Cakes" store expanded? Because the user expanded it. After expanding, you need to make sure the user sees the expanded store. So the list would need to jump to page 2 because not all expanded items fit on page 1. That's jarring, because expansion usually does not trigger paging, and the user looses focus (all existing rows are gone - what if I wanted to compare with "Applebees"?). The least disruptive interaction is probably to scroll to show all items from "Sweet Cakes", but that involves a more flexible paging which is not limited to predefined row counts (i.e., page needs to start at row 89 of the list, not on 1, or 101, or 201, ...).

(a) can be equally frustrating, if the store name is on row 100: Expanding it will not even show anything more informative. Again, can be solved similarly to (b), but that might just push out what I wanted to see in parallel.


Usually, for some case that commonly happen, table that grouping by a category (in this case, Store Name) will display limit based on the group. maybe because the system is limit the rows number based on the parent/group (the store name). From development perspective the logic more simple than limit based on child (data inside the group). you will think how to separate the row that more than limit.

but, if you think that "it'll create too many rows." you could automaticaly decrease the row number limit when user choose to group the data.


Let's simplify the problem: When one store has 105 rows, it will only show 1 collapsed row, but expanded it will show 100 rows. There are three questions to ask here:

  • Does 1 collapsed row make sense to the user (remember this can be 2, 10 or 50 collapsed rows etc. the question remains the same)
  • Logically you need to limit the amount of data loaded and 100 rows is the chosen amount, how to show the remaining rows for a store if it exceeds 100 rows? This is the question you are asking but without the limitation of the existing solution, pagination
  • And the obvious question for tables in general; What data is relevant to compare and show at once?

From your own research you should consider the following:

  • If users will only expand one store at a time to its rows, are users better served by filtering or searching a store and show only a table with rows for that store?
  • If stores never will have too much data, can stores be the only rows counted and expand with all data? If the expanded data is all the data for the store and isn't part of the 100 rows maximum, this would eliminate the pagination problem. Maybe you should reduce the total amount of rows since now it only counts for stores and you still need to consider performance. If a store has more than x amount of rows, maybe you can add a "show more" link that opens a modal or page with an overview (or new table with pagination for this store).

Both considerations are simplifying the table concept. This is what I advise to focus on instead trying to fix the problematic pagination concept.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.