ktmud edited a comment on issue #9887: URL: https://github.com/apache/incubator-superset/issues/9887#issuecomment-634463503
Was [this](https://projects.invisionapp.com/share/V5VH03AHBER#/screens/399817645) the query panel design you were looking for? I like its simpleness and directness---the grouping of visualization types and unification of control UI are really slick. It does seem difficult to fit the query + transform + map model in this design, though. There is definitely a tradeoff between simplicity and flexibility. To better understand the problem, I looked at what other BI tools are doing in this regard: 1. [Redash](https://redash.io/help/user-guide/getting-started#2-Write-A-Query): - Users always write SQL queries before visualization. - No post-processing transformation possible. - Property mapping mostly manual. 2. [Metabase](https://www.metabase.com/docs/latest/getting-started.html): - Similar to Redash, separate steps for query building and visualization - No post-processing transformations, except simple cumulative sums (mixed with normal aggregation functions). - Property mapping is manual or based on metric/dimension definitions at the query stage. 3. [Looker](https://docs.looker.com/exploring-data/retrieve-chart-intro): - A combined Explore view for query + visualization - Support "Table Calculation" (post-processing on query results) and "Custom Fields" (query level calculated columns), both have similar interactions - Data retrieval not tied to visualization - Post-processing and ad-hoc columns achieved via DLS 4. [Mode](https://mode.com/help/articles/getting-started-with-mode/#create-analysis) - Query with SQL - Apply advanced data transformations with R or Python notebook - Charting controls only operate on query results - Property mapping is totally manual 5. [Tableau](https://help.tableau.com/current/guides/get-started-tutorial/en-us/get-started-tutorial-drag.htm): - Visualization centric, no separate querying step for most cases - Powerful custom functions and on-chart controls to apply transformations - Custom function could trigger both optimized queries or post-processing, but the whole process is fully opaque to users. 6. [Domo](https://knowledge.domo.com/Visualize/Adding_Cards_to_Domo/KPI_Cards/KPI_Card_Building_Part_2%3A_The_Analyzer/011Analyzer_Overview) - Visualization centric, all charting/querying options in one page called Analyzer - Transformations like rolling average [must be applied at the data source level](https://knowledge.domo.com/Prepare/DataFlow_Tips_and_Tricks/Creating_a_Rolling_Average_Using_DataFlows) via SQL queries 7. [Power BI](https://docs.microsoft.com/en-us/power-bi/fundamentals/desktop-getting-started) - Very similar to Tableau - Most transformations (including data source joins) probably happen locally (in desktop app or on Power BI server, as oppose to the datasource) TL;DR: Tableau, Domo, Power BI use the visualization-centric approach; others data-centric. In terms of functionality and philosophy, _Looker_ is the closest to what's been proposed in this SIP; _Domo_ is the closest to SIP-34. Either way seems to work from an end-user's point of view. For Superset, it's a matter of which mode is the best for our users and whether we can smoothly get there. To answer some of your concerns: - **data <-> viz property mapping**: it's possible to keep track of derived metrics and use the same property type for source and derived metrics. Pivot tables also know which output columns are dimensions which are metrics. - **granularity**: I'm not sure I understand this correctly. "Grain change" is the same as adding/removing a column in regular controls, isn't it? I don't think we have to have restrictions on query output. Like Redash/Mode and others, excessive columns can simply be ignored---during chart configuration, you select only the columns you need for visualization. Visualizations should not run any implicit aggregations on the client side, and should throw errors if the final output has excessive/missing dimensions or is not in desired shape. - **complexity**: simple bar chart will not need transform. The transform controls could be part of an "Advanced" section hidden (but discoverable) from regular users. There are ways to make the UI intuitive and non-intrusive. Both Looker and Tableau, the most powerful of above all, use DSL to hide the complexity of the transformation layer. We don't have to go there yet, but it could eventually be a choice. In summary, the addition of a transform layer does involve a lot of work, but I'd argue it adds valuable flexibility for the users which would really differentiate Superset from its competitors. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
