Hi,
It’s good to see the active work in improving query parameters, and their connection to visualizations. One thing I haven’t seen mentioned, nor been able to implement, is specifying that (all or some) dashboard visualizations (components) be bound to a common set of axes (dynamically), and this is important. Interestingly, I don’t see this in Superset or Metabase either.
For example, I recently set up a dashboard comparing sales forecasts and (simplistic) weighted sales forecasts (salesperson’s estimated probably of closing * estimated sales amount). Redash automatically scales the (weighted or unweighted) forecast amount (Y-axis) nicely. But this is undesirable. The Y-axis needs to be the same between both visualizations for the comparison to be meaningful.
To achieve this, of course, I set the maximum Y-axis value manual for both visualizations on the dashboard, and the results were appropriate and good. But that was for a set date range (2019.01.01 to 2019.12.31). Given that I defined date range parameters for both visualizations, and that I bound both to the dashboard-level data range parameters, both updated appropriately when I changed the date range to be for 2018 (we have a long lead-to-close cycle). Of course, however, the fixed, common maximum Y-axis value I set for the 2019 data was inappropriate for the 2018 data, any other date-range selection (monthly, quarterly, etc.).
Thus,I think it’s going to be important to able to bind the axes of visualizations together, with some intelligent options. (I haven’t thought through that much yet, but certainly allowing Redash users to define a function to determine the appropriate min-max scale values across two or more visualizations for the relevant axes is the most general approach.) At minimum, just being able to specify the following would be quite helpful and solve my immediate use case: An option to request, across these bound visualizations, make the maximum axis value be the maximum across allow of them (plus an adjustment factor, i.e., + / - some fixed value or percentage of the maximum maximum observed (double maximum intentional). Such an adjustment is easy but will also be important, as, in my experience (e.g., ggplot2 in R), automated scale unfication like this works well, but rather often needs tweaking because visually the results have problems (e.g., too close to the upper edge of the visualization, crowding, etc.).
Finally, where one defines such axis unifcation is probably often apprioprate at the dashboard level. In addition, definining there keeps loose couping between visualizations. Longer-term, however, it might be desirable to tightly visualizations directly in this way. This will be especially true if things head in the direction of nested visualizations and nested dashboards. In those cases, tightly coupling visualizations makes sense, as then they become the lower-level unit of work. Indeed, in that case, I would be inclined to introduce some sort of (likely rather simple) Visualization Container between the visualization and dashboard level[1]. That way, the visualizations are never directly bound to each other, and then as such can operate in either a bound mode with other visualizations or independently, nor is how they are bound together tightly coupled to a specific dashboard but can be used in multiple dashboards (i.e., one could reuse visualization containers in multiple contexts).
Thanks!
Doug
[1]: As far as the Dashboard goes, I suspect its interface to a visualization container could be, and likely should be, the same as its interface for the individual visualization (i.e., a standard interface, with polymorphism).
