Improving the project grid's layout

Development & Design Design proposals
1

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.

The problems

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 width CSS property set in Javascript). This set width can be adjusted by the user with the expected UX (just drag the column boundary between header cells), as described in #4806. The initial set width can be computed in Javascript based on the values initially present in the table. That heuristic does not need to be perfect since the user is able to adjust the widths themselves.
  • 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.

Screenshots

Poor automated column sizing:
image

Lack of ellipsis on large cells:

image
image718×465 73.5 KB

5 Likes
2

Awesome! This is a much-needed improvement. But I am curious to know how this also impacts the “Create Project” (configure parsing option) page as the import file has a preview viewport. Will the cells be adjustable or fixed?

3

Good question! I think it could be nice to have a similar rendering there too. Actually, I am not really sure why the preview and the project should look any different, we could probably use the same grid in both places (aside from the fact that the preview cannot be edited). @thadguidry have you got any historic insights about that?

4

The preview has a different look depending on importer, and the thought was that it could be extended upon by importers based on their needs. David actually did 2 kinds of views for the Json importer initially…and we settled for the 2nd view which is what we have now. For records, the XML/JSON has a different view (non-tabular) initially once the user selects the element/object hierarchy they want. But for strict tabular data (non-records), then it could look the same as our data grid. However, it will be interesting to see how we can shape and improve the previews for the various importers that handle non-tabular data.

5

and the short answer is: David didn’t want there to be too much interactivity in the preview which might confuse folks thinking they are already in the data grid and able to edit. Which I kinda agreed with at the time. “It’s to really help see the structure of data… then they can play with the data representation and modify it later.”

6

Although I see it as a joint solution the changes make sense in isolation too, so they can be implemented step by step.

Absolutely. I see no reason to couple these changes. Both resizable columns and clipping content of cells to some maximum size seem like good ideas which can be implemented independently of anything else (or each other).

As for the continuous scrolling prototype, I don't remember the problems being caused by variable size cells. Also the state of the art for components to build with may have moved on in the last few years, so I think it's worth carefully vetting whether the abandoned implementation is the correct base to build on.

Tom