Width of table on Goals Overview page is not correct

[Stan-vw]

Context

Table on goals page isn't using the entire available width, even though not all columns are visible.

Expected Behavior

The table to use either:

1. the entire available width of the screen (with scrollbar to see columns that don't fit), or
2. use the width needed to show all columns (if less than the entire screen)

Current Behavior

Table is unnecessarily narrow.

[bx80]

Thanks for highlighting this @Stan-vw, clearly the table should expand to show all the columns if there is available width or at least use all available width if not 👍

[Stan-vw]

I understand the current max width of the global datatable element is set at 1200px. Keen to get some thoughts on what we should do here: a new max width, or should it be unlimited?

First thought that comes to my mind (not hung up on this), we can take the width of the most popular 80% of screens (which nowadays probably includes 4k screens but not ultra-wide screens). A very quick google search tells me that would mean a new max width of 3840px.

[michalkleiner]

Based on the stats of screen resolutions we get from our users I'd cautiously say to increase the max width to 1600px for now, and look at the whole widgets sizes, table sizes and resizing and grid positioning in a separate ticket.

It is true that wider tables are harder to read and stay on the row when scanning it etc, so there might be other enhancements to add to the list for consideration like striped rows, option for pivoting the table around its top-left corner where rows become columns and vice versa.

In general, getting tables presenting the data in a nice and attractive way while being usable at the same time is a complex thing to accomplish.

In this particular example the problem is also not the tabular data itself, but the column headings that are extremely long compared to the data points. Using a shorter text or rotating the heading by 90 degrees or using a shortcut with a on-hover tooltip etc. all could help here. I get these might be user configured, so we'd need a solution that e.g. adds another field for a short-text version of a goal title etc.

Those ideas are clearly out of scope here for now, but good to keep them on the radar.

[Stan-vw]

Perhaps to add to my previous comment: I'm not advocating that we make tables 3840px wide. My perspective is that we shouldn't somewhat arbitrarily limit the width of a table when the table still has columns/entries that can't be shown even though there's screen real estate.

I think the default position should be that a table fits neatly in the widget/element/section it is part of. And if that widget/element/section is 1600, 2560, or 3840px wide, it sounds like the table should be able to scale up to that width as long as it keeps adding value.

I.e. pretty much what @bx80 said, but expanded upon since I learned we have a max width parameter in there.

If the max width value is also the fixed width value, then I am definitely NOT in favour of 3840px 😅

[michalkleiner]

My perspective is that we shouldn't somewhat arbitrarily limit the width of a table when the table still has columns/entries that can't be shown even though there's screen real estate.

The counter point to that is that super wide tables that span the available real estate might be hard to read/keep focus on, so there is benefit to a limited width in that it allows for better consumption of the data, with the support of the sticky first column or repeated first column every 10th column etc. Letting the table just run as wide as it can may make it worse than having it narrower and having to scroll within it.

[Stan-vw]

The counter point to that is that super wide tables that span the available real estate might be hard to read/keep focus on, so there is benefit to a limited width in that it allows for better consumption of the data, with the support of the sticky first column or repeated first column every 10th column etc. Letting the table just run as wide as it can may make it worse than having it narrower and having to scroll within it.

I hear what you're saying, but I have to disagree here. There's a reason Excel, Google Sheets etc don't show only half a screen of columns. If you have horizontal screen real estate available AND not all columns are shown, I've yet to see an example where it makes sense to me that we should cut it off (as mentioned: excluding ultra-wide screens).

Feel free to provide an example where you think we should cut off the table without showing all columns while there is empty screen space on the right, I'm open to be convinced otherwise.

[michalkleiner]

Fair enough, it's a discussion with suggestions from both sides, not a "this approach is the only correct one" competition.

Well, Excel and GSheets are table processors/editors and you can do whatever you want there with your tables which is not the case when just viewing the table in a UI where you can't reorganise the columns to better fit your needs, group the data etc.

I don't have a specific example here where it would be better to use scrolling and not the available real estate to show more, but super wide tables can complicate scan-ability and correlating between columns that can be too far apart and or have the header too far etc.

I'll keep looking and if I find something, I'll add it here.

There's a somewhat related topic on line lengths in general and I think it's somewhat related, even though appreciating that text and tabular data are different but the goal is the same — help the reader to keep focus on the characters/line of text, not skip rows etc.
https://baymard.com/blog/line-length-readability

And an article about tables a11y just to add to the mix.
https://www.smashingmagazine.com/2022/12/accessible-front-end-patterns-responsive-tables-part1/

[bx80]

On an ultrawide screen changing the max-width from 1200px to 1600px increases the viewport from 23% to 31% of the screen width. I still have to scroll horizontally even with just four goals:

Here is how the same report would look with the max width limit removed, no horizontal scrolling necessary:

As an ultra wide screen user it's pretty obvious which is the better experience and a bit disappointing that the capability of a high end screen would be artificially cut down to size by the UI, especially as the other widgets above do use the full screen width which they clearly don't need. 🤷