Totals in table charts #29297
Replies: 6 comments 1 reply
-
I vote for #1 - it seems like the simpler approach (#2 adds complexity with effectively the same result, if I understand corerctly). I believe that the totals should not reflect the dataset, but rather the table as it's displayed (with filters, limits, grouping, etc. applied). |
Beta Was this translation helpful? Give feedback.
-
@michael-s-molina per your comment,
which is what one would expect for said metric. Maybe the term |
Beta Was this translation helpful? Give feedback.
-
There's two challenges here:
In both cases, computation should be done database-side as either cases could blow up the backend/frontend. Also in both cases, totals of this kind forces 2-phases or subquery. The existing feature "series limit" where one can say "I want to see the full time series for the top N {countries}" does it with a subquery to first identify the top N countries and then fetch their respective time series. I remember building the feature and though I could add a checkbox to "Also lump/aggregate others members" where it would show the top N times series + another time series for "all other countries" Similarly, our LIMIT feature could offer something similar where it could lump the rest of the rows without its dimensionality, making computing a total possible. But this doesn't help with non-additive metrics. For non-additive metrics, you probably want to |
Beta Was this translation helpful? Give feedback.
-
@mistercrunch This is the current behavior but the problem is that only the |
Beta Was this translation helpful? Give feedback.
-
Looking at the comments, we can see that we don't have a clear alignment. Let's go back a little bit and talk about our expectations (requirements): 1 - Take the screenshot 1 as an example where the 2- Take the screenshot 3 as an example where there's a |
Beta Was this translation helpful? Give feedback.
-
We agreed in a meeting to replace the Total nomenclature with Summary and add a tooltip in the table with more details. Thanks for the great discussion @villebro @john-bodley @mistercrunch @rusackas. I'll open a PR with the results of our discussion. |
Beta Was this translation helpful? Give feedback.
-
Our users observed some problems with Table chart totals and I would like to get input on how to resolve them.
Consider this chart where we have a dimension and one metric that uses
DISTINCT
:We can see that the
COUNT_DISTINCT(state)
total does not match the sum of the rows.This happens because the total is currently being calculated independently of the results of the first query:
The second query refers to the total and completely ignores the group by on the first query which is problematic when the metrics use some SQL constructs such as
DISTINCT
,MAX
,AVG
, etc.Another problematic example is when Row Limit is applied:
In this example, I applied a row limit of 2 and neither total represents the sum of the column values. Although the
Show totals
control has the following tooltip, it still provides a poor UX for users:Another example is when we have a paginated table, where the totals are also not matching the sum of the column values:
Some possible solutions:
1 - Calculate the totals with only what's displayed. This means that the total would vary depending on the row limit, dimensions, SQL constructs and selected page. The downside is that we wouldn't have the total of all data but that could be easily achieved with another chart.
2 - Calculate the totals on top of the results of the first query instead of an independent query. We would still need to decide what to do with the row limit. Should the totals be calculated considering the row limit?
3 - Make all this configurable. This would increase code complexity and may also decrease UX because the total calculation will differ between charts. We would need a way to inform users of the configuration when displaying data.
Thoughts @rusackas @yousoph @kgabryje @eschutho @mistercrunch?
Beta Was this translation helpful? Give feedback.
All reactions