Returning for #iste17, a conference like no other

Well, in less than four weeks time, I’ll be traveling via Auckland on a 16 700 km journey to San Antonio, Texas. I will be presenting on my students’ learning adventures with Scratch game design and FIRST LEGO League robotics at the International Society for Technology Education Conference. Following ISTE, I’ll be embarking on my most ambitious journey to date, visiting Dallas / Fort Worth, Chicago, Denver, Glenwood Springs, Sacramento, and San Francisco over the course of four weeks.

ISTE15 in Philadelphia, where I took home an ISTE Emerging Leader Award, feels like yesterday. The memories of the people I met, the places I went, and the meetups with locals in Philadelphia, Virginia and NYC are very dear to me. If you plan to be at the conference. or live in/near the cities I’ll be exploring, please let me know. I’m always happy to catch up with Twitter folk, especially if you share my love of coffee, conversation, and/or photography. Especially coffee 🙂

 

My ISTE Presentations

FIRST LEGO League Robotics – Coaches’ Corner

Poster session with Aaron Maurer and Louise Morgan

Tuesday, June 27, 1:15–3:15 pm
HBGCC Tower View Lobby, Table 34

Are you interested in LEGO Mindstorms robotics, engineering, and computational thinking? Come along and meet three robotics coaches from Australia and the United States, and learn how you could empower your students’ STEM learning through the international FIRST LEGO League robotics competition (http://www.firstinspires.org/robotics/fll)

 

The Scratch Game Design Challenge (BYOD)

Wednesday, June 28, 1:00–2:00 pm
HBGCC 006AB

Michael Graffin  
Find out how to extend coding and computer science lessons beyond code.org by using Scratch to empower students to collaborate, problem solve, and share their learning through the creation of animated stories and computer games.

 

Scratch Game Design in Chicago, IL

I will be repeating my ISTE Scratch Game Design workshop in Chicago. If you live in the area, please come along to say hello! All welcome 🙂

Thursday, July 6, 10am12pm

Archdiocese of Chicago
Quigley Center, 835 N Rush St.

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

JavaScript source code ransomware

Creative Commons License Christiaan Colen via Compfight

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!