Toni and I have spent a lot of time over the past year thinking about pedagogical approaches that are effective for introducing CS topics to learners who are new to CS. Also, we’ve thought a lot about how to do this within relatively short learning episodes, such as a 60-minute conference presentation.
Our goal for the end of a 60-minute conference presentation is usually to have participants code out (on a calculator and also (usually) by hand) a rather complicated program — but, more importantly, to have made sense of said program.
In a recent conference session, our goal was for participants to code a program that modeled a back-up sensor on a car, complete with audio feedback based on how far the “car” was away from an object. This particular program (see Toni’s post here for more information) included sequential, branching, and iterative elements, as well as commands related to connecting to, collecting data from, and disconnecting from an actuator (or peripheral device). These are a lot of different elements for someone who is new to CS to integrate!
How might we design learning experiences to support sense-making around these varied commands/structures…in a way that is accessible for new-to-CS learners?
One approach that we have found particularly effective for this work is using flowcharts — specifically, using flowcharts that develop over time. Rather than just jumping right into this rather complicated flowchart (again, complicated for a new-to-CS learner!):
we instead provided the following blank flowchart and had participant pairs brainstorm what commands might need to go into this flowchart (and in what order) in order to read and display a distance measurement from an Ultrasonic Ranger attached to the Innovator.
Note that the task of collecting and displaying a distance measurement is not our end goal, which is to model a back-up sensor — but we deliberately wanted to decompose this program/situation into simpler situations first. In this case, before we model a full-on sensor, how might we code the Innovator just to collect and display a data measurement?
A quick debrief of ideas from the whole group (plus some information from us on what these commands look like for the Innovator) led to this filled-in flowchart:
With a completed flowchart, we quickly “translated” the pseudocode in this flowchart into the programming language of the TI-Nspire and TI-Innovator. Participants checked that their programs collected and displayed a valid distance measurement as intended.
Next, we asked participants to consider, What if we wanted to collect data measurements repeatedly, instead of just once? We provided the following blank flowchart and had participant pairs consider what commands might go in each element of the flowchart.
Participants talked through lots of important ideas here, including: What should go in the “decision diamond”? What commands should happen “outside” of the loop structure? What commands should happen again and again (i.e. inside the loop structure)?
Debriefing these ideas whole-group led to the following completed flowchart:
We quickly coded these additional commands/structures into the program we had started earlier and tested our new programs.
Now, our program collected distance measurements again and again until the distance was less than 0.01 meters. For the sake of our model, we said that this value represented the back-up sensor turning off after a collision — whoops! 🙂
However, our sensor wasn’t giving us very helpful feedback! It was displaying the distances, but who would be reading that display while backing up?! We wanted to add in audio feedback (beeps!) that alerted us if we were nearing an obstacle. Specifically, we wanted there to be two “levels” of audio feedback — warning beeps if we were nearing an object, but then a more urgent set of warning beeps when we got really close to an object.
We provided the following flowchart for participant pairs to discuss:
which led to a final debrief and this filled-in flowchart:
Here we were, finally, at our programmatic goal! We had collectively developed a program (in flowchart form and in coded form in our calculators) that modelled a back-up sensor.
Yes, it took a while to get there, but the time spent sense-making about the earlier situations and flowcharts helped participants develop and use appropriate CS structures and logic while creating this more complex program. We were thrilled with the engagement, discussions, and explanations from our participants, many of whom were new-to-CS learners!
Side Note: When leading this conference session, we ran out of time during the calculator coding of the final part of the program. 😦 We have discussed some time solutions for this for future presentations of this conference session including having participants code the first program on the calculator, but providing “almost complete” versions of parts 2 and 3 already on the calculator. This will cut time out of the session without losing any of the time that focuses on sense-making about the code.
To create these flowcharts we used the LucidCharts Diagrams Chrome extension, which allowed us to create and store these flowcharts in GoogleDrive.
Here’s a copy of our handout from the conference session; we wanted participants to leave with copies of the completed flowcharts so that they could later replicate this work on their own devices.
How else have you used flowcharts to introduce CS topics to new-to-CS learners? What other pedagogical or instructional approaches have been effective for making CS accessible to all?