Design - Zoom controls

[thisandagain]

In Scratch on web / desktop we have zoom controls in the bottom right of the editor:

For tablet and desktop / web, we should make a decision as to what we want:

• No controls (no zooming)
• Button controls
• Pinch to zoom controls

One consideration is that "pinch to zoom" will impact the potential for multitouch interaction with blocks.

/cc @tmickel

[NeilFraser]

Minor point: The "=" button on Scratch zooms to 100%, where as its equivalent in Blockly zooms to 100% and also snaps to the center of the workspace. I think snapping to the center is better (otherwise one can end up looking way offscreen), but this functionality can be disabled if you want to keep the Scratch behaviour.

[tmickel]

Is it even possible to properly support pinch-to-zoom on desktop? I'd say no given that many users will be using a mouse (and I'm pretty sure JavaScript click events don't support multiple pointers/gestures).

We could go for pinch-to-zoom on touch and button controls on desktop, if we're willing to have an inconsistent experience.

Or, my preferred approach would be having buttons on both platforms, which would let us do multi-touch on tablets/phones.

[NeilFraser]

If the desktop only has a mouse, then pinch-to-zoom is impossible. But we definitely want to support pinch-to-zoom on desktops with trackpads, touch screens, or other multi-touch inputs. JS exposes a list of touch points, the rest is just math.

[tmickel]

On my Macbook no touch events seem to be generated in browsers (in Google Maps, for example, the whole page zooms, not just the map frame). I'm assuming devices with touch screens might work. We'd also need to disable page-level zooming triggered by multitouch gestures in the browser.

[thisandagain]

@carljbowman I recommend we avoid zoom controls for the I/O prototype. Thoughts?

[carljbowman]

@thisandagain - Holding off on zoom for the I/O prototype is fine with me. Especially with the Nexus 9's larger screen there is less of a need to zoom out/in to move around.

[tmickel]

@carljbowman This is on the list for the prototype, so we'll need a design.

[carljbowman]

Assigning both @rachel-fenichel and @picklesrus – Was not sure who to assign as I know there are refactors going on in Blockly that may impact these changes. Feel free to reassign.

We held off on exploring pinch zoom in touch environments, namely the I/O prototype. As we focus on the desktop experience, pinch zoom will remain out of scope.

Zoom In/Out Behavior

Overall we should keep Blockly's zoom behavior: zooming towards the center of the workspace viewport. Since the viewport includes the Block Palette and in Scratch Blocks we always have the palette open the zoom feels a bit off. We need to account for the blocks palette width (vertical grammar) or height (horizontal grammar) when zooming.

Reset Zoom Control Behavior

Currently Blockly does two things when resetting: returns to 100% zoom and repositions the viewport to the center of the blocks. This centering behavior can be a bit disorienting and should be removed.

Reset should instead just return to 100% zoom and position to the center of the viewport, similarly to how zooming in/out positions.

Zoom Controls Postion

If this is not already implemented within the code, we should allow the controls to be positionable in the corners of the workspace: top-left, top-right, bottom-left, bottom-right. Default position in Scratch-blocks should be bottom-right (or in RTL bottom-left).

Design & Icon Assets

zoom-icons.zip

Scroll Gestures

The current behavior in scratch-gui feels appropriate: scrolling should move (scroll) the workspace in rather than zooming the workspace, which is the current behavior within the Blockly Playground.

[rachel-fenichel]

More spec, from an offline discussion with @carljbowman:
The zoom buttons/icons on a layer above the blocks by default. When dragging the workspace the blocks move above the icons. When dragging blocks/block stacks, the dragging blocks move above the icons.
The icons should be opaque with a button around them.

[thisandagain]

@carljbowman From the assets here (particularly due to the mock being zoomed in) there are still a few questions:

• What are the outer dimensions of these buttons (the assets you provided are ~10x10px / existing zoom controls are 32x32px)?
• What is the vertical margin between them?
• Is there a hover state?

Alternatively: having the latest general GUI mockup easily available in vector could help alleviate these questions as well.

[thisandagain]

Quick first pass:

Current status at 300% zoom (compare with above both at 100%):

Current status at 100% zoom:

I switched these over to SVG (currently renders from sprites.png), but SVG rendering thins out the strokes (differences in anti aliasing). Looks like they are breaking up / hard to parse at 100% zoom. @carljbowman and @lifeinchords any thoughts? My instinct is to bulk up the sizing and strokes a bit.

WIP commit here: thisandagain@fd95bb1

[cpseager]

Would putting 100% as the middle icon (as it was in 2) make its function more obvious?