When someone opens a record from a paginated SaaS table and goes back, restore the page, filters, sort order, and useful position in the list. Treat the table view as part of their work. Returning to page one makes them reconstruct that view.
Pagination divides a list into pages. The difficult part is keeping the person's place when the rest of the app changes around it.
Define the table view as a whole
A page number alone doesn't describe the list. Page three of overdue invoices is different from page three of all invoices.
Keep these values together: the search query, selected filters, sort field and direction, page size, and current page or cursor. For a return from a record, also consider the row or scroll position the person left.
IBM's Carbon pagination guidance describes current-page, item-range, page-size, and navigation controls. Restoring the wider view is an application decision that sits around those controls.
Choose where the state belongs
For a shareable table view, put safe, useful state in the URL. That lets a person reopen a link with the same view rules.
Don't put confidential customer information, access tokens, or private search terms into a shareable URL. Use an appropriate private state store for values that shouldn't travel in links.
Browser history can preserve the route through the app. A local view store can retain state for an in-app return. Choose the approach that fits your routing and privacy needs, and define what a hard refresh should do.
Changing state in one place while rendering controls from another creates confusing views. Keep one clear owner for the table's current state.
Reset the page when the result set changes
Restoring a view and changing a filter are different actions. On a fresh filter or search change, usually move to the beginning of the newly filtered result set.
Suppose someone is on page eight. They choose a filter that leaves two pages. Keeping page eight could display an empty table even though matching records exist.
Preserve the chosen filter. Reset the page or cursor, fetch the new results, and show the updated range. Tell the person what changed rather than quietly removing their filter.
Handle records that moved or disappeared
A restored view can't guarantee the same records still exist. Someone else may have edited a row. The opened record may no longer match the filter.
Refresh the data while preserving the view rules. If the previous page is now outside the available range, move to the last valid page and explain why. If the range isn't known, offer a valid route back through your pagination model.
A small message such as “This record no longer matches your filter” helps connect the change to the action. Keep any error separate from a valid empty result.
Try the full round trip
Use a realistic hypothetical list, then follow the journey a customer would take:
- Choose a filter and a sort order.
- Move beyond page one and open a record.
- Return with the browser's Back control.
- Repeat with the app's return-to-list link.
- Refresh the page and check your defined behavior.
- Remove enough records to invalidate the last page.
Also check keyboard use, loading feedback, and the smallest screen your product supports. The table controls and the displayed records should describe the same view throughout.
The next time you add a detail page, include the return journey in the design. Opening a record is only half of that task.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Sources
IBM Carbon: Pagination anatomy, placement, and interaction guidance
Top comments (0)