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
In the current implementation, when dealing with visualizations that incorporate multiple subplots (e.g., for simultaneously recorded timeseries data such as EEG, MEG, ECG in neuroscience), there's a need to zoom into specific groups of timeseries without affecting others. However, the current toolset necessitates creating multiple zoom tools for each group, leading to a cluttered interface. With the number of zoom tools scaling with the number of source groups, this becomes impractical beyond a couple of groups, compromising usability.
Feature description
I propose an enhancement to the wheel zoom tool that allows it to dynamically target the subplot (or group of subplots) under the cursor for zooming actions. This feature would enable a single wheel zoom tool to apply selectively based on the cursor's position over the plot, streamlining user interactions by keeping attention in the viewport rather than on an array of similar looking tools in the toolbar.
One potential implementation would be to expand the options for the 'level' arg (which normally specifies whether a tool applies to a base plot (level = 0) or a subplot (level = 1), see Bokeh's example) to allow for something like level='cursor'. I don't think is the solution since there may be elements on the base/parent level. Probably a better solution would be to utilize a new arg, something like follow_cursor=True, which, when combined with level=1, would allow for the behavior being described - only the subplot closest to the cursor is impacted. Yet another solution would be to create a distinct zoom tool specifically for this behavior.
This approach would simplify the UI and make it more intuitive for users to zoom into specific parts of the visualization relevant to their point of interest.
Potential alternatives
One alternative considered is maintaining the status quo with multiple zoom tools for each group, which is not scalable. A complex solution could involve custom scripting to manage zoom levels and targets dynamically, but this would significantly increase the burden on the user.
One less good but possible alternative is to utilize a dropdown menu in the toolbar to select a particular subplot group and then have a zoom tool apply to the selected group. While this mitigates the scalability issue, it adds complexity to specifying this custom dropdown tool for an action that should be easier to express and apply.
Additional information
Anticipated challenges:
Handling scenarios where subplots overlap, which might necessitate a decision on which subplot(s) the zoom applies to when the cursor is above multiple groups. An initial approach could be to apply the zoom action to all underlying subplots, with further refinements as needed.
When zooming out, at some point the subplot under the cursor may not be under the cursor any more, so 'applying to nearest subplot' is probably needed to maintain consistency.
Integrating this dynamic zoom functionality with tap zoom tools presents a challenge, as tap zoom requires toolbar interaction. I suggest focusing on wheel zoom. Tap zoom might require a separate mechanism, such as an 'active group' selection through a dropdown in the toolbar... so separate issue.
tagging @jbednar, from whom this request most recently came.
The text was updated successfully, but these errors were encountered:
That captures it all well, thanks! My concern is that the current status quo is not intuitive or discoverable or easy to use; if we have multiple zoom tools in the toolbar, which group they apply to is obscure, the fact that you have to pick one or the other is something the user has to figure out fairly painfully, and switching between groups is awkward. Whereas pointing to a group and using the scroll wheel is intuitive and obvious and doesn't require explanation; people will discover it immediately ("Oh! It only zooms this group! What if I move to the other group; does it now zoom that? Yes! Perfect!"). I strongly prefer UIs that don't require explanation. :-)
To expand on this, the implementation in #13826 currently implements the ability to enable the contextual hit-testing behavior. However I don't think it quite matches the behavior defined here, specifically the behavior requested here involves a situation where:
You have multiple zoom tools, each associated with a subset of renderers (and their associated subcoordinate systems)
When you zoom, each zoom tools performs hit testing to see if any of its specified renderers intersect and then zoom on all of the renderers associated with that zoom tool.
As far as I can tell #13826 implements slightly different behavior:
When you zoom on a plot the zoom tool performs hit testing and only zooms on the subset of renderers that are found to intersect.
Both are useful behaviors but they are quite different and currently #13826 does not cover the use case we were imagining. We would need a separate per_renderer option (name needs work) that effectively toggles between zooming only on the renderer(s) that intersected and zooming only if ANY of the renderers intersected.
Problem description
In the current implementation, when dealing with visualizations that incorporate multiple subplots (e.g., for simultaneously recorded timeseries data such as EEG, MEG, ECG in neuroscience), there's a need to zoom into specific groups of timeseries without affecting others. However, the current toolset necessitates creating multiple zoom tools for each group, leading to a cluttered interface. With the number of zoom tools scaling with the number of source groups, this becomes impractical beyond a couple of groups, compromising usability.
Feature description
I propose an enhancement to the wheel zoom tool that allows it to dynamically target the subplot (or group of subplots) under the cursor for zooming actions. This feature would enable a single wheel zoom tool to apply selectively based on the cursor's position over the plot, streamlining user interactions by keeping attention in the viewport rather than on an array of similar looking tools in the toolbar.
One potential implementation would be to expand the options for the 'level' arg (which normally specifies whether a tool applies to a base plot (
level = 0
) or a subplot (level = 1
), see Bokeh's example) to allow for something likelevel='cursor'
. I don't think is the solution since there may be elements on the base/parent level. Probably a better solution would be to utilize a new arg, something likefollow_cursor=True
, which, when combined withlevel=1
, would allow for the behavior being described - only the subplot closest to the cursor is impacted. Yet another solution would be to create a distinct zoom tool specifically for this behavior.This approach would simplify the UI and make it more intuitive for users to zoom into specific parts of the visualization relevant to their point of interest.
Potential alternatives
One alternative considered is maintaining the status quo with multiple zoom tools for each group, which is not scalable. A complex solution could involve custom scripting to manage zoom levels and targets dynamically, but this would significantly increase the burden on the user.
One less good but possible alternative is to utilize a dropdown menu in the toolbar to select a particular subplot group and then have a zoom tool apply to the selected group. While this mitigates the scalability issue, it adds complexity to specifying this custom dropdown tool for an action that should be easier to express and apply.
Additional information
Anticipated challenges:
Handling scenarios where subplots overlap, which might necessitate a decision on which subplot(s) the zoom applies to when the cursor is above multiple groups. An initial approach could be to apply the zoom action to all underlying subplots, with further refinements as needed.
When zooming out, at some point the subplot under the cursor may not be under the cursor any more, so 'applying to nearest subplot' is probably needed to maintain consistency.
Integrating this dynamic zoom functionality with tap zoom tools presents a challenge, as tap zoom requires toolbar interaction. I suggest focusing on wheel zoom. Tap zoom might require a separate mechanism, such as an 'active group' selection through a dropdown in the toolbar... so separate issue.
tagging @jbednar, from whom this request most recently came.
The text was updated successfully, but these errors were encountered: