Introducing shadow blocks

[Neil Fraser]

Hi everyone.

A significant new feature just landed in Blockly: shadow blocks.

As you probably know, the toolbox may contain groups of blocks, not just single blocks.  So for example the repeat block comes with a number block already present.

The problem with these default blocks is that they are in the way if the user wants to use a variable (or something else) instead.  So one has to balance the cost of forcing the user to fetch a separate number block in some cases, vs forcing the user to throw away a surplus number block in other cases.

Shadow blocks solve this problem.  They don't need to be throw away (they can't be thrown away).  If the user wants to replace them, they may simply be overwritten.  Thus one can add shadow blocks far more liberally than one could default blocks.

Shadow blocks serve three purposes:

1) They provide ready to go type-in fields for block inputs without forcing the user to fetch more blocks.

2) They don't leave the user guessing what the default value of an empty socket is.

3) They don't leave the user guessing what the expected type for an input is.

Try them out in the playground:

https://blockly-demo.appspot.com/static/tests/playground.html

Please report any bugs as well as ideas to improve this feature.  Nothing is set in stone yet, so there's no documentation.

Speaking of documentation, there's a new page that talks a bit about code structure at a higher level.

https://developers.google.com/blockly/custom-blocks/code-structure

This page also highlights another new feature, "start hats".  If you like those bulging tumours that grow on the top of certain blocks in Scratch, you can get them in Blockly now too.

--

Neil Fraser, Software Engineer
Google, Mountain View, California

[toe...@extremenetworks.com]

I really like the shadow blocks and the implementation seems to be pretty solid.  A couple of feedback items:

1.   When a shadow block is attached to the right, it would be useful to have even the slightest outdent outline around it so that it is obvious that it is a place where you would drop a block.  You get the outline automatically when it is an inline block as your example shows for the repeat, but it looks a little funny when they are attached on the right.
2. I like the implementation with the <shadow> XML.  I've tested and have been able to put in a variety of blocks.

[toe...@extremenetworks.com]

Actually, a comment.  I am thinking that it would make more sense to be able to define the blocks with the shadow as a default part of it instead of counting on having the <shadow> XML in the use of the blocks.  It would allow for the code generators to count on always having a value to work from.
   -- John

[Erik Pasternak]

We originally thought about adding it to the block definition, the issue is that it depends on another block being defined and on setting the value in that other block. The block definition would need to be quite a bit more complicated to add in that configurable block dependency, while the toolbox xml already handles it.

[Neil Fraser]

Oh, I should probably introduce Erik Pasternak.  Erik is a coworker at Google who is working on a Blockly-related project (I'll let him say more when he and his team are ready).  He has a knack for asking awkward questions and pointing out regrettable design decisions in Blockly.  We argue a lot.  He's usually right.

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Neil Fraser
https://neil.fraser.name

[Jayod]

This solves a couple problems common with our users - accidentally pulling out or deleting number blocks while trying to edit them, and leaving fields empty.  

One concern - are users able to figure out that they are allowed to put a new block on top of the shadow block?  Do users feel like the slot is "full" and imagine that something else could be added?

[Erik Pasternak]

We have the same questions. Please let us know if you do any testing! =)

On Fri, Oct 9, 2015 at 10:48 AM, Jayod <yode...@gmail.com> wrote:

This solves a couple problems common with our users - accidentally pulling out or deleting number blocks while trying to edit them, and leaving fields empty.  

One concern - are users able to figure out that they are allowed to put a new block on top of the shadow block?  Do users feel like the slot is "full" and imagine that something else could be added?

--
You received this message because you are subscribed to a topic in the Google Groups "Blockly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blockly/bXe4iEaVSao/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blockly+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Erik Pasternak | Master of the House | epas...@google.com     

[Jayod]

Another potential issue is that because the shadow block is so pale, it is reminiscent of a disabled block.  I wonder if users will confuse them with disabled blocks, and be frustrated when they try to enable them via the context window and find no options available there.

[kbftizenkettő ftizenkettő]

I agree, shadow blocks look disabled. Users with high standards of accuracy/sense of beauty will want to replace them with regular blocks, which is as hard work as having nothing first. There should be a way to change shadow blocks to normal, e.g. right-click menu point. Also when a value is entered, they should change to normal.

(I prefer the previous way and probably won't update my toolbars.)

[Hendrik Diel]

I too agree with that users could easily become confused because shadow blocks look similar to disabled blocks.

Although i think the idea in general is very good..

[toe...@extremenetworks.com]

What about making shadow blocks be the same color as a normal block but instead of being outdented, make them indented/depressed?  This could also benefit from having a dashed line around them instead of a solid line to complete the fill in the blank aspect.

Another thought that comes to mind is that once a user changes anything from the shadow block, it could become a real block by popping forward into a normal representation.

[Neil Fraser]

On 14 October 2015 at 04:01, <toe...@extremenetworks.com> wrote:

Another thought that comes to mind is that once a user changes anything from the shadow block, it could become a real block by popping forward into a normal representation.

On 12 October 2015 at 04:49, kbftizenkettő ftizenkettő <kb.f...@gmail.com> wrote:

Also when a value is entered, they should change to normal.

You both came up with the same good idea.  Done.

Also tab and shift-tab now allow one to walk between fields.

[Jayod]

If the shadow block becomes a normal block when you enter a value, it no longer solves my users problems of accidentally removing the blocks when they meant to edit.  

Having a locked block that can have another block dropped on top of it (like a variable) was a great solution because editing was so much easier.  I'm not sure what it should look like, but the current "become a real block on value entry" loses one of the main benefits from my point of view. 

[Erik Pasternak]

I'm also not sure what people would expect to happen if they drag out the now real block. Does it get replaced by the default shadow block? Is that input now empty? Something else?

And a little additional background, part of the motivation for shadow blocks is that many blocks have a default value, even when nothing's attached. Shadow blocks was one way to make that visible to the user instead of keeping it as hidden information.

--

You received this message because you are subscribed to a topic in the Google Groups "Blockly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blockly/bXe4iEaVSao/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blockly+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Neil Fraser]

Have you tried the current version on the demo site?  If a shadow block is edited and becomes a regular block, then that block is dragged out, the original shadow block reappears.  I think this addresses everyone's concerns.

--

You received this message because you are subscribed to the Google Groups "Blockly" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jayod]

Yes, I tried the current version.  When the real block in front of the shadow block is deleted, the original shadow block appears, but with its original default value, not the value the user last entered, and it is sort of confusing to have a real block pop in there when you type something (though it is also pretty cool!).  Here's what I anticipate will be a common user problem (based on the usage I've seen of our tool in the classroom):

1. 

User gets block with shadow numbers in it onto the workspace (success!).  Assume shadow default is "1".

User tries to edit number block by clicking around the number.  When the number block is highlighted, they try to type. (fail - editor not engaged).  Typically they'll type a backspace in preparation for typing their new number.  without shadow blocks, the number block disappears (oh no!).  With shadow blocks, nothing bad will happen. (yay!)

User tries again to edit number block by clicking around the number.  Sees the editor come up.  types number (say "2").  (success!)  Shadow block turns into real block.

User realizes they need the block to contain a "3".  They click around the number hoping to edit the number.  They manage to select the number block. They hit backspace in preparation of typing their number.  Real block disappears, replaced by the shadow with a "1" in it.   User is confused.

Our users eventually get more adept with the editor interface, of course, the slowest being older adults and kids (age 7-11) with no mouse skills (they only have a tablet at home, and we teach on computers without touch screens).  But accidental deletion of number blocks is a very common problem.  Currently we mitigate it by having undo, and replacement number blocks that they can get from the Math category.  

The current shadow block implementation is great as a substitute for an invisible default value for a field, but that wasn't what I was mainly hoping to solve.  Rather than invisible defaults, we pre-parse code and alert the user to blocks with missing number blocks by highlighting the blocks in red and giving the user an error message with the number of missing fields, which has worked pretty well for us.  But just playing around with the original shadow block implementation you showed, I really liked that it became much less likely to accidentally delete the number block while trying to edit, because the block is locked in, while still allowing variables to replace the numbers. 

[Ashish sipani]

How to create shadow blocks in blockly and how to generate code for blockly?

[Beka Westberg]

Hello,

Here is the documentation on shadow blocks. Here is the documentation on code generation.

If you have more questions please post them in a new thread. I'm sure someone would be happy to help :D

Beka