Display variable type on dynamic getter and setter blocks

[rachel-fenichel]

The problem

The proposed dynamic variable getter and setter blocks (see google/blockly#1281) don't display the type of the selected variable, which will be confusing for users.

Possible solutions

1

Add dynamically update the text on the block to include the variable type (e.g. 'set string ___', 'set number ____', etc.).

We would have to consider internationalization implications.

This works for arbitrary numbers of variable types, but can make the blocks hard to read for users who aren't used to typed variables. They may see the variable type as a noun instead of an adjective, which will break the flow of the sentence.

2

Change the color of the block based on the type of the variable.

This would probably only work for a limited number of variable types, and could lead to confusion if there are conflicts with the colors of other categories of blocks. We could allow developers to specify colors for each type, but that requires an additional API.

Developers can accomplish the same thing by creating a similar block and adding an onchange handler with a lookup table for the colour, or by creating multiple getters and setters (one per variable type) with different colours for each block.

3

Add an icon to the block, and have it change based on the type of the variable.

This would require developers to specify icons per variable type, which requires an additional API.

Developers can accomplish the same thing by creating a similar block and adding an onchange handler with a lookup table for the icon, or by creating multiple getters and setters (one per variable type) with different icons on each block.

[reedspool]

Corollary of (3): Develop new set of connector shapes that suggest type. I bet this isn't an option, but can't convince myself why not.

Also to (3), icon means image, which means alt text for accessibility, which means same API and internationalization questions as (1).

[RoboErikG]

Shaped connectors are feasible, but add a lot of additional complexity, especially if you're allowing for custom shapes.

• Shapes need to be paired.
• They have to all be the same size to keep the connector calculations correct.
• They would need an API and more involved changes to insert into the svg rendering.

So they're out of scope for us short term, but something we could revisit later.

[rachel-fenichel]

I can convince you why not!

Shapes work for a limited number of types, but break down quickly when we have more types. They need to be increasingly complex, but that can be hard to distinguish, especially as you zoom out. There's just not a lot of room there for distinctive rendering.

They're also hard to use when a connector can take multiple types (e.g. you can print a string or a number: what shape is the connector?).

RE: icons requiring alt-text: yes! Thanks for pointing that out.

[duzc2]

When I wok with c# or java , the name of types are very long text as : System.ComponentModel.DataAnnotations.Resources.DataAnnotationsResources.
it's very ugly if we set it on the block.
also , there are toooo much types need tooo much colors or shapes.
how about add the type name in tooltips?
I use tooltips in my project , it look great for c# or java .

[duzc2]

@rachel-fenichel
Or , maybe add a pop menu item to show the current type and allow user to change it?

[duzc2]

The variables.js use a prompt input , it has no ability to chose a type.
how to input a variable name with a type of it ?
Any one has suggests?

[duzc2]

it must a large list in c# or java like language.
and for most edu case , we could think there are a few types.
we may need a base way to select type simply and a API to be extended.

[duzc2]

I have finished most of this work.
I found that there are many variable logic in workspace.js and block.js
if I make a new menu item 'change variable type' on the blocks I built , I need to add:
a enter in workspace , a event in event.js , a event handler in block.js
it must be invasive.

[rachel-fenichel]

We do not plan to support changing the type of a variable after creation.

[BeksOmega]

Moved this to samples as we don't want to add new blocks to core.