Proposal: Mouse Wheel Behavior, Scrolling vs Zooming

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.

[ewpatton]

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.

[rachel-fenichel]

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.