Exposing Variables

I was happy with the way interfaces were coming along last week.  However, if the variables that pertain to these implicit interfaces are not readily available, it's unlikely users will leverage this capability.  On a quest for inspiration, I looked at the way other people do it.  The places I looked were Scratch, Khan Academy, and two academic papers about teaching novices to program.  Essentially I learned that there's no easy solution because teaching people the concept of variables is hard.

In the academic papers, one of the studies was about Expert Vs. Novice programmers.  It showed that novice programmers struggled to grasp initialization of a variable, but that they readily grasped reading a variable.  Using variable assignment to update a variable was slightly more difficult, but was still within reach.  It mentioned that a problem novices had with loop variables was the variable being updated behind the scenes. Fortunately, in the loops we're talking about, initilization is handled for the user, and the loop variable being updated can be readily seen in Play & Explore.

The second paper dealt with a teaching strategy for introductory computer science classes.  In the strategy, the "roles" of variables are taught.  They claim that 99% of variable uses fall into 10 distinct roles.  If you teach these roles and then reinforce them any time they appear in the lesson, beginning programmers are more likely to be able to use variables when appropriate and outline how to initially approach a programming problem based on what variables and roles it will require.  I do not think introducing 10 categories of variables to the interface is appropriate for LG, but the 10 roles provide a base for what use cases we need to make easy.

Scratch didn't have a lot to offer since it's "variables" are almost identical to the old "properties" pane in Looking Glass with the added option of making global properties.  One nifty thing they had was a list of variables with a single getter and setter at the bottom with a drop down to change what variable it pertains to.  I thought this saved a lot of space and could be useful when we address how to put custom properties back into LG.

Khan Academy has a tutorial that was more a long the lines of what I want to use variables for.  They introduced the concept of variables as a way to increase efficiency.  They showed that having a variable in one place and using it many others makes it much easier to update your program since you only have to change the variable once.  This is the kind of behavior I'm looking to introduce since one of the initial motivations for implicit interfaces was to prevent having to recreate the same event listeners over and over.  Unfortunately, this doesn't help with where to put local variables in the interface, but it does provide a good template to use for tutorials to introduce variables.

I've made a sketch of another option of where to put the variables after this research.  Some pros about this design are that it makes variables easy to access.  It also makes it clear where they are coming from by putting the name of the method above the variables and it allows for global variables.  Additionally, it supports implicit interfaces by allowing you to "view" a variable that's an object.  Clicking the view button would bring it up as selected so you could see what procedures it has.

Some cons are that it introduces a whole new pane to the left hand side which has implications on the usabiltiy of the entire system.  Adding new panes willy nilly is never a good idea, but I think this one could be very useful.

Another option I was thinking of is a combination of the properties pane and this previous sketch.  This would put all the custom variables in one place. I thought about using the list of properties and single getter/setter like in Scratch, but I think having the actual draggable item there with the object who is calling the method is more consistent with the rest of the interface in LG.  I like this because it makes custom properties and local variables easy to access, but it could cause even more confusion.  It would be super convenient for me when I make games, but might not be as intuitive for novice users.