Understanding How Kids Learn Programming in Scratch
We challenged kids to discover how to use code blocks, but also how to make four cool projects with specific requirements that encouraged understanding targeted programming concepts. But we didn’t tell them that! Instead, we had them take their awesome ideas, and program them into cool projects. Then we challenged them to Level Up those projects to make them even better. We collected data on their projects and learning to study their trajectories of programming. Below you will find the many different ways that we found to measure how kids learn programming.
Seed is your jumping off point, building the foundation for your project. It helps you define your idea, vision and audience.
How do kids learn computer science, especially in places that are not the classroom?
How can we study how well they are learning those programming concepts?
These two questions helped us design summer programming camps where we were able to teach kids how to make animated stories, music videos, and video games, all by programming in Scratch. During these camps, we took lots of notes, hours of video, saved many projects in various stages, and also received backend programming data from Scratch at MIT (Massachusetts Institute of Technology). After the Scratch camps, our team spent hours combing through and organizing these data, spotting connections, and writing up our findings to submit to academic journals.
We wanted to develop a rigorous way to study kids' learning of computer science in informal environments, i.e., outside of the classroom. By collecting data from mulitple sources (including observational notes, back-end data including over 30,000 snapshots of kids programs in progress, as well as their finished programs), could we better understand the challenges and processes of learning among novices?
Many experts agree that learning computational thinking skills should be a high priority in what we are teaching kids these days. But getting kids into programming takes a lot more than offering the same "watch me and follow along" methods that we have been using. What parts do kids have a tough time grasping? These new programmers might not realize that to get a sprite to begin in the same place everytime they have to add that into their code (initialization). How many times, or over what time period, does it take for kids to pick up on a presented concept? Do kids "pick-up" programming differently than adults do, and what can we do as educators to address that?
Encouraging children to become involved in computer science can be challenging, despite the fact that these skills are in-demand and represent a new and key form of literacy in our world today. Despite the importance of computer science education and growing initiatives designed to bring these skills to a broader range of learners, we know very little about the learning of novice programmers. We hoped that our study could address this gap and begin to create indicators that computer science educators could use to understand the progress of kids learning computing.
There has been research done on kids programming in Scratch before. Much of it is limited to the basic questions of "Are kids learning programming with Scratch?" or "Do kids understand these computational concepts after 50 hours of exploring with Scratch code blocks and seeing other users' projects?" Our questions go another step deeper than what is already out there in research, by looking at when kids start to pick up on concepts in a scaffolded learning environment, and how often they use what they have learned after they learn a new concept.
For context, we are using Scratch to teach 9-14 year olds how to program. Scratch is a block-based visual langage that was developed at MIT. These blocks can be clicked together like Legos, which helps avoid frustrating beginner programming errors, like spelling mistakes and missed semi-colons.
We designed and led three, week-long day camps over the summer of 2014 to teach Scratch to kids who had signed up in association with the local 4-H program. We had them make projects that had specific requirements that had to be met, but where each kid was able to make a project that had to do with their interests and hobbies. Four days were for new projects, and the last day was set aside for kids to finish any projects they wanted to, and then set up their computer screens for a Family Invitational Gallery Stroll (public presentation of work). At the end of each camp, we had a ceremony for the kids and their families, complete with completion certificates and Scratch Camp nicknames.
Sprout is the story of your project, its process and evolution. It illustrates how the work's getting done.
Although our project has Sprouted, at the moment we don't have content for this area. Check out Bloom to see our work!
Bloom is a celebration of your end-product, a reflection back on your process and a look forward into the future.
Our main goal was to study how kids learn programming with Scratch. We wanted to show that programming projects designed with constructionist principles had enough rigor to teach kids what they needed to know to make successful projects. Through direct observation, lots of notes, and a heap of data analysis, we have outlined code measurements that can help teachers track how their students are learning to program. Overall, there are 61 specific code block uses that we have outlined. They can be separated into these programming concepts:
Specific Measure Examples
We have completed an exhuastive list that includes all 61 measures. This list includes what the measure is, why we are looking at it, and what the charted graph line for each measure should look like. It is several pages long, and you can access it here:
Below you will find specific examples of measures.
What happens when a sprite’s location is not initialized? When you play the project again, the sprite is in the wrong place! This is a pretty obvious bug for adults to understand, they simply add a location block for the sprite to start at. This Position Initialization is harder for kids to remember. Our data have shown us that even by the fourth day of camp more than 75% of kids still do not always remember to initialize their sprites. This was even after being constantly reminded to “Tell the sprite where it needs to start”.
This Missing Initialization graph shows three measures that track missing initializations: Missing Position Initialization, Missing Show/Hide Initialization, and Missing Scene Initialization. This graph is for the same camper that made the Bloody Kitty Heads game from below, and that corresponds to the Day 4 block on this graph.
The length of the “bars” that appear on the measure lines show the length of time that it took for the student to realize and figure out how to fix the initialization bugs in their code.
Short “bars” show quick initialization debugging
Long “bars” show that the camper is not catching their bugs quickly
If the bar stops at the dashed line for the next day block, the camper didn’t catch the bug before starting on the next project
If the bar goes through the day line, the student may be working on the same project from before
The short green bar at the beginning of the graph shows that the camper had a sprite that did not have a starting position coded. The shortness of the bar shows that she found the bug in her code, and fixed it by adding a beginning position block into her sprite’s code.
The long pink bar shows that she added a scene, but never set which scene should start first. In this case, it is because after adding the one scene to the stage, she never changed it in the code. It never needed the initialization.
On Day 4, the graph looks like this camper has lots of bugs. But if you play her project below which this portion of the graph correlates to, you can see that it doesn’t matter where the kitty head sprites start or where the basket starts. Other sprites never move, like the Lives hearts.
Many times the Missing Initialization measures can show when students have position bugs, and when they fix them. But, Initialization may not always be necessary, as shown in Examples 2 and 3.
Repeat Loop Use
Multiple Green Flags
Here is one playable example of the programming accomplished by one camper over one day. This was the fourth day of the Scratch camp, and the fourth project, Video Game. Campers were given several example games to play and hack, and then were given the option to remix one of the options, or completely make their own Video Game. This camper remixed our example, and she added blood and gore to the sprites, enabling her to include her own interests.
Use the arrow keys to catch the bloody kitty heads!
If you would like to see into the Scratch code for this example, go here: