Dashboard column sizing is sub-optimal
Project Member Reported by jwer...@chromium.org, Sep 13 2016
On my dashboard I have a list of CLs, one per row. Every row has different columns for Project, Branch, etc. The Chromium OS project likes to use pretty big names for projects and branches, such as chromiumos/third_party/coreboot and firmware-gru-8785.B. Unfortunately, with the available column size on my 1280x800 laptop, all I'm seeing in every column is stuff like chromiumos/third... and firmware-gr... Of course there's no perfect solution here and some stuff will have to be truncated no matter how you design it. However, for the Chromium OS use case (and I'd bet for most others), truncating the front of the field is much more likely to preserve the most useful/distinct part than truncating the tail. I'd much rather see columns with ...arty/coreboot and ...gru-8785.B than the other way around, because I probably know the prefix from context anyway.
Sep 13 2016,
Oct 5 2016,
Feb 28 2017,
I'm not sure if this was intentional or accidental, but behavior seems to have changed quite a bit here... see attached screenshot for the current situation. Now the Project and Branch row seem to always expand to allow the longest value in the displayed table to be printed in full, which is even more undesirable because some project and branch names are really long. This can have some pretty ridiculous effects like cutting the subject line down to less than 25 chars and still making the whole table to wide to fit (notice the horizontal scrollbar). I think the column sizing really needs to be overhauled completely with some more focus on what the user likely wants to see. Columns should only expand to the maximum size when they have some very well-known to be limited values (e.g. dates, diff sizes, checkmarks). After those the remaining space should be divided into ratios depending on how important each column is... e.g. Subject should likely get the most real estate (at least 30% screen width?) and the others should get lower allotments accordingly. Every column should get the right default as to which part is truncated if the width is insufficient (as I argued above I think Project and Branch ought to truncate the front, whereas Subject should probably continue to truncate the end). For some columns like Status it might also help to introduce abbreviations to save space (e.g. "Merge Conflict" = "MC").
Jul 31 2017,
I was about to file the same issue. Also note that author fields aren't truncated, which can result in a huge amount of space being devoted to out-of-office messages.
Aug 14 2017,
smoreland@ has also proposed the idea of having the columns be reorderable, which would allow users to prioritize certain information.
Jan 20 2018,
Moving this to the triage queue.
Jan 22 2018,
See also internal issue b/64145900
Jan 22 2018,
Jan 22 2018,
Issue 8198 has been merged into this issue.
Issue 8165 has been merged into this issue.
Issue 8313 has been merged into this issue.
Author and branch columns should be truncated at a reasonable max-width.
Sign in to add a comment