In Scratch we allow both the "player" and the blocks themselves to modify the state of a program. Because of this, we need a way to allow more than one (in our case: two) client to modify the representation of a program. Support for this is encapsulated in @NeilFraser 's "realtime" work. Placing here for further discussion and to track progress.

/cc @cwillisf @tmickel @rschamp

We are unfortunately going to end up breaking quite a few of the demos. Prior to making this repo public we should make sure to audit / update / remove items from the ./demos directory.

http://www.scratchjr.org/learn.html#blocks

• Say
• Grow
• Shrink
• Reset Size
• Hide
• Show

Depends on #2

Update sound effects with assets from Scratch / Scratch Jr. Now would be a good time to audit these with the design team:

• click
• delete
• disconnect
• change category

@carljbowman any thoughts?

An error shows up in both playgrounds on load.

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

We still need to finish work on rendering / connections for our iterator blocks:

• repeat
• forever

The new event model just landed:
google/blockly#252
You may wish to merge this at your convenience.

Currently if the toolbox position is not start, they will be overlapped by the flyout.

We need two separate playgrounds for the horizontal and vertical grammars that represent our reference implementation for each.

In blockly the mouse scroll wheel defaults to controlling zoom level. This feels pretty confusing IMO on Mac OS and we've discussed mapping our pan / zoom behavior to be closer to what is used in Apple Maps. Related to #43

To Do

• Define list of supported "fields"
• Initial design pass for each field
  • Horizontal
    • String
    • Number
    • Drop-down (events)
  • Vertical
    • String
    • Number
    • Drop-down
    • Angle
    • Musical note (Keyboard)
    • Color
    • Variable
• Design review
• Second design pass
• Handoff for implementation

Questions

• Device / platform specific fields?

Related to #2 #3

http://www.scratchjr.org/learn.html#blocks

• Move right
• Move left
• Move up
• Move down
• Turn right
• Turn left
• Hop
• Go Home

Depends on #2

http://www.scratchjr.org/learn.html#blocks

• Wait
• Stop
• Set Speed
• Repeat
• Forever

Depends on #2

• Set dates (1/25 – 1/29)
• Collaboratively set agenda with Google Team
• Book a room at the Media Lab
  • Monday: 244
  • Tuesday - Friday: LLK meeting room

We should normalize the block names with what exists in the scratch-flash codebase. This will make eventual work on the runtime / project serialization easier.

/cc @cwillisf @tmickel

• Allow Toolbox to be placed at different locations.
• Allow Toolbox to support horizontal layout of blocks and labels.
• Make sure Toolbox labels can support icons.
  • Allow icons instead of text labels.
  • Ensure alt text for icons works.
  • Support selection UI for icons.

blocks_compressed.js as generated only includes blocks in blocks/*

This causes out horizontal blocks to break when trying to use the compressed version as in https://developers.google.com/blockly/hacking/building

http://www.scratchjr.org/learn.html#blocks

• Start on Green Flag
• Start on Tap
• Start on Message
• Send Message

Depends on #2

Illustrator File

R4_Standard Block.ai.zip

General Size / Icon

Radii

Implement numeric inputs for horizontal blocks. E.g:

• Repeat
• Move
• Turn
• Hop
• Grow

/cc @carljbowman

Likely not something we will want to support going forward but rather we should be sure to point folks to it within the google/blockly codebase.

• Confirm Apache 2.0 license with MIT's Technology Licensing Office
• Create copyright document with MIT and Google teams
• Add to repo

For local development and prototyping (as well as design reviews around the lab) we should implement and lightweight iOS wrapper application around playground.html.

This exists upstream. It seems like a merging issue because it was fixed in 5297344 but then reintroduced in 6e6a04b.

Blockly has a really nice translation pipeline setup with https://translatewiki.net/. We'll need to adapt this for use with our translation workflow in Transifex for the vertical grammar.

/cc @mewtaylor

We currently have two different ways to "insert" a block that is inconsistent between Scratch and Scratch Jr. From observation (particularly on mobile devices), we'd like to implement a variant of our design from Scratch Jr for all grammars.

Scratch Jr

Scratch

Scratch (Prototype)

Blockly

Tickle

Questions

• In Scratch Jr and some of our prototypes even if you are inserting a group (stack) of blocks, the UI only shows an insertion shadow for the top / outer most block. This is different from some other Scratch variants in which the entire group is shown. This is done to avoid jarring changes in the display (see Tickle for reference) but comes at the cost of slightly inconsistent behavior. This is something we should discuss / spec.

Test suite will need to be updated to reflect new grammar, blocks, and generators. While doing so, we should automate the jsunit and jslint testing via Travis-CI which should help with open source contribution quite a bit.

Create a new playground.html for the horizontal grammar including updated blocks, toolbox, and generator(s).

• Define subset of blocks for initial design pass
• Initial design pass
  • Input Block (Integer)
  • Hat Block
  • Input Block (String)
  • Dropdown Block
  • C-Block (Repeat)
  • Variable Block
  • Dropdown/Input Block (Integer)
  • Boolean Block
• Design review
• Second design pass
• Handoff for implementation

Blocks with no input should be rendered as a "hat" as per spec from @carljbowman

Current

Spec

We need a spec for highlight (selection) states for blocks. Ala:

Common source of typos and inconsistent with the rest of the Scratch codebase and HTML / CSS.

As per our testing with Scratch Jr and Scratch on tablets, blocks should "grow" under the user's finger during a "drag" operation. Assigning to @carljbowman to spec and drop-in any additional context.

Blockly currently:

• Deletes the block if it's dragged out of the side with the toolbox, no matter how far past the toolbox the drag ends.
• Otherwise drops the block at the point in the workspace nearest the pointer's final position, no matter where the pointer exited the workspace.

Scratch currently:

• Deletes the block if it's dragged into the "flyout" section of the toolbox.
• Adds the blocks to the other sprite and returns them to their original position, if the drag ends on top of a sprite.
• Otherwise returns them to their original position, including if they were dropped on the category section of the toolbox.

We need to design the overall GUI for our initial prototypes with special emphasis on the palette (toolbox) / workspace paradigm. Discussion with the team has suggested that we should quickly explore and prototype a range of options. This is due to the fact that no one solution really seems to be perfect just yet.

Benchmarks / Reference

• Scratch
• Scratch Jr
• Blockly
• Blockly Games
• Tickle
• OzoBlockly
• Dash & Dot

Blocks currently only accept a hue rotation value. We'd like to modify this to allow either a hue rotation value (number) or hex color value (string).

Example

{
  "id": "math_foo",
  "message0": "foo bar",
  "args0": [],
  "colour": 120,
  "tooltip": "",
  "helpUrl": "http://www.example.com/"
}

{
  "id": "math_foo",
  "message0": "foo bar",
  "args0": [],
  "colour": "#C98323",
  "tooltip": "",
  "helpUrl": "http://www.example.com/"
}

Reasoning

• The HSV and HSL color models are really handy, but are unrelated to human perception. Because of this, having the flexibility to make small adjustments in order to make the color system look unified and aesthetically pleasing is important.
• Looking at a few other implementations (Dash and Dot, Sphero, App Inventor) it looks like modifying blockly to allow the specification of absolute color values is pretty widespead.
• Scratch's block colors are fairly well established and understood by the existing userbase.

/cc @afmckinney

Implement string inputs for horizontal blocks. E.g:

• Say

/cc @carljbowman

Blocks go left; scrolling goes right.

As we port over the Scratch grammar we should decide which generators we want to support. My initial thought is we'd want to support a generator for Javascript and a generator for SB2(3) but drop support for some other languages which the community can help us fill-in over time.

This is likely a topic for our kickoff coming up soon, but feel free to drop any initial thoughts in here:
/cc @cwillisf @rschamp @mewtaylor @NeilFraser @rachel-fenichel

I was thinking that it might be helpful, since the methods for handling svg drawing are visual, to adopt a coding convention that contextualizes the methods visually in addition to docstrings. These comments could show an example of what the method draws, as well as reference constants/variables used throughout the method spatially/visually for debugging purposes. Here's an example of what I'm kind of thinking of roughly:

/**
 * Render the left edge of the block.
 * @param {!Array.<string>} steps Path of block outline.
 * @param {!Object} connectionsXY Location of block.
 * @param {number} rightEdge Minimum width of block.
 * @private
 *
 *                 __
 * start point -> /
 *                |
 *                 \
 *                  \
 *                   |  <-- Blockly.BlockSvg.NOTCH_HEIGHT
 *                   |
 *                  /
 *                 / 
 *                |
 * end point   -> \__
 */
Blockly.BlockSvg.prototype.renderDrawLeft_ =
    function(steps, connectionsXY, bottom) {
.
.
.
};

Thoughts?

In the process of quickly implementing the horizontal grammar we broke RTL in a number of places:

Depends on #31

The Scratch team uses NPM as the dependency management system for new JS projects. Because of this, it would be nice to have a clear process for release "tagging" and publishing to NPM.

Looks like this has been explored quite a bit already by the blockly community:

• google/blockly#136
• google/blockly#177

To Do

• Define subset of blocks for initial design pass
• Initial design pass
  • Flag
  • Event receipt
  • Event emitter
  • Move right [int]
  • Reset
  • Say [string]
  • Repeat [int]
  • Forever
• Design review
• Second design pass
• Handoff for implementation

Questions

• Should the "forever" block continue to be an end-cap? No (see below)
• Should we have a template for a block w/o an icon (text-based)?
• How do we handle use-cases like the "Mic" block in Scratch Jr?

@carljbowman and @tmickel experimented with multitouch a bit in the "Shakespeare" prototype. We need to spec our desired behavior / interaction.

Related to #24 #43

Bring in the latest from https://github.com/google/blockly (2016 branch?). @NeilFraser which branch should we pull from?

Since this depends on work in progress in Blockly a merge from upstream Blockly should be done on a regular basis to avoid large painful merges in the future. A standard merge can be used as this project will never be merged back in to upstream.

https://help.github.com/articles/syncing-a-fork/

Let's set up a schedule for this and can investigate automation if needed.

The notch as currently rendered does not match the spec from @carljbowman

Current

Spec

Blockly:

• Dragging blocks can pick up blocks whose outputs are near the moving block's inputs.
• Dragging blocks can be dragged into other blocks (moving block's output connects to stationary block's input)

Scratch:

• Dragging blocks can be dragged into other blocks (moving block's output connects to stationary block's input)
• Dragging blocks will not pick up blocks whose outputs are near the moving block's inputs.