Client-side aggregations from cell selection

[seancolsen]

Problem

• Spreadsheets have functionality to display aggregate info based on the selection of cells

  

• Mathesar lacks any such functionality

UX Design goals

• We should figure out how to give the user similar functionality to shown above.

Possible solutions

• In #2342 we would like to add a "Cell" tab to the table inspector. The Data Explorer already has such a tab. The Cell tab within the inspector (in the Table Page, Exploration Page, and Exploration Editor) could display aggregate info.

Considerations

• The Record Page has table widgets which don't allow the table inspector. If the user wants to display selection-based aggregate info, is that possible from within a table widget?
• When we display aggregate info, how do we decide which types of aggregations to show?
• It seems that types which we could conceivably aggregate (e.g. Number, Date, etc) are transmitted via the API as strings. In most cases the front end will be able to parse those strings, but in some cases the front end parsing will fail. For example, Postgres can handle numbers with much higher precision than JS. What is our expected behavior in this case?
• Are there performance concerns with this feature? Does the front end to parse the cell values as the user forms their selection? This seems fine for small selections, but it's common for the user to select all the cells in a column. Do we need to parse the values when fetching and cache them? Would this present performance concerns during load time? Could we offload that parsing/caching work to a web worker to be done asynchronously on load?

Next steps

• If we decide to move forward with this feature we will need UX design specs and an implementation RFC

[seancolsen]

The maintainers team met today to discuss this issue. We decided to approve the feature at the product level, with the recognition that it still requires UX design before implementation.

@mathemancer expressed some concern that this feature would not be useful enough to justify its inclusion in Mathesar. He worries that giving user too many ways to compute aggregates will become confusing.

I and @ghislaineguerin both made a case for this because we rely on this feature regularly when using spreadsheets.

To help address @mathemancer's concern, we'd like to note that the UX design should take care to contain this feature to a small part of the app where users are unlikely to confuse its purpose with our other grouping and summarizing features.

[seancolsen]

Towards the UX design process, here's a quick mockup of what I have in mind:

I'd want to improve aesthetics, but I think the "Cell" tab of the table inspector would be a logical place to put this UI.