Summary: experiences of teaching with PocketCode in a public school in Vienna
My report after holding an 4-hour coding workshop using the free/libre and open source (FLOSS) Android apps PocketCode and Pocket Paint for smartphones in a public school in Vienna, followed by 3 days of 3-hour-courses using PocketCode in my own summer school.
While i made several shorter (one hour) coding workshops in public schools using the “PocketCode”, i never before made such a long workshop. I teamed up with media educator and digital artist Christoph Kaindel and we teached together a class of around 20 young 12-year-old students at Neue Mittelschule Sechshauserstraße in Vienna, Austria. The goal of the workshop was to increase the number of CodeWeek EU activities during the year and to gain experience with FLOSS tools for education, as promoted by the Free Software Foundation Europe/Austria.
The NMSi Sechshauserstraße school is more specialized into computer teaching than other schools, but the class of our workshop did not had any coding experience.
In a pre-conference before the workshop with the class teacher (and professional singer!) Daniela Haas, it was decided to focus the coding workshop on those devices the students already own: Android smartphones. As a backup plan, should the smartphones not work, we had the option to move the whole workshop into the schools computer lab and use Scratch.
We learned that the school is equipped with a set of tablet computers, but the tablets (Microsoft Surface) are running a version of Windows and at the time of the workshop, the PocketCode App was only available for Android devices. As the whole PocketCode App is free/libre open source software, versions of PocketCode for Apple and Windows will hopefully created sooner or later by interested coders.
Also in the pre-conference before the workshop, Daniela Haas told us that the class visited the local firefighters station and it was decided that the workshop should be centered around creating a game/app around this topic.
Christop Kaindel discovered that on the PocketCode homepage is not only learning material for teachers but also example games and tutorials, and he was able -without changing a line of code- to convert the game “saving Alice” into a firefighter version by just replacing the sprites and the background.
He also learned that it is possible to connect (some) smartphones to a video projector (beamer).
At the beginning of the workshop, we had to overcome some technical problems with the smartphone-to-beamer connection:
Unfortunately for us, while Christoph's smartphone was able to connect to the beamer in the classroom, his smartphone could not run PocketCode stable enough. His tablet and my smartphone (both could run PocketCode flawless) were unable to connect to the beamer.
Finally, we found a student with a smartphone that could connect to the beamer as well as running PocketCode, so we seated her next to the video projector.
To my pleasant surprise, every student had already installed the PocketCode as well as the Pocket Paint app on their smartphone, save for the few Iphone users. I borrowed my smartphone to one student so that nearly every student had his own coding device. A nasty surprise became apparent as soon as we tried to start with our workshop: As the students come originally from a lot of different countries, their smartphone settings reflected those primary languages, leading to much confusion. While we showed the coding bricks in German language, some kids had to translate on-the-fly into their (smartphones) native language.
Lucky for us, two teachers were present (history teacher Reinhard Marsch was participating in the workshop like a student) so we had a total of 4 adults for 20 students and could assist with translation and other problems in near-realtime.
While i personally prefer to teach coding (especially the programming commands like “if”, “loop” etc.) in English language, the decision to hold the entire workshop in German language was made at the pre-conference, reflecting on the very diverse linguistic backgrounds of the class. For example, i learned that one energetic student was born in Kosovo, translocated to Macedonia , later translocated to Italy and finally arrived in Austria (learning German). His “normal” english school lessons, typically the first foreing language teached for an Austrian kid, are actually his fifth language, at age 12.
The game concept was to control the movement of firefigthers holding a safety sheet by tilting the smartphone left/right. The firefighters should catch people jumping from a burning building. The game concept is as old as the "game and watch" game "fire" from 1980.
I began with explaining (at the blackboard) what a safety sheet is as the kids had not seen such a device at their visit in the fire station.
By restricting the “artwork” to a line (the safety sheet) and a box (the burning house), both hand-drawn with Pocket Paint, i was able to show the necessary coding (of the safety sheet movement by tilting) in the space of around one hour. We then made a break (ignoring the shools standard sheduled breaks) and moved the whole class into the sport room. The idea was that the each student let his friends make three pictures of himself with their smartphone camera:
Of course, the last picture was the most popular among the photographers, quickly named “stirb!” (die!). The jumping (on a mattress) was more popular with the boys and the girls stayed absent for a very long time, before finally some girls also made “jumping” pictures of themselves.
Thanks to the “Pocket Paint” app, it was easy for my colleague Christoph Kaindel to show the students how to make the background of a picture transparent.
Naturally, not every student had the same level of “finger-painting” skill with Pocket Paint using his smartphone. Some unlucky students run into a bug were the smartphone/ refuses to save the edited picture, making the deleted background black instead transparent. The bug was not reproducible, but it happened some times on different smartphones.
Students with less interest on photo-editing used easy-to-draw stick figures instead, with much detail and red color given to the “splash” picture.
Some talented students replaced the background of the painted house with an actual photo of a house and even found pictures of realistic flames to add to the backgrounds, thanks to Pocket Paints “import a picture” (into another picture) feature.
After the sport room break, we continued with coding the guys jumping from the burning building. One minor problem by teaching PocketCode on very diverse smartphones is that the screen resolution (x-axis, y-axis) of every device is different. However, the students did a very good job on adapting the code (we limited the left-right movement of the safety sheet) to the limits of their own device and to their personal taste.
code -> test-> modify cycle become apparent in the student's behavior, without much prompting to do so from the instructors. The students made good use of the always visible “play” button of PocketCode to test out their games. The rapid switching between paying attention (or catching up) to the instructions, coding, fine-tuning and experimenting worked very well for the majority of students; better than i exspected. It was very helpful to have not one but several adults present to provide help for students trailing behind because of dissenting smartphone language settings or because of wrongly moved code blocks.
(please note the the coding was done with PocketCode app using coding blocks and is written here in pseudo-code resembling python
Most students, after having coded the left screen limit for the safety-sheet:
if x-position < -200: set x-position to -200
Could produce the correct coding for the right screen limit “in their mind”, without seeing or hearing it from an instructor:
if x-position > 200: set x-position to 200
The students also quickly pointed out that the control for firefighters was counter-intuitive: if tilting the smartphone to the left, the firefighters moved to the right:
The code was:
if abs( x-position ) < 10: move x-position by "inclination-x"
I corrected the code quickly into:
move x-position by "inclination-x" * -1
The students again pointed out loudly that the movement was now correct (tilting left made the sheet move to the left) but “far too fast”.
At this point i decided to let the 12-year old students do a bit mathematical thinking of their own and asked the audience for proposals of how to make the movement slower. The first answer was to replace the “-1” by “-2”. We did, but the result was that the sheet moved even more faster. Having the class (math) teacher, Daniela Haas, present i transferred the teaching to her. She engaged the whole class mentally, trying to lead them to come up with the correct answer ( -0.5). However, even with me Christoph Kaindel, the history teacher and the math teacher each trying to “provoke” the class into coming up with the correct answer the students proposed answers like “+2” but not the correct one.
While significantly lowering the oxigen level of the room by thinking hard, some students finally guessed “0.5” and tryed it out. At this point the math teacher had already sayed the correct answer (“-0.5”, but not everyone was paying attention) and most students preferred to orient themselve at their peers instead of doing their own research. After “getting” that 0.5 was a workable number the students were able to flip the sign to “-0.5” on their own.
I reflected that spontanious mathematical insight is never easy to inflict into a bunch of children distracted by their smartphones, especially on a hot day just before the summer vacations. On the other hand, by quickly editing the coding blocks and experimenting with different numbers, even if just guessing, the children had the tools for learning in their own hands. No praising teacher is necessary if the code works.
The biggest problem from a teaching point-of-view was the concept that in PocketCode, an object (the falling figure) can have several different skins (photos): in our game, the “before”, “jump” and “splash” skin. Because we tried to explain this concept first verbally by talking about it (instead of only showing it via the video projector step-by-step), many students did not get it right and made 3 different objects instead of one object with 3 different skins.
After some help from the always busy adults finally every student had one correct “jumper” sprite with three different skins. I noted that this very same mistake (one object with “costumes” instead of several objects) also happens if i do workshops using Scratch.
Another thing that was difficult for me while teaching PocketCode (this also shows up when teaching Scratch) was that i had to force myself mentally not to code too procedural: there is no break command in PocketCode to exit a loop.
Instead, the correct way is to have at max one loop per code block group, and it is possible to have several code block groups with one loop for one and the same object running in parallel.
The workshop ended after 4 hours with a playable game (movable firefighters, several randomly falling down jumpers, score counter). Some of the students made use of the photos taken in the sport room, while others sticked to the stick figures. Due to limit of time i was not able to try out Pocket-Code's in-buildt physic engine. A follow-up workshop was sheduled for autumn, and the students dismissed us with a round of applause.
The workshop attracted several adult visitors, among others the school head teacher, Helene Swaton from Vienna's teacher academy and Meral Akin-Hecke, Digital Champion Austria as well as CodeWeek EU Austria.
My impression was that the PocketCode / PocketPaint apps can be a valuable asset for teachers of all directions due to the fact that most students in Austria already have an Android smartphone. It will however take a lot of willing teachers and workshops until using a smartphone during class for coding will be a tool as common as using an pocket calculator for doing math.
I was suprised by the eagerness of the class teacher, Daniela Haas, to finish the game (“let's do this feature also!”) and delighted to hear her observation that students who usually show only limited interest in math participated very activly in the workshop and did come up with their own mathematical insights while coding.
Flickr album with all workshop photos made by Helene Swaton, cc-by-sa licensed:
Each week during the school vacations, i provide with my company spielend-programmieren week-long summer courses for (game)programming. Each course is 3 hours each day, for 5 days.
I continued to experiment with PocketCode and PocketCode during first summer course in July for 3 days before switching over to Python. The setting was different to the pulic school workshop: I had only 4 students, no beamer, no helpers and all students were equally interested and highly motivated in learning to code (i charge money for my courses).
I needed one 3-hour block to teach the same firefighter game as in the school workshop, including time to go outside and take photos of the students as well as of buildings (the flames were to be hand-painted as there was, most inconviently, no burning building in sight and i was hesistant to provide one).
On the second day, i improved the game by adding a real gravity and acceleration (using variables, not the the physic module) for the jumping guys. My students were unwilling to delete the “constant gliding down” guy so we ended up drawing the non-accelarting guy a parachute and finally randomizing before each new jump if the parachute (gliding) or free fall (accelerating) mode is used.
After the first hour of the second day (4th hour), the students were already pursuing their own game ideas with PocketCode. One student experimented with the in-buildt physic engine and on the third day we all coded together a 2-player ball game using the PocketGame physic features.
I hade some troubles getting the in-buildt collision detection code blocks to work like i want: it seems to only work well in combination with the physic module. Hopefully the equivalent of the “touching” command in Scratch will make it's way into PocketCode.
All in all, i was very pleased with the physic coding options of PocketCode, as it makes coding gravity (in all directions!), mass, impulse, collision and friction really smooth.
My biggest personal wish as a teacher and PC user is to use PocketCode on my PC, typing on my keyboard, without the need of swiping with my big fingers on my tiny smartphone (or installing an emulator), but i guess that is what other, PC-based, visual programming languates like Scratch or Beetleblocks are made for.
My students had fun using PocketCode and one already reported of teaching PocketCode to his friends. I will certainly use it especially for students new to coding and i am sure it is a great tool for every teacher, independet of the teached topic.