I have an issue with a table with pagination that doesn't have fixed column widths. I've been discussing with a colleague whether we should put fixed widths or not. So the approaches are: - Columns should not change with when changing the page, ever. - It is ok for columns to change width a bit when paging for a better fit of the content.

Which solution is best?


It's definitely ok to change column widths for different pages.

Why would you keep column widths of cells that aren't in the table anymore and sacrifice readability?

I work on a B2B application that largely consists of tables with pagination and it's definitely not wanted by our customers that column widths don't make sense compared to the contents of the table. See my examples below what I mean.

Using fixed column widths is not a better idea. To find the ultimate width for columns and still make efficiently use of the available space on all pages will be very hard if not impossible. It's better to adapt column widths to their contents and make the table a lot more efficient and useful, this counts for each page.

If comparing columns between pages is needed or highly desirable, pagination might not be the best implementation. Create a filter that users can customize to show only the rows to compare. And/or add options to show more rows on the page or maybe even consider showing the whole table at once.

Page 1
enter image description here

Page 2 with column widths kept from the previous page enter image description here

Page 2 with columns widths adapted to the content
enter image description here

With fixed column widths
Getting it right is not easy, maybe even impossible:

Page 1
enter image description here

Page 2
enter image description here

  • Ok, I had the same idea than you, but I see some answers saying the contrary – Joanvo Oct 3 '17 at 12:10
  • When I started working on this software I also thought that it was a better idea to keep it visually consistent. But the biggest complaint I got from many users was that the available space was not used efficiently. Some content could be visible but wasn't. We have tables that are full of information and the page refreshes when paginating. Our users are well known with the software and know what they want and need. It all depends on the content itself and the users. – jazZRo Oct 3 '17 at 12:35

Try not to make the user recalibrate their eye position on each pagination action, especially if just the table is refreshing while other page elements remain static.

If a table either:

  • loads more on scroll

  • paginates, but refreshes quickly (independent of the other page elements)

The user is going to be thrown off when scanning the columns. Because they scan a table oftentimes like a list, changing the positioning of the columns will force their eye to recalibrate. This is especially true if the table is paginating, but the whole page does not have to refresh.

You could allow manipulation of the column width manually, and talk to your devs if that state can hold across pagination actions on the table.

  • What about @jazZRo answer? – Joanvo Oct 3 '17 at 12:10

I would strongly prefer that the columns remain fixed in width. Column dividers moving as a direct result of user action lends to the idea that the type of data has changed instead of just the content, which will take away your user's time and mental focus for the unnecessary task of reorienting themselves.

The point of displaying data in a tabular format is to make it easier to parse and compare quickly, if you resize your columns then you also damage the user's ability to parse and compare data across different pages.

If you find fixed width columns too restricting for your users' needs and have the resources to dedicate, you might consider allowing users to resize or show/hide columns to give the larger data columns more room to breathe when needed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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