Hi Jodi

In terms of Expression, a couple of our digital activities are built around a core world in which students author expressions composed of a few dynamically-changing values that are in turn being "published" or "exposed" by a dynamic simulation. (These are the light-switches and alarm clocks you see in the video.) The environment can be configured to support different operator grammars (arithmetic operators vs. relational operators vs. logical operators vs. string operators), and the user interface permits only expressions on a single operator. This simplifies input requirements, accommodates a staged introduction of operator types (e.g. we use the environment to teach Boolean logic at one point), and defers the need for parentheses or order of evaluation considerations, since these are transparently distributed across multiple expressions. Since each expression always has, and always displays, a "current value" in terms of the dynamically changing values that anchor the whole "chain of calculation", and since the dynamic simulations generate a broad range of such sample input values quickly, conceptual and syntactic errors in students' new expressions tend to be revealed quickly, rather than await some more protracted test-and-debug cycle. Finally, each new expression can be given user-specified name, which serves as an identifier for its full symbolic flower in any downstream expressions that reference its value. This lets you control complexity as your expressions grow more involved (by encouraging you to name subexpressions), and introduces a very precise moment and action around which teachers can hold a discussion about "abstraction."

Overall, I believe it's a nice environment, and think it's one that could be used to anchor several more activites than we had time to develop. But there are still design weaknesses in the "new expression" interface, and it remains a challenge to design activities (instances of the environment) in which students find writing lots of expressions both engaging and sufficiently open-ended to accommodate multiple forms of success across varying degrees of ability and achievement. My favorite of our activities in this area involves designing an expression that determines when your alarm should wake you for school, based on some time-and-date inputs exposed by a simulated alarm clock. One student can succeed by setting it for 7:00, or--better---for 7:00am; whereas another student may realize she's going to be woken up on weekends and try to limit it to school days, but not in summer, and so on. Turns out there's lots to think about, in waking up! Teachers have commented this is both the most challenging and the most rewarding activity in our sequence.

Nick

Thanks Nick. Is there a way to see more of the activities?

Unfortunately our class materials -- lesson plans, student handouts, and so forth -- aren't ready for sharing; they are very much evolving assemblages.  The actual digital microworlds that students work with during the lessons are are all accessible online though: http://csforall.sri.com. The one I describe above is called "Alarm Clock."

Several of our activities use a passcode-based mechanism that throttles kids' exposure to and exploration of the environment through certain teacher-managed staging points. So at key points in the classroom script the teacher will introduce a passcode that unlocks the next level of functionality. For Alarm Clock, the stages are

• 1. no passcode (explore the basic clock operation and buttons. What sort of "quantities that change" are at play in a basic alarm clock? If you wanted to model them with "variables," how would you name those variables,  what sorts of values would you expect them to have, how would you explain them to a friend, etc.
• 2. passcode: "values". Ok, here are some variables the system gives us for its model. How do they match up with yours, what are their ranges, etc.
• 3. passcode: "expressions" (or "new" -- depending on which activity sequence). Ok, now you can add new values to the list yourself, defining each one with an expression in terms of existing values.  Can you build one determines when to ring the alarm clock? Once you define an expression with a boolean, rather than numeric value, you can optionally tie that value to the alarm clock's ringer, so the alarm will "ring" whenever the value is true.) Also note once you have booleans in your table of Values, the "Add New Value" panel grows to include logical operations and not just relational ones.
• 4. Passcode: "strings". This introduces some strings to the Values table, as well as some string operations (exact match and containment) to the "Add New Value" panel. Students working at this (optional) level aim for expressions like 'isWeekend: (dayOfWeek matches "Saturday") OR (dayOfWeek matches "Sunday")' or 'isWeekday: NOT isWeekend" so they can make sure their alarm clock only rings on school-days....

Enjoy!

Nick

Hi Neil,

A couple of our unplugged activities --

• "Story Variables" in which students investigate a series of stories all containing quantities or things that vary. Through partner and group discussion, students come up with a class definition of ‘variable’ and practice identifying and naming variables meaningfully, and also discuss aspects such as range of values. 
• "Dice Conditionals" in which we cover expressions containing arithmetic and relational operations leading to a boolean condition (True or False). Students learn how to use an expression to determine if a condition is satisfied and evaluate a conditional. We want them to understand the idea of an expression evaluating to TRUE or FALSE; students practice thinking in the IF THEN and IF THEN ELSE formulation through a simple dice game played in pairs.

Will share our curricular sequencing of our unplugged, digital (non-programming) activities and integration with Scratch shortly.

Hi Neil,

We sequenced our curricular activities such that students started with unplugged activities targeting a concept, and then proceeded to digital (non-programming activities) in some cases, and finally worked on Scratch programming activities aligned to the same target concept. Each Scratch programming lesson started by reminding students of concepts they had already encountered in the unplugged or non-programming digital activities, and included at least a few programming activities that closely aligned with previously completed non-Scratch activities.

For example, the unplugged "Story Variables" activity introduced students to the concept of identifying and meaningfully naming variables. Students built on this concept further in the "Cats and Ladders" digital (non-programming activity) where they identified and named variables, and then combined the variables using arithmetic operators to create arithmetic expressions. Later, once students were introduced to the concept of conditionals through the unplugged "Dice conditionals" activity, they combined these concepts of variables, arithmetic expressions and conditions to program "Conditionals using arithmetic expressions" in Scratch.

Thanks so much, Jeremy! It's the inspiring work on dynamic geometry and dynamics representations in Math (that you and SRI Math Ed researchers on SimCalc and SunBay/Cornerstone Math have contributed to) that was the basis for this work.
Great to be able to draw on that influential body of work and bring those ideas to CS education settings for deeper conceptual learning.

Hi Nicole,

Yes, we have really tried to ensure that when we teach students how to use a concept in the Scratch programming language, we can refer back to explicit terms and scenarios that students have already encountered in the non-programming activities and can relate with. 

In our recently concluded implementation of VELA, we interposed the VELA curriculum (3-4 weeks depending on degree of teacher scaffolding as appropriate for different student populations) into existing 9-week or 18-week CS curricula being taught to 6th, 7th and 8th graders in the SF school district. We start our curriculum with the digital non-programming "Graphical looping" activity involving the comic strip example with a swimmer, which you briefly see in the video. Here, we focus on helping students identify repeating patterns in real life objects or processes, distinguish between pre-loop, loop and post-loop actions, predict patterns using repeat generators, and represent scenarios using loops . This is followed by working on simple loops and nested loops in Scratch. Some of our Scratch scenarios are in the swimming context to help students relate to what they recently worked on in the "Graphical looping" activity. Next, we teach students simple conditionals without the use of variables in Scratch (for example," if (touching <sprite>)"), before introducing them explicitly to variables through an unplugged "Story Variables" activity. Students learn how to identify and meaningfully name variables from given stories, and specify range of variables. This is followed by another non-programming (but digital) activity called "Cats and Ladders" where students are tasked with saving cats from different levels of burning buildings in a city. In the process, they work with different variables associated with different ladders and arithmetic expressions combining the variables. Next, students work on an unplugged "Dice game" which they seem to have enjoyed a lot. They practice taking decisions (using conditionals) based on the die values (values of variables or expressions). These activities provide a nice segway to the next Scratch activity where students model real life scenarios and games using conditionals with arithmetic expressions. 

After this, we teach students how to combine loops, variables, and conditionals in Scratch. We teach students how to use variables inside a loop, and how the number of times a loop runs can itself be a variable (perhaps even an user input). Through this, we try to impress upon students the notion of generalizable programs as opposed to hardcoded ones. Following this, we move on to Boolean operators and expressions. We start with a digital non-programming activity called "3 switches" where students explore how different combinations of 3 switches help turn a lightbulb on or off. Then, students explore similar concepts in the Scratch environment, programming scenarios with different outcomes based on Boolean expressions. Finally, students work on an "Alarm clock" activity where they create logical expressions combining arithmetic, relational, boolean, and string operators to set their alarm at different times of the day and week. This culminates in a final Scratch lesson combining all the concepts learnt as part of VELA, along with the introduction of the "repeat until" construct.

Will share more details on the courses in a separate post, or one of my colleagues will.

Wow.  Your activities are well planned out and it sounds like they are set up such that all students would be successful in learning the computer science concepts while completing them.

Thanks Chris! Indeed, it has been an exciting and busy 18 months on this project.

You touch upon an important issue, and one that we are looking at more closely based on our first round of classroom research that just ended this Spring. 
We had originally designed the curricular activities for 7th-8th graders, and assumed familiarity only with arithmetic and relational operations. We did not pre-suppose familiarity with pre-algebra (though we figured they might be learning that alongside in math class). Interestingly, all children with whom we tested our earlier prototypes (including the 6th graders, and from different schools in the area), were familiar with "variable" from their math class. (Incidentally, their immediate response to the question: "Do you know what a variable is?" was interestingly along the lines of "Yes, it's like x or y..."). One of our goals for this project is help kids move beyond this understanding of a variable to the idea of variation and of variable as a "changing quantity or thing, that can assume different values over time." and also have meaningful names like "SizeOfShirt" or "PenPrice")

For our classroom research, though, it was suggested (by our district partners) that we add 6th graders to our sample. So we ran the intervention in 3 classrooms - 6, 7, & 8 grade. We did not change the activities much, but encouraged the 6th grade teacher (and all teachers really) to take more time to scaffold the activities if necessary, and our "theory of action" research included observations to see if and how teachers tweaked the curriculum in the classroom to meet their students' needs. We have yet to analyze the data deeply, but anecdotally it appears that some activities (especially the ones involving boolean expressions and abstraction) were a heavier lift for some 6th graders. 

In our refinement and next iteration, we do plan to design for more flexibility in the activities to accommodate varying learner levels in middle school.

Interesting one of our teacher partners commented that she found the curriculum to give *her* a much stronger conceptual foundation of these topics than she had, and that has helped her work so much better with her next cohort of students. She recommends it as a teacher PD curriculum as well :-)

Hope this long-winded answer addresses your question, Chris. My colleagues might have more to add :)

Thanks so much, Jennie! I am hoping that the new K-12 CS Framework will push toward a deeper conceptual focus while still balancing with other big ideas that our community has deemed important (such as ethics, diversity, creativity...). To your other question, no, not in this project -- we're not yet tying this with progressions in other content areas, although doing it with Math would be a natural extension of this work.

Thanks for your comments and questions, Art! The K-12 CS Framework is a great resource to guide future work..
Thanks also for your interest in using VELA. Our activities and curriculum are still undergoing improvements and refinements as part our Design-Based Research effort. We first prototyped the activities with small groups last Fall. This WInter & Spring we piloted them in 3 classrooms (with teachers teaching the curriculum, not researchers). Each phase (and especially our first classroom interventions) points to things that can be done better and leads to iterative refinement of the activities and curriculum. That said, we are certainly interested in other classrooms and settings in which it can be used. So we should definitely chat offline :) 
As for why our focus on those concepts.. we drew on a large body of earlier literature, including my own 2-3 year long doctoral dissertation research designing & studying intro programming/CS curricula for middle school. They point to these topics specifically as being more difficult for students to learn deeply because of the heavier conceptual lift for students. We also found these topics to have overlaps with Math, and were interested in exploring if we could productively draw on past Math education research that points to the use of dynamic interactive activities for helping diverse learners understand abstract math concepts in middle school. (One of our Co-PIs, Nick Jackiw, is a math ed researcher (and creator of the Geometer Sketchpad) who has had many years of experience in that space.)
I look forward to our more VELA-related discussions & conversations, Art, and exploring the possibility of your use of this curriculum in San Diego. That'll be very exciting!

Thanks so much, Jennifer! When we roll this out in a bigger way, we would love to be guided by your experience and expertise with PD. 

In our case, for the first round of interventions in 3 classrooms, the PD for the 3 teachers (and the district MS CS coordinator) included a foundational session where we presented a rationale for VELA. Then the PD took them through the curricular activities, with a focus on the new digital activities (rather than the Scratch activities). In some cases, we modeled how the activities would be led in the classroom. For all of them, the teachers interactively played with the activities. Though it was "professional development" we underscored that spirit was also one of getting feedback from the teachers on how to refine the examples and activities (in the time between the PD and the classroom intervention). So there was a fair amount of re-design of some things as well. The teachers were encouraged to tweak the lesson plans as necessary in the classroom. Those are all part of the "theory of action" research piece. 

We also held focus group-style conversations with teachers once in during and once after the intervention where they shared stories and feedback. (This was in addition to 2 individual interviews with each teacher).

The pedagogical strategies were incorporated into the lesson plans we created (and refined with the teachers).

Thanks so much, Melissa! You are so right-- we have a long way to go for establishing good curricular progressions for PreK-5 that will give students a strong foundation in computational thinking. To be honest, our focus in this project has been middle school. In the course of this research, especially based on our experience with 6th graders compared to 7th-8ths, we have been thinking about how younger learners could experience a similar focus in their work, and what it would take to make our activities more accessible or flexible to give them a "lower floor".

Incidentally, on another STEM+C project that we recently won at SRI, we are looking ways of integrating CT into PreK Science & Math activities. We are drawing on a lot of learning and thinking from the VELA project :-)

Thanks for watching and for your comments and interest, Lien!
Currently the curriculum exists as a set of lessons plans (for teachers), worksheets, review sheets (formative assessment) and a summative assessment that span about 20-25 hours. (In our research teachers took a variable amount of time, and we wanted to study how they slowed things down especially for 6th graders). The curriculum was studied in San Francisco Unified, a district that has started rolling out CS in middle school. So the curriculum was integrated into the (9 weeks long) middle school CS class. The teachers did an intro unit on CS & the world before VELA; and after VELA, they did a unit using Finch Robots and then the final project. SO this took the bulk of the intro programming unit (which they were would normally do with Scratch).

Based on our classroom research, we are refining the curricular activities and lesson plans. We are thinking about whether we should "package" it for future use, or let people pick and choose activities and lessons they may want to integrate. Or perhaps allow for both :-)