CMK Day 0 – Plans and Expectations
Blog comments are doubly ephemeral and fickle things, but as this disaster-movie summer drags on, I find myself drawn to them. Partly this stems from the selfish altruism of the small-blog comment economy, where lucky posts accrue a handful of comments and amazing, challenging pieces slip beneath without a single one. More realistic is that blog comments is a way to do a bit of writing, but where someone else has already framed a topic for discussion. That’s hard work, yo.
Instead of writing, last night I finished packing for Construcitng Modern Knowledge. This meant slightly more than counting socks – it meant building a bundle of components and projects to bring to Manchester. Little rituals like this throw me for a loop. It’s throwing objects into a Lack, and I’m hyper conscious of all the decision trees that (could!) fork off every inclusion or exclusion. It’s as close as I ever get to date-night wardrobe anxiety.
After lots of reflection, I’ve decided to approach CMK12 with my “teacher hat” firmly rolled into a back pocket – not dominant, but still something that affects my posture. I brought two UFOs (Un-Finished Objects – a term I’m stealing from my quilting mother-in-law) that I’d like to bring back in a fully functional state, ready for students to tackle physical design and software modification. Beyodn that,I brought as many sensors and buttons as I could fit into tupperware, two Unos and two Teensys, and a bunch of breadboards and jumper wire. My short conversations with @wagongrrl convinced me that Scratch4Arduino would be a good focus point for my days in Manchester.
I also had this strange half-dream about visiting the MIT Media Lab, where Jordan laid out the secrets of building fascinating systems that operate in the physical world. The rememnant of this dream-derived wisdom seems obvious – the more interesting a relationship you create between sensor data and behavior, the more interesting the object will be. Well, duh. But the wisdom part, which I can’t quite capture in text, is that I need to build a labyryinth that guides kids through the process of gradually complicating that relationship.
Typical Arduino examples for any given sensor expresses the reading through an LED, either in frequency or brightness. It’s a neat trick to blow on a temperature sensor and see the LED glow brighter, but I think those examples create some subtle problems for my students. Of course computational systems can tie together visual and physical systems! That’s the world they work with everyday, where one form of data seamlessly and magically modifies something else. They flip the phone an the puzzle blocks slide “down” the screen in a new direction. I’ve watched many bright students build a sample sensor->output system, run some sample code and then stall out for days. They can modify some constants in the code, but they don’t easily move beyond that. Even though their own fingers put the parts together, they don’t have the tools to do much more than re-skin the behaviour.
With a single input and output, there’s a limited number of relationships you can express between the two analog values. Adding more inputs and outputs rapidly opens up a world of new possibilties, but with a proper microcontroller, it increases the complexity of the code at an even faster rate. Want to actually ove things? Well, then we can add motors or solenoids… and add a power circuit that’s seperate from the 5v logic path. Can you see where 7th graders hit the wall?
Scratch offers them a familiar set of expressive techniques and the mathematical/programatic tools to build those interesting relationships between the on-screen behavior and the physical inputs. They can easily use the same sensor reading in different ways for different sprites!
So my goal is to nail down the full process for installing and configuring S4A with our hardware (can it use Teensys?) , and then set to building a few sensor boxes. As a starter project, I’m think giving a group of students the same pre-assembeled sensor package and asking them to build a Scratch game around those inputs. At CMK, I’d like to not only create a few sensor boxes, but also fully document my design process of a game.
I find Andrew’s Kavad project inspiring for the way it embodies and merges the journey and the goal throughout. The Kavad is designed to teach, so Andrew learns through research, practice and introspection and designs a Kavad that with lessons that did not exist before. The power of the design process, something I’ve always respected as an alien discipline, is manifest throughout his photos and writing. I need to produce similar works for my own learning and on my own axis of fascination. The web is replete with instructions and HowTos that can illustrate a particular path, but do little to teach how to find, follow or create a path of your own. I’ve done a lot of learning over the last, about electronics and programing and parenting and all the rest, most of it in a brash enthusiastic charge. I’ve done reasonably well encouraging students to emulate that head-first approach, but I need to show some balance, some more consideration, some more design.
So that’s my background plan, what I’m packed for in the moments before CMK surprises me. Finish some projects, build some new tools. But I’m going to try to engage with all this from a slightly different self. Not the pure-id learner, but modeling a more deliberate, reflective and concious process of investigation and design. Building a new self while I’m making new things.
OK. Now I’ve got that posted. Maybe it’s time to leave the airport.