So some of you may know that this year, after 13 years of being a primary classroom teacher, I've moved into a specialist teaching role as Head of Computing. This has been great for me and I'm really enjoying getting to teach kids all the way from age 4 to 11. With the switch from ICT to Computing and the increased focus on computer science, coding was naturally top of my list of content to develop and ensure progression across each year group. Our school was already in a great position since my predecessor had begun including the use of Scratch, Kodu and other software back in 2011. My aim though was to seek a wider range of software to help deliver unique learning opportunities in each year group. The release of Scratch Jr this summer really couldn't have come at a better time.
For the uninitiated, Scratch Jr is the streamlined app version of the acclaimed visual programming language developed at MIT. It features fewer code blocks and relies on colour and icons rather than worded labels to help students identify the purpose of each block. As such I saw a perfect stepping stone for Year 2 students. It would sit nicely after the use of more guided or level based systems like Kodable and Tynker but before they moved on to the expansive possibilities offered by the full Scratch package. It also offered an excellent medium for introducing, reinforcing and consolidating their understanding of algorithms.
Much has been made in the UK press about the new KS1 curriculum's inclusion of algorithmic comprehension. Are they too young? Is it too early? Quite simply put - no. From the earliest of ages kids develop an understanding of sequence and following steps to complete a task so being afraid of labelling the process or defining it in computational language seemed a little silly to me. I've seen kids in Foundation Stage trained to use the terms digraph and trigrams to better comprehend their phonics so why shouldn't they begin to understand what an algorithm is to get a better grasp on computational logic?
So what I have for you here is a sequence of lesson ideas and resources that I've put together to deliver just that, using Scratch Jr as the medium.
CODE BLOCK INQUIRY
Scratch Jr has fewer blocks than the full program which is great for younger kids. They're grouped by colour into six types - Start, End, Movement, Looks, Sounds and Control. One of the first activities I always suggest when letting kids loose on a new app is what I call Play 2 Learn time - giving students a short period of time to experiment and explore the app independently. They'll figure things out for themselves and the more able will identify themselves naturally, making it a useful AfL task in itself. You'll also end up with fewer questions later in the session and students that do need help can seek it from peers who have found the answers already.
The open-ended nature of Scratch Jr though presented a slightly different challenge in that they could miss out on key functions by only accessing part of the app. As such I planned in a variation on the idea that built around a paired inquiry. I gave each pair just one iPad and a sheet with a table that showed each coloured block category and had space for a label. I modelled the Start blocks (and this label was provided on their sheet) and then challenged them to come up with a single word to label each of the other colours. They were also banned from touching anything but the blocks themselves so that they didn't waste time changing sprites or backdrops etc.
This worked very well and lead to some excellent discussion between the pairs. I moved around the room, questioning their reasoning and pointing out holes in their logic. They found the movement, sound and end blocks easy. The Look blocks label was more challenging and I found they were using terms like "change size" that only represented one of the Look blocks. To help steer their thinking, I eventually gathered them to discuss the difference between recording the word "hi" as a Sound block and using a Look block that showed the word in a speech bubble. We discussed the difference and the senses used for each.
The other block type that they struggled to name were the Control blocks. This was somewhat expected as the blocks don't work in isolation and the concept itself is both more obtuse and more directly linked to programming. So I gave them the first letter of the word they sought and with just that, some groups did actually get it whilst others offered sensible alternatives such as Change.
At the end of the activity, we reviewed their answers and compared to the real concepts. I then gave each kid their own iPad to go an investigate further with the simple (but engaging) purpose of making the cat do something amazing.
So far so good, students can use the app and have developed a simple understanding of the way it allows them to make things happen. Now came the challenge - getting the concept of an algorithm across to them and meshing their understanding of it to what they were doing in Scratch.
We started with a recap from the first session and a run through of the block types. I also quickly introduced the other buttons around the screen eg change the background and add/remove sprites. I connected my iPad to the board via Apple TV so they could watch me build a code string of four blocks (the start flag, move right 5, say hi class, move up 4. Ok, first question: How many things will happen when I press the flag?
Rather than put their hands up, I had them show me on their fingers (thus guiding their answer to less than 5 at the same time.) before revealing the correct answer, we then watched and they counted silently on fingers as the cat animated. We now had our answer of 3 things and I wrote a giant 1,2,3 on an adjacent whiteboard. We then discussed verbs as doing words and elicited the first step's verb as MOVE. They then provided me with the additional information - the variable data that qualified the command ie 5 and right. All those folks that say computer science can't be cross-curricular - that's English and Maths concepts all rolled into one right there!
We repeated this for the second two steps and it was at this point that I introduced the term algorithm for the first time. I had them say it out loud and repeat it after this in unison at every opportunity. I even deliberately said it wrong myself to let them correct me. We discussed instructions and recipes and tied their understanding to algorithms as real world examples of a series of steps that produce a specific result.
Then I unlinked from the Apple TV briefly and dropped in a slightly longer code string without them seeing it. Before connecting again, I switched Scratch into full screen mode. The point of this was that this second time, they would only see the animation and not the underlying code. Their task was essentially the same but they had to reverse engineer the algorithm from the final result. I likened it to taking a Lego model apart.
They followed a similar process as before - they counted the number of actions on their fingers as I showed the animation several times. They then discussed in pairs what they thought the answer was before offering their final decision. Universally correct, we then laid out the sequence on the whiteboard, step by step. I drew attention to the fact that they didn't know the exact numerical values of the movements etc but they could estimate based on the result. This lead neatly into their independent task:
I switched to a pre-made animation of a camel walking to the middle of a desert screen, with my name in the corner, saying "Camels live in the desert" then walking to the far side of the screen. Simple, accessible and also linked to their current topic of animals and habitats. This was shown to them like the last one, ie in full screen mode and without them seeing the actual code. They each worked independently to try and recreate the animation by breaking the end product back down into the requisite steps. I provided a small group of weaker students (identified during the prior session) with adult support and the middle ability group took an annotated screengrab of the Scratch Jr interface to support them in finding things like adding their name etc.
This was where the trail and error nature of programming came into play as many identified the steps and the required blocks but didn't make the camel walk as far as mine did. As a class we discussed the fact that they couldn't see my numbers but they COULD see where the camel started, paused to speak and ended up. This was enough for most to tinker with the digits until they were more closely aligned with my own.
As an extension task I showed the first couple to finish how to add a second page and use the broadcast style ending block to move on to it. They then added a new creature in a new habitat and were allowed to animate it however they wished (in a similar style.) As more kids finished, I directed them to those I'd taught and they began peer teaching them, allowing me more time to consolidate the initial concept with the weaker students.
ALGORITHMS, ALGORITHMS, ALGORITHMS
(AND REPEAT BLOCKS!)
The next session was were I introduced the repeat block. I started by adding a ridiculously long and repetitive code string to Scratch Jr that stretched the length of the page. We discussed why this was inefficient and compared it to using times tables in Maths for something like 8 x 10 rather than doing 8+8+8+8+8+8+8+8+8+8. I modelled using the repeat/loop block to simplify the code and then the games began.
I'd made a set of 12 algorithms, written in sentences, that grew progressively harder and all required a repeat block. They were labelled A - L and I used traffic light AfL colours to key me in to the three starting points I'd set for various ability levels. Their challenge was to race to reach the special final purple one L. I reminded them that each algorithm needed to be shorter in code form so they would have to use a repeat block. The challenges progressed from simple repetition of two steps to repetition of steps and then an additional action etc.
THE ALGORITHM WRITING CHALLENGE
The final session in the sequence began with a little algorithm writing challenge. I'd chosen three of the sample projects (Farm, Under The Sea and Animal Race) and screengrabbed images of the code string for each sprite. As I was aiming the Farm samples at my less confident coders, I decided not to include the second string that made each animal noise.
I presented these blocks on a sheet with space for the kids to write out the algorithm that each string represented. In pairs they had to complete this challenge in ten minutes. The most confident kids took Animal Race which includes broadcast commands, so I held them back at the start of the challenge to provide some additional input (plus essentially stagger the starting times)
Upon completion, I then gave them IPads and showed them where the actual projects could be found in Scratch Jr so they could self-assess. This lead to the final part of this lesson sequence - creating their own project.
CROSS CURRICULAR CODING
Scratch is by far the easiest software to enable cross-curricular links to be made to other areas of learning in my opinion. Computer science doesn't have to stand apart from other areas of the curriculum. Using the main Scratch 2.0 web tool, I've recently produced Viking quizzes with Year 4 as a part of a term-lomg study of the Norsemen as well as Welcome to the UAE interactives with Year 6 that were pitched as a service for Emirates airport lounges. In both cases, the students were definitely more engaged as the subject matter related to what they were learning about outside of my lessons. All it took was a little extra time and thought.
My Year 2’s have been studying animals and in the week of the final session on Scratch Jr, had visited an Arabian Wildlife Centre. So their final project was to make an alternate version of their previous sample project (Farm, Animal Race etc) but with a UAE theme. We started by adding the desert backdrop and then they discussed which of the animal sprites were suitable (the camel, the snake and so on.) I showed them how to quickly recolour certain animals to make them more appropriate - a blue lizard looks wrong but recoloured to a sandy shade and it became far more like the geckos that you see on a daily basis here.
The code itself was to be based on the sample projects, meaning that they could use their sheets from the algorithm writing challenge for prompts and guidance in its structure - they are only Year 2 after all! I took the Animal Race kids and showed them how to add their face to one of the human sprites so that they could actually be in their presentation as the one who officiated the race. They then showed this to those from the other groups who finished so that they too could add themselves in to their programs and introduce it.
WAS IT ALL WORTH IT?
Short answer - yes, definitely. I now have a group of kids still in KS1 that all understand what algorithms are, have had experience reading and writing them, have an understanding of the Scratch interface (setting them up nicely for Scratch 2.0 work in Year 3) and have had immense fun coding for the first time. Many downloaded the app at home and started developing their own projects too.
Ok, that's all folks. I hope some of you found these concepts useful. If you liked the ideas then give me a shout out on Twitter @iPadEducatorsAE. You can also follow Scratch Jr with @ScratchJrTeam for their own updates and check out the Scratch Jr website for some more great resources.
Til next time,