To engage all learners, we must design more ways to tinker with electronics beyond just the computer science curriculum.

by Kreg Hanning

New tools designed to get kids building with electronics are popping up all of the time. Micro:bit, Arduino, and littleBits are just a few of the names you will come across if you spend any time exploring this space. While I am truly excited at the prospect of introducing more young people to the world of electronics, I often worry about the way these tools are marketed, and in turn, which groups of kids are encouraged to engage with them.

Far too often I see these tools being discussed only within the context of a computer science or electrical engineering curriculum, rather than as another medium to engage in creativity. If we want to engage learners of all backgrounds, we must introduce these tools as another way for students to explore and interact with the world around them.

At the MIT Media Lab, I am a part of the Lifelong Kindergarten (LLK) research group. One of the main goals of LLK is to leverage new technologies to design systems that support creative learning through play. The constructionism learning theory expressed by Seymour Papert lies at the center of our group's philosophy. It is our belief that people learn best when they are actively constructing knowledge by working on problems that are particularly meaningful to them, in a playful way. For the past 10 years, LLK has supported these types of learning experiences by developing and maintaining  a programming language and online community called Scratch > scratch.mit.edu

From scratch.mit.edu/about:

With Scratch, you can program your own interactive stories, games, and animations — and share your creations with others in the online community.

Scratch helps young people learn to think creatively, reason systematically, and work collaboratively — essential skills for life in the 21st century.

My own research centers around designing tools that create bridges between creativity on the screen and in the physical world. A lot of this work has been done in the form of Scratch extensions. As the name implies, Scratch extensions extend the Scratch programming language by introducing new programming blocks that connect to hardware devices or web services. For example, there are now Scratch extensions that enable members of the Scratch community to interact with (or access data from) Arduino, Twitter, micro:bit, Spotify, Leap Motion, International Space Station tracker, and littleBits.

Let’s look at a simple example using the Scratch Spotify extension. With this extension, you can input the name of a musician or song into a Scratch programming block, and Scratch will import a 30-second audio clip from Spotify into your Scratch project. Using events and conditionals, you can then animate a character on the screen by making it dance each time a beat is played in the song. You can even go a step further and remix the song by stepping through the beats in a different order.

Now imagine that you want to connect your dance project to the physical world. The BBC along with 29 other partner organizations recently released a device named micro:bit, designed especially for the UK school system. Micro:bit features an accelerometer for tilt sensing, an LED matrix for displaying information, and a few other useful peripherals to get students started building with hardware. The micro:bit Scratch extension exposes some of the device’s capabilities by introducing new programming blocks to interact with the hardware. We even included a “When shaken” block to trigger events each time someone shakes the micro:bit. By adding a few more blocks to your Scratch project, you can make it so that the next beat of a song is only played when the micro:bit is shaken.

By attaching the micro:bit to your body with tape or pipe cleaners, you become the interface for interacting with Scratch. Dance movements can now be translated into musical beats. Dance faster (more shakes) and the beats will be played faster. Stop moving and the song also stops, waiting for that next dance move to be detected.

This is just one example of how I would like to support the merger of tinkering in the physical and digital worlds.

Rather than prescribing specific projects designed to teach the tool, I would like to provide more students with opportunities to use these devices as a medium to explore their own interests. A learner who has an interest in music might naturally discover the Spotify extension. However, it might not be immediately obvious how a physical device like the micro:bit could enhance the interaction. This is why it’s necessary for facilitators, educators, and developers to provide a rich set of examples over many different interest areas. It’s important to show a wide range of possibilities that someone who uses the tools might want to explore.

Below is an example of a scope and sequence for an actual curriculum that was designed to introduce the micro:bit. I have intentionally not linked to the source of this curriculum as my purpose is not to call out or criticize anyone's efforts. In fact, these types of activities can often be found in many traditional computer science programs.

Activities by Week:

1. Making
2. Algorithms
3. Variables
4. Conditionals
5. Iteration
6. Review/Mini-Project
7. Coordinate Grid System
8. Booleans
9. Music and Arrays
10. Bits, Bytes, and Binary
11. Radio
12. Arrays
13. Independent Final Project

The curriculum starts out in a playful way with “Making.” However, by the second week it moves right into “Algorithms.” To me, this could very well scare off many kids who might not have (or haven’t yet discovered) an interest in computer programming. Each week a new technical concept is introduced, along with an accompanying, predefined hands-on project. These “projects” are often structured more like recipes, where students are expected to follow step-by-step instructions. All of this eventually builds into a culminating event during the final week: the “Independent Final Project.” Rather than using this independent project as a way of allowing students to build their knowledge by working on a project they care about, it is used as a figural “finish line” that students are invited to take part in once they have learned all of the necessary skills that they may (or may not) end up even using in the final project.

Instead, I would like to see projects as the main component of the curriculum. Through these projects, students can be invited to learn about a particular skill or strategy when it’s needed to complete the task at hand. After all, is it appropriate that during week 2 all students should be learning about the meaning of  “algorithms”? If students have control over their own learning, they are likely to make deeper connections to ideas and develop a greater sense of agency.

One interesting topic that I have not addressed in this post is evaluation. I believe that learning is done best when it is done in a playful way. However, how do educators evaluate play to see if their students are actually learning? This is a big question. Fortunately a fellow Media Lab Learning Fellow, Anneli Hershman, has published another ML Learning blog post about this very topic, titled “They’re having fun… but are they learning?”. Assessing learning through play is no easy task. Just as open-ended activities have no one, correct, answer, there is no one way to evaluate the effectiveness of learning through play.

I want to challenge us to think about these new electronic platforms as another medium for expression rather than just a gateway to computer science. We should think about them more broadly, not unlike the way we view pencils and paper, markers and crayons, and LEGO bricks and Scratch blocks.

Kreg Hanning is a research assistant in the Lifelong Kindergarten Group and a ML Learning Fellow

This post also appeared on Medium