Starting from @Scratch: (Re)thinking visual programming

Several years ago, I started my exploration of Scratch coding with a group of highly motivated students who were happy to dive in, figure out how it worked, and answer my questions – which typically started with “How on earth did you do …?” We went on a learning journey together, and considering that I didn’t really know what I was doing, it is quite surprising how far we managed to travel.

Fast forward to 2017, the first year that we had to assess and formally report on our students’ understanding of, and application of visual programming. I spent my Christmas holidays teaching myself Scratch, drawing upon tutorials published by MakeBlock, and any resources I could find on the Internet. I delved into event blocks, loops, IF/THEN branching, and tried to work out which Scratch skills should be taught at each year level. I was fairly sure I understood the content; and based on my experiences teaching Scratch in our after-school/lunchtime clubs, I thought I knew how to teach it. The assessment was still a grey area, but that wasn’t going to stop me diving in and attempting to teach Scratch coding to all students from Years 4-6 for the first time.

Teaching Scratch Game Design

As part of my new STEM and robotics teaching role, I have been teaching a Scratch game design course in Year 6. Term 1 proved to be rather challenging. The sheer scope of students’ skills and past exposure to Scratch, ranging from absolute beginner to extremely advanced, were hard to differentiate for. In addition, this was the first time many of these students experienced my approach to teaching Scratch, which relied heavily on the use of online learning videos and tutorials shared via YouTube and Google Classroom. While some students produced some extraordinary games like the one above, there was signficant room for improvement.

For the Term 2 unit, I decided to explicitly teach and demonstrate some Scratch skills, running 5-10 minute mini lessons and demonstrations of the use of event blocks, loops, and IF/THEN branching. Students then had opportunities to delve further, using differentiated Scratch tutorial cards to learn more about Scratch. During one of these sessions, a question started to arise.

When designing a maze game, students need to work out how to control their character sprite movements using the WASD and/or arrow keys. I was pointing the girls in the general direction of using IF/THEN branching blocks (aka conditionals) for their arrow key controls, but we kept encountering problems … Firstly, the IF/THEN block ran once when triggered by an event block; and secondly, the colour sensing (for maze walls) didn’t seem to work properly.

Problem solved?

Putting everything in a forever loop seemed to work. It used a single script, and in my mind at least, was a “logical” solution. Yet, I was struggling to understand, let alone explain, this question: Why did the IF/THEN blocks have to be in a forever loop in order to work?”

Uncovering a fundamental misunderstanding …

Standing on the train station platform one morning, I found myself revisiting, and pondering this question. It occurred to me that I actually knew someone in the programming industry who might actually be able to provide an answer in terms I could understand.

My longtime friend and programming expert can be best described as a maths geek with an incredibly logical mind. He specialises in developing software controlling LED signs, such as animated city carpark signs which tell you how many bays remain, and bus stand information displays somewhere in New Zealand. To this day, I still enjoy teasing him when his little dots don’t work, including the time his code was used to display terrible Christmas decorations on a city carpark sign. Anyway, I digress …

As I hopped on the train, my friend replied to my Twitter message, kindly pointing out that “IF/THEN branches did NOT need to be in any kind of loop in order to work”. After reviewing his suggested reading links on the Scratch wiki, it became apparent that I had a serious gap in my understanding of the underlying logic and structures of the Scratch visual programming language.

Oops.

A whirlwind professional learning experience

For all my research and experimentation with Scratch over the years, I’d missed something that should have been blindingly obvious. Scratch reflects the logic and syntax of a formal, event-based programming languages, and includes events, and structures such as branching (IF/THEN conditionals) and repeat loops. To my chagrin, I’d been seriously muddling up my teaching of events and IF/THEN branching.

Meeting up with my friend for coffee a few days later, I began what was to become a whirlwind professional learning experience. We spent hours talking through programming concepts, examining and evaluating example Scratch projects, and discussing the best way to introduce and develop students’ visual programming skills at different year levels. The conversations continued via Twitter for weeks, and I’m just starting to feel like I can comprehend and apply what I’ve learned.

Visual programming and formal written programming languages are machine languages

Formal languages are designed so that applications written in those languages can run on devices such as desktop and laptop computers, tablets and smartphones. Each formal language has its own syntax (similar to a natural language’s grammar), which include set programming structures and rules which define how the computer reads and executes tasks. A computer is a machine, which only understands your typed code if you use the exact words, logical structures (e.g. IF this condition is met, THEN do this), and punctuation that conform to the syntax of that language. Scratch is a formal language that is presented visually rather than as text, though text can be used in some of its structures.

In terms of Scratch, an event could be a key press, a mouse movement/click, or the broadcast/receipt of a message. Whenever an event is triggered, it activates a script, a programmed sequence of actions. For example, whenever the right arrow key is pressed, the sprite will move 10 steps along the x axis (to the right). Branching (IF/THEN conditionals) are used for a different purpose. They change the sequence of the script or instructions depending on whether a condition is TRUE/FALSE. Branching is especially useful for sensing walls, monsters, traps, and other sprites in Scratch game design.

Rethinking how I teach visual programming

While the original solution involving a forever loop does work, it is not considered to be good practice because of the demands that it can place on the device. While it isn’t the end of the world that my young students have been using a forever loop as a container for IF/THEN branching to control user input via the arrow keys, it is important that they understand the logic, structures, and recommended techniques of the language they are working with – especially if they choose to explore other formal languages, such as Java and/or Python, in their secondary schooling.

There is no one right way to write a program, so we need to try and teach our students to create code which is logical, structured, easy to implement, and which addresses the user’s needs.

So this is a simple example of the recommended programming technique for controlling a sprite with your arrow keys, with colour sensing branching.

Drawing some conclusions

Firstly, I am extremely fortunate to have a friend with programming expertise and experience teaching adult education. Without his patient assistance, I’d still be stuck teaching the same flawed thinking and approach for the foreseeable future

Secondly, it has become really obvious that in order to teach visual programming effectively, I need to develop my understanding of the logic and syntax structures of the programming languages I work with. While it isn’t necessarily a pre-requisite for introducing and experimenting with Scratch, it really, seriously pays to understand the concepts that students are exposed to as they tinker, problem solve, and create digital solutions with code.

Developing my professional knowledge and expertise with Scratch has taken me years, and I still find myself filling in the gaps – including the ones I didn’t know I had! One of my professional growth goals this year was to develop my understanding of how to effectively teach, assess, and support my students’ learning in visual programming, with a view to eventually exploring formal written programming languages.

Ironically, I wasn’t expecting to have to go back to the very beginning, and start from Scratch!