Open dhess opened 3 years ago
Note to self: come back to this later and add my thoughts on why a generic "Use a variable" action might not be very useful in large programs. Sometimes you only want to see local vars and you know it, and sometimes you know you want to use a function and only want to see functions.
Please see design mock-ups below:
Vertical bar between name and type, and align them so they line up vertically across multiple buttons.
Design 1
Show the name as the main label and show the type as a “tag.”
Design 2
Use type names as headers to organize values/variables.
Design 3-1
Design 3-2
Design 4
See Figma file
All of these are a significant improvement over what we have now. Unsurprisingly my preference is 3-1
, as I think it makes the best use of the limited space on many students' screens. Though I actually prefer the simpler styling of the headers from https://github.com/hackworthltd/primer-app/issues/96#issuecomment-948735508, Design 5
.
Could we also see a Design 1-2
which addresses the part about aligning the bars "so they line up vertically across multiple buttons"?
Could we also see a Design 1-2 which addresses the part about aligning the bars "so they line up vertically across multiple buttons"?
Sorry, missed that one, see below: Design 1-2
We should display list of variables similar to list of values, see #96 for when the design is finalised.
(This comes from @annedino4's User Research Report Round 2, issue number 18.)
In Vonnegut, when the student selects “Use a variable” or “Use a value”, we present them with a list of buttons, one per variable/value, whose labels are formatted as
name : Type
. However, early testing indicates that students are conflating the name and type. For example, for variablex : Direction
, when asked to say which variable they're inserting, they will sometimes say "Direction”.Can we help students differentiate via better labels? For one thing, we don’t format these labels very nicely — the names and types run together and they don’t line up vertically. We’ve discussed this at length and have so far come up with the following ideas:
x
andy
might be quite small compared to, e.g.,directionToInt
and make the former more difficult to select in a touch interface.