You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To enable a consistent experience across all visualizations, we first need to catalog and document the "standard" behaviors and interactions that we expect all visualizations to provide, regardless of how they're implemented. A contract-based approach would provide several benefits:
Apps which embed visualizations (e.g. dashboards) will be able to know which visualizations support global operations (e.g. filter updates), and which don't. This means that we can also provide standard user feedback and messaging for when they try an action on a visualization that doesn't support that capability (e.g. clicking on a chart that doesn't support data-based value filtering).
Plugins which need to implement their own visualizations "from scratch" (e.g. large scale network diagrams, 3-D models), they will have a menu of standard interactions to target as best as possible, and a way of opting out of interactions they can't support.
As another example, we want visualizations to be responsive by default, and usable useful at a variety of sizes. But some visualizations may very well have a minimum embeddable size, below which they just don't make sense. By capturing the visualization size ranges as a capability, dashboards would be able to optimally size the embedded panel for visualizations.
The text was updated successfully, but these errors were encountered:
To enable a consistent experience across all visualizations, we first need to catalog and document the "standard" behaviors and interactions that we expect all visualizations to provide, regardless of how they're implemented. A contract-based approach would provide several benefits:
dashboards
) will be able to know which visualizations support global operations (e.g. filter updates), and which don't. This means that we can also provide standard user feedback and messaging for when they try an action on a visualization that doesn't support that capability (e.g. clicking on a chart that doesn't support data-based value filtering).As another example, we want visualizations to be responsive by default, and usable useful at a variety of sizes. But some visualizations may very well have a minimum embeddable size, below which they just don't make sense. By capturing the visualization size ranges as a capability,
dashboards
would be able to optimally size the embedded panel for visualizations.The text was updated successfully, but these errors were encountered: