Scratch-blocks: Wrapping blocks

[towerofnix]

Whenever I program with Scratch, blocks being too long is always a problem. For example, here are some scripts from my more complicated projects:

And I've seen them get _much_ longer than that.

(For reference, Snap! does use block wrapping, so having the editor open while reading this might be useful..)

I think it would be helpful if (vertical) blocks would automatically re-layout themselves when they start becoming pretty long, so that you can see them all in a conveniently short (but still long enough to work with) space.

This would also probably help with organizing scripts - "clean up" would make columns of more similar width.

Here's what the example scripts above look like in Snap!:

However, block wrapping brings up a couple of questions. What should we do with input literals?

In Snap!, they don't wrap at all:

It's possible that we could make inputs wrap like normal blocks on the inside.

For a more internal question - should blocks have specific line break points, or should breaks happen dynamically? Or should there be a combination of both?

Here's an example in Snap! with manual line breaking (I added %brs to the spec of the blocks):

They definitely look better than before.

But then you get this, when there aren't any input values:

..which doesn't look so great. So it's a little puzzling, exactly how manual/dynamic breaks should be handled..

Here's the project.xml download for the demo Snap! project: http://www.mediafire.com/download/6iu71f1737kqqok/Wrapping_Demos.xml

And of course this is just all an idea. :)

(Edit 2018 03 18: Formatting fixes.)

[tmickel]

Definitely an intriguing idea! Thanks for taking the time to put together all the screenshots and notes.

It seems like there may be a huge benefit here of making long-nested blocks easier to read and parse. But, I wonder if there is some trade-off - for example, after seeing a wrapping block in someone's project, does this make it harder to find the same block in the palette (i.e. since the shape is different)?

I'm not sure how much the Scratch team has discussed this before. Referring to @thisandagain @carljbowman who may know more and have more ideas.

[rachel-fenichel]

Jumping in with a description of Blockly's behavior around this:

Inputs can be inline or external. Here's a simple block with inline inputs:

If you right click you can explicitly set a block to be inline or external (third option here):

If I set this block to be external, it looks like this:

Inline vs external state is mostly set by heuristics for each block (we can get into those later if you're interested), allowing for different states depending on language. The developer can also explicitly set a block to have either inline or external inputs.

When you save and load a workspace, if you have explicitly changed the inline state (through that right click menu) it will save and load with that state--otherwise it'll save and load with the inferred state.

This is useful in the cases you've mentioned above. It generally does the right thing by default, and it gives an advanced user more power.

Edit: Here's the documentation https://developers.google.com/blockly/guides/create-custom-blocks/define-blocks#inline_vs_external

[towerofnix]

That's interesting, though it does still have the trouble of not really knowing where you can find a block in the block palette..

[CatsAreFluffy]

What about a right-click option for showing the block in the palette?

[towerofnix]

Possibly a smooth animated scroll to where it is in the palette (if you have the category selected) to give you a better idea of where it is relative to other blocks?

[chrisgarrity]

Moved to LLK/observations#34