-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Proposal: Mouse Wheel Behavior, Scrolling vs Zooming #2205
Comments
One critical difference between maps and Blockly: with maps it's immediately obvious that there is more to see beyond the current viewport. Roads go off the edge of the map, etc. In Blockly it's possible to have blocks out of view with no indication that they are there. The scrollbars are intended to hint that scrolling can actually do something; they also help the user to know where they are in the workspace. For this reason I don't want to hide the scrollbars on any scrollable workspace. We already allow developers to choose whether to scroll or zoom with the wheel. I think we just need to make sure developers know about that option, and can test to see which one feels more intuitive to their users. |
That is a very good point I did not consider, and I see how scrollbars are the most eligant solution to the problem.
I'm not sure that scrolling functionality is provided, without building it yourself that is. (Link, Link) Please correct me if I'm wrong! I've thought about it some more, and I've come to the conclusion that non-reactive scrollbars are the real issue here. Scrollbars really seem to scream that scrolling is an option. I will still try to scroll the workspace every time, and I will find it jaring every time. If scrollbars are to be shown, I feel that setting the scrollwheel to scroll by default is the best solution. |
Good point--we have the ability to disable zoom on wheel, but not to enable scrolling. Scratch-blocks has scroll-on-wheel. While I don't know what the best default is, adding scroll-on-wheel as an option would be a good feature. |
I backported the scrolling functionality from scratch, and it works really well, but I'm not sure how to set up the options:
|
@samelhusseini @AnmAtAnm @RoboErikG @alschmiedt Does anyone have strong opinions about what this should look like in the options struct? |
The connection between the scrollbars and dragging/scrolling is tighter than it needs to be, and it would be great to make this technically possible. But we still want to disallow it in the options parsing, because of the concern about users knowing whether the stage expands further. Related: we've had requests to be able to drag a block to the edge of the workspace and have the workspace pan, so you can move blocks larger distances without needing to zoom out or do lots of drags. That's also probably related to disentangling dragging and scrolling, so let me know if you want to do it and/or want more information.
Make it an object, like zoom or grid, and make sure that the current way of setting it still works going forward. Note that right now if you don't explicitly set scrollbars, you get them if you have categories and don't otherwise. That's intentional. |
On differences between the UX of Blockly and Maps... I'd say the most critical one is that the map is one large object, like if you put a physical map on a desk, all you can do is move the whole thing around, not individual objects within the map. Oh, and of course you can zoom by moving your head closer or further away. There is no other major target for a drag operation. Unlike Blockly where you have a bunch of blocks on your desk, the major drag interaction is with the blocks themselves (not the desk, if you think of it in physical terms), so having to also drag the empty space feels strange. |
@rachel-fenichel your comment here got me thinking:
And an idea came to me, I've open an new issue to avoid taking this off track any further: |
I'll throw my hat in the ring here as well, since we implemented our own wheel handler for App Inventor. For us, what we found is that, particularly for people with multitouch capable trackpads, users seem to intuitively get that using two fingers should pan the workspace, similar to what one would experience if using a touch screen. This also works if you have a mouse with wheel that supports left-right as well as up-down motion (1D scrolling falls back to up-down scrolling) because it ties into the scrollX/scrollY properties of the mouse wheel event. For zoom, we use Ctrl+Wheel, which has the side benefit in Chrome on macOS of being mapped to pinch-to-zoom gestures. Those who understand the touch screen approach also immediately get that if they do a pinch/expand gesture they can zoom in/out the workspace. And of course, there are the visible buttons as well for zoom because the ctrl+wheel approach isn't easily discoverable, so that's something we need to address. |
Good morning everyone! I also feel that zooming on scroll is unexpected and not the best user experience. They use scroll/drag to move around the workspace, and pinch (or cmd+scroll) to zoom, which I think work very well both on mobile and computer. After looking at both these pull requests (#2247, #1737), I've tried this set of (mostly undocumented) options that I'd expect to mimic that behaviour, but this way both pinch and wheel move the workspace.
Am I able to get this desired behaviour without hacking into blockly source code? --EDIT--
|
Problem statement
Lots of people don't like how the workspace zooms on scroll.
This is honestly just a guess, but I think this may be because the workspace is displaying scrollbars. The applications mentioned in #110 (Google maps, bing maps, yahoo maps, and autocad) do not display scrollbars, and people naturally use the mouse wheel to zoom.
Proposal
Scrolling would have precedence over zooming when handling a scroll event, but zoomWithWheel would have precedence over scrollbars when setting up the options. What I mean by this is:
If scrollbars is force-set to true and zoomWithWheel is force-set to true: "mouse wheel" would scroll the workspace and "ctrl mouse wheel" would zoom the workspace, so scrollbars still mean scrolling.
If scrollbars is force-set to true and zoomWithWheel is false, scroll events will scroll the workspace.
Edit: The ability to drag the workspace (isDraggable) would need to be separated from the workspace having scrollbars ( .scrollbar).
I believe this would preserve the maps-like-ness of the workspace, while giving better affordances.
The text was updated successfully, but these errors were encountered: