You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2018/09/12 18:50:22 UTC

[GitHub] graceguo-supercat edited a comment on issue #5269: Filters as a native dashboard (v2) construct

graceguo-supercat edited a comment on issue #5269: Filters as a native dashboard (v2) construct
URL: https://github.com/apache/incubator-superset/issues/5269#issuecomment-420741116
 
 
   I collected following feature requests from open source community, and from Airbnb usage:
   
   - Filter component or filter_box from explore view? Given @mistercrunch comments above, I assume existed filter_box viz type will keep working as it, and will introduce new filter component lived inside dashboard. So there will be two types of filters working together.
   
   - Scoped filter
      - Filter should be visible (scroll up/down is ok, but not extra tab switch) when it is applicable to any charts.  
      - Top level filters: 
   Filter is placed in dashboard without tab, or at top section of dashboard with row-level tabs. So that filters are always visible in the dashboard. 
   Top level filters will apply to all charts in the dashboard.
     - Tab level filters:
   Tab level filters are placed inside a Tab component. As long as the tab component is visible, filters will apply to all charts in the same tab.
   
   - Easy UI for user to see which charts are affected by which filter, and easy add immune from the filter.
   - Easy UI to group multiple filters, and allow user define cascade filters.
   Current filters are filter_box that generated from explore view, so each of filter_box (can have multiple dropdowns) contains one slice of constraint, whereas dashboard may have multiple filter_boxes to add many constrains. If this is the case, i see our users always update one filter_box in dashboard, apply it, wait all charts in dashboard finished loading, then update another filter_box, wait another round of loading...It is very frustrating in daily use. 
   <br/>So I am thinking dashboard should allow user group a few filter_boxes(and native filter components) together, in which user can update each filter but don't trigger dashboard level loading events. In the group user can also make cascade filters (where one filter react on other filters's selected values). And in the end user can apply all selected values altogether in 1 dashboard level load. This will greatly improve the dashboard filters usability.
   
   - After user update filter and trigger the dashboard level load, can we have UI indicator showing filter is applying or done? Some of our dashboard is crazy big so it's hard to scroll back and forward to check if every chart is ready  😓
   
   - Keep filter state in URL parameter [#5374]
   If user applied filter in dashboard, can we update dashboard's url parameter (or anywhere as a state of history), like url for explore view? So that when user refresh dashboard, the previously applied filters are still be memorized. 
   Dashboard should not automatically save filter parameter unless user saved them as default_filter metadata.
   
   - Coordinate `Visual Correlation` feature. Discussed in another thread, @JamshedRahman want to introduce a new feature that allow one chart to publish events to dashboard level, and charts listening to the events can change/react accordingly. These 2 features will implemented independently, but i just feel there might be some common logic to share. 
   
   These are all proposals. I would like to leave @xtinec who implements this feature to decide final list. Thank you!!
   
    
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org