-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve zoom/pan on Mac touchpads #87
Comments
Yes, it's a mental model difference. Out of interest, when using a touchpad what way would you drag your fingers to scroll down? Would you drag your fingers down to move the viewport down, or drag your fingers up to drag the document up? Because I would have thought that an inverted scroll direction would apply to what you're reading from the |
I drag my fingers down to scroll down. You know, like pressing Page Down =). I made a little REPL that shows wheel event statistics when you do a pan gesture over an area. A chromebook touchpad reports this sort of pan events in Chrome: median time between events is ~16.7 ms, typical pixel{XY} magnitude 10-20, 40 if going fast. The signs are as follows:
Well now comes the embarassing part... I tried to play a puzzle and the controls do seem to be inverted... Things move up where I expect them to move down. I tried a different device too (a linux laptop with Firefox). This one does "drag fingers up to scroll down a page". So pixel{XY} signs in events are inverted and panning in the puzzle works like I want it too. Pixel magnitudes are also about 2x higher and panning seems somewhat too sensitive. So maybe the panning directions are just plain inverted everywhere and I never noticed... I'm gonna go burn in shame for a while 😅. If would help me a lot if you could check out the REPL too and report the signs, magnitudes and frequency of pan/zoom gesture events on your device. |
Just confirming that the expectation is opposite on Mac. I think it’s because they want the touchpad to work like a tablet. (I’m so used to switching back and forth that I don’t notice it anymore. But the page and puzzles are doing opposite things on my Mac.) |
I started a branch for this issue and began by inverting the panning direction and halving panning sensitivity. Panning now works as expected on my two devices, how about yours? Preview link where you can try out the changes: https://hexapipes-git-better-wheel-gereleth.vercel.app/ I also found out that zoom gestures are really hard to make consistent between my two devices - either one is too fast or the other is too slow. Maybe a zoom control is necessary after all - zoom in/out buttons or a slider, maybe some hotkeys too. |
Works well on my MacBook. |
There are some issues with how zoom and pan functions work on Mac devices. Some were described in issue #40 that resulted in a setting to disable zoom and pan.
The problems as I understand them:
No one complained about zoom strangely 🤔
I'd love to improve the situation but I'm flying blind here as I don't have any Macs at hand to test on.
For panning directions my mental model is that when I'm zoomed into a large puzzle then I'm looking at it through a small view box. I touch a touchpad with two fingers and this action "grabs" the view box and I move it around to see a different portion of the puzzle. So if I'm looking at the top of the puzzle and I want to see the bottom instead then I'll pull my fingers down on the touchpad.
When people say that the panning direction is inverted does that mean that their mental model is different (view box stays stationary and you drag the puzzle instead, so fingers move up to go from top of puzzle to bottom) or that the model is the same but the actual result is wrong?
If it's a mental model difference then I see two options for resolving this:
As for panning sensitivity it might be that some event throttling could help. I'll try to make a REPL where we can find out how panning action events look across devices / browsers.
cc @Aaron-Rumpler who volunteered to provide feedback about this =).
The text was updated successfully, but these errors were encountered: