mui-x
mui-x copied to clipboard
[charts] Allow to zoom on data
We can currently zoom with axis properties min
/max
. But this kind of feature still requires:
- Add a min/max behavior on 'band' scale such that bar charts could also get it
- Add event listener and visualization to select zoom area
- define a DX to enable/disable/customize the zooming and scrolling
DX
Zoom behavior
Allows to choos if the axis interact together (see #12083) this is well defined in the section "How dataZoom components operates axes and data" https://echarts.apache.org/en/option.html#dataZoom
Display
Inside zoom
Allow to modify the zoom state by mousse interaction inside the chart
- select x/y ranges
- drag chart zoom with mouse move
- define how to swich from select to drag
- zoom +/- with the mouse wheel
https://echarts.apache.org/en/option.html#dataZoom-inside https://api.highcharts.com/highcharts/chart.zooming.mouseWheel
Slider zoom
Allow to modify the zoom state with sliders
- select x/y ranges
- drag zoom range
https://echarts.apache.org/en/option.html#dataZoom-slider https://api.highcharts.com/highstock/navigator
Search keywords:
This would be a pretty sweet feature
Zoom Behaviour
Zoom & Pan Gestures
Allows users to zoom and pan using mouse/touch events. Seems to be the most straight forward for allowing users to interact with your data.
Will need customisation to allow which axis can be zoomed.
Examples: echarts, victory, visx, scichart
Takes:
- 🟢 More intuitive
- 🟡 Requires different handlers for touch & mouse
- 🟡 Harder to implement, zoom need to be on correct coordinates
Zoom with Click & Drag
It allows the user to "select" an area they want to zoom by "click & dragging" in the chart container. If the user wants to "zoom out" we need a different behaviour or button to handle that.
It doesn't feel as intuitive as Zoom & Pan Gestures
, but could be helpful if you don't want users zooming in while scrolling. scichart actually allows it together with Zoom & Pan Gestures
, by using different patterns for each behaviour.
Examples: highcharts, recharts, apexcharts
Takes:
- 🟢 Easier to implement
- 🟢 Mouse position can easily be extrapolated to new "axis min/max"
- 🟡 Not so intuitive to use
- 🟡 Requires a "reset zoom" button + translations?
Visualisation / Overview
Slider
Is a helper component that allows the visualisation of the current zoom state. Usually shown as a Slider
which is often called a Brush
as well. It works good for line charts and series data, is a bit odd for scatter data, but can work as well if the axis are properly formatted.
Examples: echarts, visx brush, victory, scichart
Takes:
- 🟢 Allows for easy visualisation of zoomed data
- 🟡 Not so great for scatter, but sufficient as a first effort
- 🟡 Will require "drag and drop" implementation, maybe use from other packages?
Area Overview
Works better on non linear data, like scatter charts, but would require a different implementation.
Examples: visx zoom
- 🟢 Specialised for scattered data
- 🔴 Specialised for scattered data 🙃
- We should probably skip it for now and implement if necessary only
Axis Binding
The scichart library allows zooming to be bound to two different axis. Same for Echart by providing the xAxisIndex
Takes:
- 🟢 We already allow for multiple axis, this could build on top of that.
:warning: This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue. Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
@joserodolfofreitas: How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.
The zoom feature is very cool. However, I'm confused about the UX in https://deploy-preview-13859--material-ui-x.netlify.app/x/react-charts/zoom-and-pan/. I was expecting it to behave close to Figma, FigJam, Miro, Excalidraw, tldraw, Gimp, Canva:
- a. Pan to move up, down, left, right
- b. Mouse down + mouse up to move up, down, left, right
- c. Ctrl + Pan up / down to zoom in and out
- d. Scrollwheel to zoom in and out
- e. Mouse down + mouse up to select a zoom area, like in https://observablehq.observablehq.cloud/framework-example-mortgage-rates/ or https://www.highcharts.com/demo/highcharts/line-time-series. Now, we can't do b) and e) simultaneously, it's fundamentally contradicting. I think it should be a prop to configure it. As an end-user, I would expect d) to be the default, it feels more intuitive (I don't know if it should be the default for the component though).
I'm confused about the UX
Thanks for the feedback 👍
There is already a user issue to improve the zoom behaviours and patterns https://github.com/mui/mui-x/issues/13798
The idea for this feature was to start with a very minimal set of behaviours and get feedback on improvements we should include.
For e)
it is a good idea, but I would leave it out until we implement the "slider"/"brush"
component and tackle the entire logic at once. https://airbnb.io/visx/brush
I'm a bit confused regarding b) & d)
. Since it is the same way it is currently implemented. And we would have to choose between c)
or d)
, or allow a way to configure it between those two, which I expected to implement when tackling the user issue I mentioned above.
Regarding a)
, if you mean pan
as space+click&drag
, that is not how charts libraries usually work, examples on my comments above. Though yes, it could be a customisation option we offer, since these small "trigger" modifications should be quite simple to setup.
Let me know if I missed anything or if there are any further feedback, these discussions are always welcome 💪
There is already a user issue to improve the zoom behaviours and patterns https://github.com/mui/mui-x/issues/13798
@JCQuintas It's great to see this.
The idea for this feature was to start with a very minimal set of behaviours and get feedback on improvements we should include.
👍 to be lazy, at this stage, we only need the rough right direction.
For e) it is a good idea, but I would leave it out until we implement the "slider"/"brush" component and tackle the entire logic at once. https://airbnb.io/visx/brush
It makes sense, similar to https://github.com/mui/material-ui/issues/17228.
I'm a bit confused regarding b) & d). Since it is the same way it is currently implemented.
Agree, this is how it behaves today, It matches for me with what I expect.
And we would have to choose between c) or d), or allow a way to configure it between those two, which I expected to implement when tackling the user issue I mentioned above.
I have fixed the description of c), it wasn't clear.
Regarding a), if you mean pan as space+click&drag, that is not how charts libraries usually work, https://github.com/mui/mui-x/issues/12503#issuecomment-2135262930 on my comments above.
It indeed seems to be close to how other libraries behave, https://charts.ag-grid.com/javascript/zoom/ is a bit closer to what I was expecting as a end-user.
Now, taking a step back, I think we benchmark to:
- Help us appreciate the version of the future that we are envisioning. Meaning, doing A sounds interesting, is there anyone who built A that I can review and appreciate if it is such a good idea after all?
- Help us idea generate more ideas. I have found of doing A and B, but they did C, I never thought about it. How great is C?
- Help us understand what are users already used to. How do make it easy for them to migrate over?
- Help us understand the gaps in the market, what are the things that nobody is doing but feels like have to be done?
Here, I appreciate that a lot of libraries are doing 3. now, it feels like from 1. that they are approaching this backward, that we have an opportunity with 4 to do it differently. I suspect that those libraries are implementing the best UX when you have a mouse wheel, but not when you have a trackpad. So it feels like they got stuck 10 years in the past.
True, it is important to know what is expected so we can try and innovate with the unexpected. 😄
But overall I hear you, we need to allow users to customise these settings.
Not sure if it is related to how you experienced it and your comment about the trackpad, but we previously had the inverse behaviour for scroll on a macos
trackpad. two fingers swipe up
would zoom in, but it was mentioned that google maps does the inverse, so I reverted it. It should be easy to detect darwin
and revert the direct for macos trackpad
google maps does the inverse
Oh interesting, I got so used to those UX behaviors, that my brain goes on auto-pilot when going to Figma and Google Maps, even though they respond to different gestures.
I will try to catch myself using those. I suspect I default to Figma UX when I use Google Maps: I pan up, it see it zoom, I undo it, then I start to click-drag. https://github.com/Leaflet/Leaflet/issues/7046.
It should be easy to detect darwin and revert the direct for macos trackpad
I would imagine that trackpads apply to Windows too. I had something like this in mind https://stackoverflow.com/questions/10744645/detect-touchpad-vs-mouse-in-javascript.
It is only inverted on macOS, due to how they handle scrolling.
It is only inverted on macOS, due to how they handle scrolling.
I don't know if it has an impact, I personally have the macOS vertical scroll direction inverted compared to what the OS default is.
Could maybe have logic we can copy for the features on mobile https://github.com/retyui/react-quick-pinch-zoom.
A new UX feedback. On a trackpad, mouse down + drag + mouse up, the same sequence of movement as to select text, quickly warms up the part of the finger in contact wit the trackpad because of the friction force ♨️. It's ok for small text selection areas, but unpleasant when moving a lot on Google Maps.
It could be why Figma is not doing this. In any cases, I wish Google Maps changed their UX.