The prototype described above had one big usability flaw: you had to manually trigger a refresh of the grid (for instance by changing the number of rows shown) for it to update. There was also no indication in the grid that the view shown was only an intermediate state of computation and that more data was coming.
As I wrote earlier there are many ways we could change that. I have been exploring one, which consists in showing which cells are still being computed. You can try it out on the 4.0 branch and it looks like this:
The basic principle is simple: when joining a change data object with the grid to obtain the state of the grid after a long-running operation, cells which depend on missing parts of the change data (i.e. rows where the operation has not been computed yet) are marked as “pending” and serialized as such.
As long as there are pending cells in the current view, the frontend periodically refreshes the grid.
This solves the basic problem of knowing when to refresh the grid, but the refreshing itself could still be improved:
- Potentially, we could only refresh the cells that were pending, not the entire grid. This would give a better user experience by being more efficient and giving a more fluid experience of (for instance) editing a cell in a column that is not being computed. The fact that we do not use a reactive frontend makes this a bit cumbersome, but it is still doable.
- Refreshing the grid can change the width of columns, which can also be disruptive if the user is interacting with other cells while the grid is refreshed. This is why I started looking into making the grid layout more predictable.
Many UX options are still on the table:
- Do not add a spinner to pending cells (like in the previous prototype) but just use this information internally to determine if the grid should be refreshed;
- Make the spinner not fully opaque to show the previous value of the cell before the operation:
Or more generally any other ways to render those pending cells. - Do not refresh automatically, but instead create a notification at the top of the screen (for instance using our yellow bubbles) signifying that the operation has progressed and the grid can be refreshed. The user would then click on “Refresh” in the notification to trigger the refresh when it fits them. Or give the user the option to switch between this manual refreshing and auto-refresh.
- Mark entire rows/records as being pending if any cell in them is. Or hide them entirely: only show rows/records that are complete. This would mean that the grid would initially look empty after starting a long-running operation, and it would fill itself up gradually.
- Other approaches? What would be your preferred one?
Although the current prototype works okay from what I can tell with interactive testing, I am still struggling to get the corresponding Cypress tests to pass reliably. In my experience that’s a sign that the strategy used is not fully bullet-proof and there can be some races between various processes, so I am investigating that.
But that should not prevent you from taking it for a spin already! 