Design - Fields / Selectors

[thisandagain]

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

[thisandagain]

For reference, the current list of fields in blockly:

• angle
• checkbox
• colour
• date
• dropdown
• image
• label
• textinput
• variable

Couple additional fields that we have in Scratch:

• musical note (keyboard)
• input / dropdown (combo)

[thisandagain]

@carljbowman This one really relies on #2 and #3, but this is here to get the conversation started. @NeilFraser has a bunch of great thoughts on some of these in his "Wat" paper that we should make sure to reference as well.

[thisandagain]

Follow-up from yesterday's discussion:

• Defined list of required inputs in two phases (needs for horizontal and vertical grammars). List added above.
• The three basic fields needed for the horizontal grammar should be our first priority
• We still need to define a plan for how these fields / inputs adapt across platforms / form factors

[thisandagain]

@carljbowman Any updates?

[carljbowman]

There are a lot more nuances to inputs across devices. For example, how the scripting area/workspace scrolls when the keyboard opens? Or when a dropdown opens on an edge?

@tmickel and I have discussed the desired behavior and I am working on synthesizing, but these specs highlight sizing and normalization across Vertical & Horizontal.

Here is a hacky prototype to demonstrate interaction with Number and String inputs:
fields-prototype.zip

Number Inputs

String Inputs

Dropdown