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.

Registration: https://docs.google.com/forms/d/e/1FAIpQLSe2NzAX1VUKRhgIvSfALcBrk0WZRXvSepNc6HWADuqMs9j6fg/viewform?usp=sf_link

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!

 

 

Facing the Challenges of the new Digital Technologies Curriculum

As schools around Australia prepare for the implementation of the new Digital Technologies curriculum, teachers are starting to come to terms with some difficult new terminology, content, and skills. While Western Australian schools have been given two years to implement a slightly more user friendly version of the national Digital Technologies Curriculum, we are facing a number of significant challenges in common with our interstate counterparts.

Challenge 1: Explaining the difference between Digital Technologies and ICT

There is a common misconception that ICT and Digital Technologies are the same, and teachers who haven’t read the curriculum are in for a shock.

While ICT focuses on the use of technology for learning, Digital Technologies focuses on empowering students to be creators, producers, and developers of technologies through the development of computational thinking. 

For example, students use ICT skills when they make movies, podcasts, and digital stories. They develop understandings of digital technologies when, for example, they explore the role of hardware and software in their smartphones;  and when they use computational thinking to code digital solutions to problems – e..g. programming a robot.

A good way of defining the difference is comparing ICT General Capabilities to Literacy Skills, and Digital Technologies to the English learning area.


Challenge  2:  To integrate, or isolate, that is the question.

At the start of 2015, we introduced major changes at my school. In line with the purpose and goals of the ICT General Capabilities in the Australian Curriculum, classroom teachers became responsible for integrating ICT across the curriculum. There were two reasons for this change. Firstly, we believed that learning with ICT should not be isolated in the computer lab, segregated from the rest of the curriculum. Secondly, building our school’s reputation for high-quality ICT and digital technologies programs will rely on the expertise of every member of the school community, from the Principal down. Can schools really afford to reply on one expert? What happens when they leave …?

In our school, many teachers are exploring the power and relevance of ICT and digital technologies to their classroom teaching. I’ve watched teachers become the most excited learners in the room, empowering their students’ creativity and problem solving through digital storytelling, coding, and robotics – and starting to see authentic connections to maths and literacy.

My coaching experiences this year, and discussions with teachers (through Twitter and ISTE), raises an important question in regards to the implementation of the Digital Technologies curriculum.

What is the point of teaching students to collaborate, think computationally, and solve real world problems in one lesson a week outside of everyday classroom learning?

Yes, this may be appropriate for a technologies extension program, but surely these skills are important and applicable for all students, across a range of learning areas?


Challenge 3:  Supporting Teachers’ Engagement with Digital Technologies

The implementation and integration of the Digital Technologies curriculum will be a steep learning curve for most teachers. Some of the concepts in the new curriculum are scarily new, especially the parts about binary language and coding. Yet, others are familiar. For example, we use algorithms for problem solving, cooking, and giving directions / instructions in English , Science, and Maths. We use spreadsheets for collecting and making sense of data in Maths and Geography. These learning activities provide an authentic, relevant context for the integration of digital technologies.

As indicated by the WA curriculum writers, it makes sense to integrate Digital Technologies at the primary level – both through classroom learning activities, and through your library makerspace (if you are lucky enough to have one). If we learned anything from last year; however, it is that teachers are going to need a lot of support, both through collaborative PLCs and resourcing, to become comfortable teaching this new curriculum.

At my school, I have been working as a part-time teacher coach, supporting teachers’ integration of ICT and digital technologies in the classroom. This approach is most empowering for those teachers seeking help to develop their relatively limited technology skills, and those keen to push pedagogical and technological boundaries. I know that most schools can’t afford to fund this kind of role, but I would suggest that teacher relief for collaborative planning, classroom observation, and targeted professional development in Digital Technologies would be money well spent. I’d start by developing the skills and capabilities of a small group of interested teachers across a range of year levels, and then giving them time and space to share their learning with their colleagues. I am hoping to do this in my own school this year – it is just too hard to lead this change process alone.


Challenge 4:  Finding resources and fellow pathfinders.

As we begin our Digital Technologies journey, I take a great deal of comfort in the knowledge that we’re not alone. Around the country, and around the world, teachers are developing resources, activities, and tools that we can adapt for use in our school.

As schools begin their familiarisation and planning with the Digital Technologies Curriculum, it is important to consider what tools and resources they already have available, e.g. iPads; and plan for strategic investment in edtech tools which add value to the curriculum, such as BeeBots, Dash (Wonder Workshop), Sphero, and MakeyMakey. I’d add LEGO EV3 robotics if you can afford them!

For developing skills in computational thinking and coding, there are a range of free resources and communities available online, including:

If you’re interested in developing your understanding of the curriculum, or if like me, you’ve been tasked with leading its implementation, I’d highly recommend connecting with your local ICT subject association, joining Twitter, and exploring the CSER Digital Technologies MOOC. With the rest of Australia (except NSW) implementing this change from 2017 (2018 in WA), things are about to get really interesting!


 I’m learning as I go, and I don’t have all the answers.

Leading the familiarisation and implementation of the new Digital Technologies Curriculum in my school is probably the biggest challenge I’ve faced in my career to date; and I’ve learned some valuable lessons.

You don’t need to have all the answers when you’re starting out. If you can develop a basic understanding of the concepts and tools, don’t be afraid to learn and experiment alongside your students. It took me months to overcome my fear of learning in front of my students and colleagues, but I soon discovered that the more I threw at our girls, the more they came back and surprised me..


 Leading curriculum change isn’t easy, but its worth fighting for.

You will treasure those little moments … Watching a girl who struggles in class successfully code a robot for the first time . Noticing that a group of students have continued the Hour of Code 2015 activities independently through their Christmas holidays. That time I sat down with a Year 5 student and asked her how to explain how she did things I didn’t know were possible with Scratch.

At the end of the day, my students are the reason I teach.

Demystifying Coding and Programming – Just Scratchin’ Around

Scratch_cat_large

Jenny Ashby @jjash may not know it, but her Sydney #slide2learn session on Beebots and coding gave me the push I needed to take a risk, and experiment with Scratch programming in Years 4 and 5 in late 2014.

Openly acknowledging in class that I had next to no idea of how Scratch worked, and what it could do, I set my students a challenge to create a game, or tell a story. With the help of YouTube tutorials, older siblings, and coding enthusiasts amongst their classmates, the girls merrily set to work planning, problem solving, and coding their projects; and they were only too happy to teach me in the process!

2014-10-31 12.04.40

The Task

Challenge 1:

Use Scratch to tell a simple story which includes at least one talking character (sprite), and at least two settings or backgrounds.

Challenge 2:

Create a simple game where the user or player has to choose a key on their keyboard to make the sprite move or perform an action. This game could be a maze, a guessing game, or your own idea. It needs to include at least one Sprite (object/character), and a background.

Self Assessment Criteria

I have:

  • Storyboarded what my story / game will look like, and what will happen.
  • Created a simple story or game using Scratch
  • Included at least one Sprite and background
  • Used code blocks to require user/player action – e.g. IF the player clicks their mouse or presses the A key, THEN ….

IMG_8230

Some Results

Arcaine

Press ‘s’ to start, then use arrow keys as per in-game instructions.

Super Grandma!

Press the following keys to progress the dialogue: a, c, e, r, q.

Ask Katy Perry

Start by clicking on the green flag.

Fun Maze (Year 4)

Click on the green flag to start, then use your arrow keys to navigate.

What did we learn?

2014-11-20 14.24.00

Introducing Scratch programming to my students was a huge professional risk, as to the best of my knowledge, it had not been formally taught at the school before. It was also the first time I had ever attempted to run a coding/programming project, something which I wouldn’t have dreamed of trying before #slide2learn.

Through this project, I learnt a great deal about the power of play – allowing students to explore, experiment, tinker, and collaboratively solve problems as they pursued their coding projects. I was surprised by the level of student engagement – both in, and outside of class. Many went home to ask their older brothers and sisters for help and advice in coding their projects! I was also really impressed with the power of peer teaching and support in class, as we even brought some Year 4 students into a Year 5 class to explain how they used a particular Scratch tool !

Next time I run this, I intend to more formally stress the need the storyboard and planning aspect of the project, and include some higher level coding skills in the assessment criteria (drawing upon the Australian Digital Technologies Curriculum). I’d also like to try and provide better summative feedback to students, beyond the whole class discussion and reflection sessions we ran last year. The peer teaching and problem solving approach worked very well for most students, encouraging them to think and learn from eachother.

Later in 2015, I am hoping to introduce Beebots and coding apps into Early Childhood maths / procedural writing, and explore how to integrate Scratch programming into other learning areas in upper primary. We are at the very early stages of teaching coding / programming at our school, but I am very curious to see where this little experiment takes us over the next few years.