Here is a post to gather problems with the way we currently display the project table. I have been thinking about them lately and I think those problems are closely related and should be tackled together.
I don’t claim this is an exhaustive list of all issues with our grid, but I am interested in thinking about a holistic solution for those three:
- Columns cannot be resized (#4806) and are sized by the browser, often giving poor layouts. For instance, if a column name is long but all the cells in that column only contain a few characters each, the column will expand to take a lot of width to display the entire column name, taking up a lot of space in the grid. This feels pretty unacceptable when I actually think about it. I think this is one of those issues that I must have been confronted with early on as I discovered the tool, and then just got used to and do not question anymore.
- Cells with large content are always displayed in full (#1440). This is also pretty revolting honestly. A big cell will blow up the height of the row it contains, meaning that all other cells in that row will expand to fill up a lot of unnecessary space.
- Navigation in the project is done by manual pagination, whereas users generally expect seamless scrolling (#1027) from most other tools (Excel, Google Sheets, many tabular ETL tools…). We tried implementing this, but given that the height and width of cells is completely unpredictable because of the two issues above, it is really hard to implement in a satisfactory way as things stand.
A proposed joint solution to those problems
I would aim to:
- put a set width on each column (meaning that the column header has a
- have a set maximum height for each cell (and therefore row). Overflowing content would be displayed using an ellipsis (for textual content) or an interactive expansion for reconciled cells with many candidates (to be made precise)
- implement infinite scrolling, which should be easier to get right with fixed column widths (because dynamically adding / removing rows will not change the height of other rows because the column widths change). I would do it based on the GSoC project of Lisa Chandra (#2746) which was really high quality. Other changes in pagination implemented since (#33, #572) should also help get this to work sufficiently smoothly.
Although I see it as a joint solution the changes make sense in isolation too, so they can be implemented step by step.
Poor automated column sizing:
Lack of ellipsis on large cells: