Page size should be adjustable
Aliases: rows per page · pagination density
What it is
How many rows sit on a page sets scanning density, request size, and how many pages exist. Adjustable page size lets the same pager switch between “few and clear” and “many and overview” by task. It is not how pages are numbered, and not whether a distant page can be jumped to. It is whether chunk granularity is locked to one default that fits nobody.
Why it happens
The default count is a designer’s guess at “what one screen can scan”. People who compare, tick, or read long cells need fewer rows so a checked item is not lost in scroll. People who scan a catalogue or many fields need more rows so the page count does not swell into an unfinishable distance. Granularity also binds to network and rendering: double the rows and one request plus table reflow cost more, while round trips drop. A locked size forces every task, every connection, and every window height to share one cut.
Changing the count rewrites the coordinate system: yesterday’s page 5 is not the same objects at the new size. If the product does not say so, and does not keep the user near the same record, adjustable size destroys the revisability page numbers were supposed to give. So the control is not an isolated dropdown; it has to re-anchor “which stretch I am looking at”.
Where it stops holding
If a shared page address writes page size into the URL, recipients see a different density — useful or chaotic depending on the scene. Shared views often want a stable default, with size kept as a personal preference locally. On mobile, one screen is already close to the default count; offering 100 rows turns the page into a long scroll and pagination stops being a cut. Streaming APIs with no total cannot cut stable pages by count; adjusting then becomes “fetch a little more each time”, which is a different control. Assistive-tech users may need fewer rows per page so speech does not overrun working memory; a forced large page fights that.
Applying it
- Offer a few steps (10 / 20 / 50), not an arbitrary integer as the main path. After a change, keep filters and anchor the viewport on the row that was in view, or its neighbour.
- Remember the chosen step as a preference for that list; do not reset it every visit. Be explicit about whether share links carry the size or use the default.
- Hide the control when the total is tiny. Avoid an “All” step when the total is huge, or one render will sink the page.
- How to check: while looking at a record mid-page n, raise the size and lower it. That record should stay near the viewport and the page count should move. Then change window height and network class and see whether the default is still scannable and loadable; either failure means the steps are not decoration.