Skip to content
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

Closed
BeksOmega opened this issue Jan 1, 2019 · 10 comments
Closed

Proposal: Mouse Wheel Behavior, Scrolling vs Zooming #2205

BeksOmega opened this issue Jan 1, 2019 · 10 comments

Comments

@BeksOmega
Copy link
Collaborator

BeksOmega commented Jan 1, 2019

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:

  • Scrollbars would now default to true only if the workspace has categories, and zoomWithWheel is false. (So if you can zoom with the wheel, there will be no confusing scrollbars)
    var zoom = Blockly.Options.parseZoomOptions_(options);
    var hasCollapse = options['collapse'];
    if (hasCollapse === undefined) {
      hasCollapse = hasCategories && zoom.wheel;
    }
  • 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.

@rachel-fenichel
Copy link
Collaborator

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.

@rachel-fenichel rachel-fenichel added component: coordinates issue: feature request Describes a new feature and why it should be added component: events type: question and removed issue: feature request Describes a new feature and why it should be added labels Jan 9, 2019
@BeksOmega
Copy link
Collaborator Author

One critical difference between maps and Blockly: with maps it's immediately obvious that there is more to see beyond the current viewport. In Blockly it's possible to have blocks out of view with no indication that they are there.

That is a very good point I did not consider, and I see how scrollbars are the most eligant solution to the problem.

We already allow developers to choose whether to scroll or zoom with the wheel.

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.

@rachel-fenichel
Copy link
Collaborator

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.

@BeksOmega
Copy link
Collaborator Author

I backported the scrolling functionality from scratch, and it works really well, but I'm not sure how to set up the options:

  • Should you be able to set scrollWithWheel to true if scrollbars is false (essentially separating draggability from scrollbars)?
  • Should the scrollbars option be converted into an object like zoom or grid, or should a scrollWithWheel option be added?

@rachel-fenichel
Copy link
Collaborator

@samelhusseini @AnmAtAnm @RoboErikG @alschmiedt Does anyone have strong opinions about what this should look like in the options struct?

@rachel-fenichel
Copy link
Collaborator

rachel-fenichel commented Jan 25, 2019

Should you be able to set scrollWithWheel to true if scrollbars is false (essentially separating draggability from scrollbars)?

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.

Should the scrollbars option be converted into an object like zoom or grid, or should a scrollWithWheel option be added?

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.

@BeksOmega BeksOmega mentioned this issue Jan 31, 2019
3 tasks
@jollytoad
Copy link
Contributor

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.

@jollytoad
Copy link
Contributor

@rachel-fenichel your comment here got me thinking:

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.

And an idea came to me, I've open an new issue to avoid taking this off track any further:
https://github.com/google/blockly/issues/2294

@ewpatton
Copy link
Contributor

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.

@pantoninho
Copy link

pantoninho commented Mar 27, 2020

Good morning everyone!

I also feel that zooming on scroll is unexpected and not the best user experience.
I'm trying to mimic figma.com zoom/move interactions using available move/zoom options (even the undocumented ones) with no success.

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.

 const blocklyOptions = {
    scrollbars: true,
    zoom: {
        controls: true,
        pinch: true
    },
    move: {
        drag: true,
        wheel: true
    }
}

Am I able to get this desired behaviour without hacking into blockly source code?
Thanks and keep safe

--EDIT--
I was able to get the desired behaviour by ditching the zoom.pinch option and using zoom.wheel:

 const blocklyOptions = {
    scrollbars: true,
    zoom: {
        controls: true,
        wheel: true
    },
    move: {
        drag: true,
        wheel: true
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants