Dr. Stager or; How I Learned to Stop Worrying and Love Scratch
I am going to be honest, today I was found out. I understand the place and power of programming. However, I was one of those people who had overlooked Scratch as somehow being ‘easy’. One of those people how felt that it was a good place to start, to explore and remix, but not really worthy of real work. As I listened to Gary S. Stager, Ph.D. speak about making I realised that I had been missing a trick all along. What matters is not how it looks or even how it works, but rather what it allows you to do — and it allows you to do a lot. This experience was no more obvious than when I was tinkering with Lego WeDo.
Having had some experience with Lego Mindstorms, I was interested in the difference to WeDo. The first thing that stood out was that there is just one motor and two sensors: motion and tilt. While to operate it you need to be connected to a computer (or in the modern version, an iPad using apps like Tynker). Although there were instructions provided, I was more interested in how it all actually worked. I therefore decided to try and make a simple propeller that would be controlled by tilting.
My first step was to connect the WeDo to my computer. Unlike Lego Mindstorm, WeDo allows both its own software or Scratch. After searching around, I made a simple line of code that demonstrated how the two sensors worked. This involved developing an appreciation for the values produced by the senses, as well as blocks required to get them to work.
Once I did this, I then wondered if I could use the tilt mechanism to not only turn it on and off, but also control the direction. After testing a range of options, Richard Olsen helped out by suggesting that I create a loop with two different parameters, where if the tilt was above 2 then it would go one direction, while if it were below 2 it would go the other way. This worked, but it was very messy. After struggling to determine whether it was actually turning, I added a yellow brick to the makeshift propeller in order to make it clearer. Although we could get the propeller turning, controlling it was a little haphazard.
After some reflection, it was identified that one of the issues was the time on the motor. We therefore adjusted this from 1 second to 0.1 second. This provided precision, but was at the expense of speed.
It was thought that maybe a part of the problem was that there was too much going on in one line of code. So after some discussion from others, we split the program into two parallel lines. This solved everything, providing both speed and precision.
As I moved around the different stations throughout the day, so many devices devised were based around the use of block code. Whether it be Dash and Dot or the Hummingbird kit. One of the points that Stager makes again and again is that programming itself has not dramatically changed over the last thirty years. What matters is what we can do with it and more importantly, how we go about it.
School, especially in science and math classes, typically only honours one type of learning and problem- solving approach, the traditional analytical step-by-step model. Other more non-linear, more collaborative, or more artistic problem-solving styles are often dismissed as “messy” or “intuitive” with the implication that they are not reliable. (Invent to Learn)
If you enjoy what you read here, feel free to sign up for my monthly newsletter to catch up on all things learning, edtech and storytelling.
Originally published at readwriterespond.com on June 6, 2016.
