Last year at this time, I was trying not to think about Kindergarteners. I was still teaching 9th grade English and I had just accepted a job teaching technology to K-5. I was excited about the challenge, and I knew I had bitten off more than I could chew.
As I was developing the tech curriculum, I had the challenge of teaching programming or at least computational thinking at each grade level K-5. Our school is mid pivot in technology. We are in our second year of a 1:2 iPad program in the middle school, this is our first year of having a cart of iPads available for elementary, and this is our last year of having 2 labs of PC's for the students to use, next year we will only have one lab. Knowing this, I wanted to design a programming scope and sequence that mostly used tablet-based tools. I was really excited when I was introduced to Daisy the Dinosaur and Hopscotch, both from Hopscotch technologies, a great app company.
Daisy the Dinosaur and Hopscotch both use visual blocks to represent commands. I first saw this programming interface with MITs App Inventor and Scratch.
Hopscotch
This approach to syntax is physical, like puzzle pieces. The commands fit together if they work together. The commands are also grouped into color coded families. This approach to programming is great for kids, color helps them navigate, and the physical syntax guides them towards success. From a teacher perspective, it is much easier to find the errors in this physical syntax, I don't know how many missing semicolons I could find in a class period. With these apps, I was confident I had a good entry point for grades 1 and 2. I was working with a kindergartner during coding club and I asked her to find the block that ended with the word "up." Now in my defense, I thought it was a likely sight word and chances were pretty good she knew it. She was incredulous, "I can't read!" So here was my challenge, can you teach programming to students who do not yet read? Of course, I look beyond this challenge and see the next: Can you use programming to support and deliver literacy instruction?
I am happy to report that, much to my own surprise, the first challenge has been met. There are many ways to get pre reading students to engage in meaningful coding challenges that develop computational thinking. My short list includes Kodable, Lego Fix the Factory, and Bee Bots. With the Tynker app and the planned release of Scratch Jr, it seems like there are new platforms to support young coding all the time. As a critical and reflective teacher, I know any of these tools is only as good as the lesson it supports.
As a push-in tech teacher, I work closely with the classroom teachers to create lessons which dovetail with and support their lessons. Real world programming with students or with robots can create great opportunities for content integration. My first graders program a robot to fly to the planets in order . I use the content as the surface the robot operates on. This format also creates a social learning opportunities. It is challenging for a group of 6 students to work on a robot, I plan for four on a robot. So in many ways technology class is a communication workshop and a crash course in ninja level sharing. I am grateful my teachers stay to help me out. We often have three adults in the room with 24 kids and six robots .
Elements of programming that support pre readers
Sequence
The concept of code (written language)
Cause and effect
Counting
Planning
Left to right reading
Problem solving
How Programming Supports Social Learning My school values social and emotional growth, and it is an important part of all classes, tech included. It you have never handed out devices to students, you may not know the almost universal body language of pulling the device close in and turning away from other students.
The Power of Pairs Until my students really understand an app, I like to have them share an iPad. We always have to talk about how to talk to your partner about sharing and offering help. This is also a point I really appreciate my classroom teacher's knowledge of the students and ask them to pair the kids up. I have heard one teacher refer to these partners as elbow to elbow and knee to knee. The IPad shifts left and right of center for the whole period. While it is hard to share devices like this, I see a real learning benefit in sharing. Most students will stay tuned in to what their partner is doing when they are waiting for their turn. As they watch, they mentally rehearse and problem solve, building their understanding for their next turn.
When we program robots we work in groups of four students to each robot. This can be challenging and a little chaotic. When we take the time to model and rehearse some group communication skills and sentence stems the students seem to be more successful. When we give each student a specific role (programmer, input engineer, debugger, recorder) some of the students are more successful. In these roles the programmer is in charge of writing the program to do this she lays out the programming command cards left to right, the input engineer presses the buttons on the robot to input the program from the cards, the debugger watches the robot execute the program to check for errors or locate any mistakes in the program.
From Pairs to Parallel Play
The first time we explore an app we do so in pairs, but once the students seem comfortable with the app we graduate them to working individually. One delightful surprise this year was students asking if they could move their chairs together to work side by side even though they had their own iPad.
Keeping Learning at the Center
One of the challenges of programming with robots and apps is that they are designed to look like toys and games. My goal is to structure an interaction that is thoughtful enough that the students really build their understanding of programming and robotics. With the robots we have you program directly onto the robot using the buttons on the top. I ask my students to use command cards to plan out their programs. The students want to physically steer the bot around and input commands as needed. They object, "but I can do all that in my head." Without a physical record of the commands, there is no way to debug, edit, or even audit the program as it runs. In this case the cards are the critical difference between learning and play.
To App or to Bot, that is the question
Whether it is nobler in the mind to work in groups or alone, to take to desks or abandon them into a sea of learning, these are the choices that wake teachers up at night. When bringing programming to young students should you use an app or a robot? This decision might be based on what you have available to your class. In a tablet rich environment it makes sense to focus on apps, but if you are going to buy some tech which will give you the most return? Here is a quick side by side. I like Kodable because it is another great learning resource I have lodged on my cart of iPads. I like the Bee bots as I can make some great connections to content.
Kodable Pro
Structured interaction
Built in tutorials
Graduating complexity
Isolated from class content
Cost per unit 6.99 per license (can be installed on up to 10 devices)
Bee Bots
Strong content integration
Stand alone unit, no device needed
Simple interface
Limited complexity
Cost per unit $90.
It seems like the bee bots could be(e) shared effectively between several classes. A good lesson with the robots requires a good deal of prep. This can mean laminating goal cards, creating command cards, building maps for the bots to navigate and even downloading custom jackets to turn the bees into rockets when needed. There is an amazing resource site for this called Primary Treasure chest, thanks to Vicky Sedgwick for sending me that link.
