Regarding Simultaneous Scrolling

I can understand this feature request in principle, but how precisely is this supposed to work?
The sizes of the columns in the two tables can be completely different, even when looking at sizes relative to the table width. For example, the first 20% of the first table can correspond to the first 80% of the second table.
So even if we find a way how to compute how far the other table should scroll, this would mean that the two tables would need to scroll at different speeds and one table (the one that the user is currently not scrolling themselves) would even jump around. Furthermore, this would mean that if a user scrolls the first table to the point where they want to have it, and then adjusts the second table, the interesting part of the first table could scroll out of view, with no chance of getting it back without the second table starting to move again. So I suspect the behavior would often be quite frustrating in a way that is worse than the current behavior, where one has to do a little bit more scrolling in some cases, but at least the automatic table scrolling does not work against the user.

If you have a concrete proposal how the UI should interact with the user and how the scrolling behavior should work, we can reconsider this.

Regarding Same Columns

What do you mean here? Columns of setup and statistics table are currently never the same. For each column of the setup table there are several columns in the statistics table.

Let's have just one table?
That is, like the old-style tables, just that the middle part (data rows) are missing.

As discussed in #491 (comment), this is not a good option.

... or the design choice described in #491 (comment) is not a good option.

Why should we derive the page design from technical restrictions?

I think we need to prioritize use cases:

• Is it important to find the configuration and setup info for a given result that I see in the lower part? (Would favor one table.)
• Is it important to find out which run sets used the same technical configurations?
  (Favors merged table cells. Does not always work anyway, because it depends on the order of columns.)
• How important is it to use that particular way of calculating the sum of rows?
  (Simple implementation is important, definitely.)

This might be possible after #569 / #719 because now we handle more of the table rendering ourself.

@lachnerm The goal here is to merge the upper table on the summary tab into the header of the lower table, such that we have a multi-line header in which many cells span across different columns. With react-table v6, this was not possible, do you think this is possible with our own rendering on top of react-table v7?

So if I understand everything correctly, we would basically merge both tables such that the upper table's entries move into the header of the corresponding runset in the lower table, right? I've looked it up and it I think this should be possible. I will take a closer look when the update of the table framework from #719 is merged.

@PhilippWendler I would like to renew this request.

There must be only one table on the summary page, and the scrolling must be done via the page by the browser, not via an extra element inside the page.

If you have a small screen (laptop) and a large table then you cannot watch the first row and scroll to the left, because you cannot even not see the first row and the horizontal scroll bar at the same time on screen!

This is still planned but currently we have nobody who could work on this.

To whoever is following this: the implementation of this in #1065 is close to being finished and we are looking for feedback on the design.