rejigger

The last week before break, no one in an elementary school is at their best. I hit a weird wall with my g5 students that I hadn’t expected and it threw my last week plans for a loop.

The goal had been to start diagramming and building multi-sensor data loggers for use in and around our school environment. In past years, I’ve had students do this with single sensors and just collect a pile of data. I wrote some of this up in mBot for Makers, if you for some reason want more details and Scratch blocks. Reflecting on that project, I felt that I had kept the good stuff for myself. A group of 5th graders could see a huge string of temperature numbers or, after a bit of work in Sheets, reasonable line graphs of that data. When we looked at lots of those together, the interesting pictures emerged. Temperature by the elevator drops rapidly at recess.  Maybe that’s because (shuffles papers) this graph shows that the doors are standing open for 10 minutes!

This year, I wanted to put students in control of those connection. Instead of gathering data from a single sensor, they would use two or three at a time. Each program would gather enough data to investigate a possible correlation. Does the temperature drop when the doors stand open? How fast? How much? How far into the hallway?

It didn’t work out like that. Instead, most of the groups wandered off into one of two directions. Either they chose sensors and locations seemingly at random (which, in g5 terms means that everyone chose their first idea and no one was willing to lose face and change) and spent the period staring at the page unable to come up with a reason why the temperature in the chicken coop would affect the amount of motion in the g3 bathroom. Or they jumped right to work designing a system that would DO SOMETHING based on sensor data. Change the color of an LED strip when the door stands open too long. Play a “wash your hands! sound every time the bathroom lights come on. Basic elementary school tools to chide the world into compliance.

It was the last week of school, and I only managed to see 3 classes out of six. I think it’s clear that I skipped an important step in this process. Maybe before we start up again, I can set up single sensors around school and present them with the kind of data that so fascinated me last year. Instead of shoving them into the heart of a hard problem, let them launch from the spot I found interesting in the first place.

Advertisement

rebuilding

I’ve been thinking more about the topic / grade divide I ended on yesterday. Like almost all my conundrums, the actual practical answer will probably hinge on scheduling or sectioning details, of which I know nothing and have even less control. But, in the meantime, it’s interesting to think through.

Yesterday I was thinking about Jeff’s cosplay group and mentally mixing it with my daughter’s sustained interest in 18″ doll photography and stop motion (you can follow her work on Insta and Youtube). Somewhere in that intersection is a course that reaches out to kids fascinated with costuming and prop building, looking to combine art and photography with the fantastic. There’s not a tool in any makerspace that couldn’t be pressed into service of those goals.

Let’s posit the existence of three unique, catchy frames for makerspace elective/exploratory that might appeal to disparate (if not mutually exclusive) sections of a student population. Jodi, always smarter than I am, suggested Craft, Build, Tinker as placeholder category names. The names aren’t meant to exclude any activity, but as a signpost for fascinating, passionate kids.

For me, the most important thing is to avoid signalling to giant pre-existing social groups that this new space is “for them.” In an earlier interview this season, a Head of School explained that my (potential) makerspace/programming electives would be for “those 6 guys, you know, who just want to play video games.” That’s one way to make sure that no one else becomes invested in a program.

 

I don’t want to avoid programming, games or robotics. I just want to avoid making the initial makerspace electives filled with the people who automatically choose context-free programming, games or robots out of any field.

 

If I had the option, what would be different about offering each of the three topics to a different grade level each term as opposed to offering the same topic to the different grade ranges?

 

Assumption: There are probably 2-3 distinct grade level schedules in a 6-12 school. So offering Craft in a given block means offering it to 6-8 or 9-10 or some other partitioned subgroup.

 

There’s an obvious teacher benefit to only offering one topic at a time. This isn’t the same as only having “one prep” in a single subject, but it’s about as close as a makerspace can get. Project storage for three classes is still space intensive, but you can hope that most projects will fit within a reasonable range. While different kids will explore different tool and material paths in their projects, you can build similar introduction or training tasks grounded in a particular context.

 

Providing similar prompts to 11 / 13 /17 year old students at the same time is a great way to get feedback on their viability. Every week would be a new set of focused “and then…” challenges. My hope would be that if a particular project shot off in an unexpected direction that needed new tools or materials (“I need a 2x1m foam block to carve a *buster sword*”) that supporting that project would inspire new ideas and funnel more interest towards the new investment. Most of all, running classes for multiple age groups would give me a broader introduction to the student community. My first year at CI, I worked with single grade levels for 6 week chunks. It was really, really hard to get a sense of the school with that schedule.

 

What are the downsides? Trimester are long and semesters are longer. Just as I don’t want a makerspace to be “the robotics room,” I don’t think being “the prop/costume” room is significantly better.  If I bet wrong on the topic for the first term, the space could be flooded or become a ghost town. If the first topic is a roaring success, I’ll need to find someway to keep those students engaged and connected with the space outside of the elective/exploratory structure.

 

Running multiple topics hedges against some of these outcomes. Whatever reputation the space might develop, it won’t just be as home for a singular activity. I could still spread out offerings across the age groups in a given term, and then cycle topics through each age group (trimester offerings of Craft / Build / Tinker for one group, Build / Tinker / Craft for the next).

 

I worry about generating 3 sets of compelling, context-rich prompts across three domains during the first run, and of making sure that all three tracks are equally well resourced. I worry about having to do major tool shifts during the day. Having a Build class using woodworking and welding equipment followed by a Craft class using the paint stations and sewing machines could put a strain on the space (and me). I don’t know if it would be any easier to retain kid interest in the “off season,” since the offerings in their particular grade range would still be A then B then C.

 

I don’t imagine that I’ll actually have the flexibility to choose between these two models next fall. But I think I have a better idea of how to make either reality a success.

foundations

I was able to launch makers at FHS because of Cat and Peter, two stupendously bright 7th graders that were bouncing off every form of engagement our middle school had to offer.

These were kids I had known and taught for years, who only broke rules in order to stay in at lunch. Makers grew out of those kids because it was clear that there study halls a week was going to be both a chore and wasted opportunity. Offering anything else was a net improvement.

Also, adafruit. And sparkfun. And a Microcenter in town that quickly abandoned videogames in favor of maker kits. With a small number of passionate kids and a willingness to use my own credit cards, it was entirely possible to run Makers as a hyper-personalized student directed workshop.

The program at FHS quickly outgrew that model, and it wasn’t viable for a moment at CI. There’s no program that can “just say yes” to every kid idea or teacher idea, that will survive 800 voices making requests. Gary shielded me from the brunt of my naiveté and I still feel like I learned that lesson the hard way. Early days of FHS Makers felt like being the personal guide and concierge for intrepid travelers. When I could provide something they only half-thought of, or could assist with a new complex skill, it felt like everything I wanted to be as a teacher. When I tried that at CI, I felt like an incompetent waiter running dishes in from the kitchen four blocks away.

Looking at next year, I want to find a way to create little pockets of that early FHS experience, supported by the tools and materials we’ll have on hand instead of just my credit card. How does that work? I can’t build years of knowledge and connection before I arrive. The last 5 years have blown apart any notion that “kids are the same everywhere.”

The goal shouldn’t be to tap into a really popular strand of culture (yeah, I taught through all sections of the Minecraft wave), but find a few pockets & project areas that can fuse groups together. Jeff Layman has been running a great cosplay elective at ISB. That seems flexible enough to reach any kids with deep ties to book/film/comic/fan culture and incorporates the printers, cutters, sewing machines and micro:bits.

Would it be better to offer several different topic electives each term, or offer the same topic to different grade levels? Oh, now I need to see a bell schedule.

Restarting

There’s a new job and a new space waiting.

Blank walls to fill and new faces to learn.

 

In every conversation for the last 8 years, I’ve felt like the Makerspace expert, or at least at parity. I have pat answers for “what’s the most important tool,” or “what kind of space do we need?” or “how do we find someone to help us grow?” Taking your own advice is always daunting.

Taking a decade of it all at once is terrifying. I feel how inadequate my advice has been all along.

“Start with people.  Build relationships and cultivate passion. Tools and projects will follow.”

That worked well for me at FHS, where I was on the ground for years before I said the word “Makerspace” out loud. At CI, I was able to draft off Gary and Shelly’s years of work until I made my own connections and brought new classes into our orbit. For new faculty opening a brand new dedicated space, it seems impossible to take things that slow.

I need to think things through from principles again, need to process the great work being done by my colleagues and (absent) friends around the globe, need to reflect on what a program could become before it’s constrained by “how we do things.”

 

Fortunately, I remembered a place where I used to do all of that.  Welcome back.

WaterColorBot and Snap!

 

This is my informal rundown of how to get started using the WaterColor Blocks extension with Snap! and your WaterColorBot plotter. I’ve had a WaterColorBot on hand since the first Kickstarter, and this is the way I most commonly use the WCB with elementary and middle school students. There are ways to generate more impressive output – complex vector art in Inkscape or detailed images rendered with StippleGen, but nothing touches WCBlocks as a learning tool.

 

First, you need to have something installed on your computer that will pass commands to the WaterColorBot. I still use RoboPaint, but I think you could also use @techninja42 ‘s CNC Server on its own. Using RoboPaint, you can open the program and then use the RoboPaint settings menu to home the brush and calibrate the height of your pen. Once that’s done, leave RoboPaint at the home screen. You don’t need to do anything in the RoboPaint program, just have it open to pass commands to the WCBot.

There’s a bunch of stuff to download in the WCBlocks github, but there’s nothing required for Snap! except a single project file (saved as .xml) that contains the actual Blocks. The other stuff in the WCBlocks download is either examples (interesting, but not required) or stuff for offline Scratch. I havent checked in the last few months, but IIRC offline Scratch fails to do the central useful feature of Snap! + WCBlocks – namely have single blocks that move both the WCBot pen and the screen turtle. So, basically, don’t use the Scratch version.

 

To use Snap! with the WCBot, you need to open Snap! and then import a project that contains the WCBlocks. Any of the example files in the WCBlocks download will work. I’ve recently been using this file with kids, which has all of the WCBlocks along with the examples I discuss in this post. When I’m working with kids, I often send a custom project file that adds extra blocks or scripts. We’ll pass quietly by this point, but it’s the door to my rabbit hole obsession.

 

Project files often don’t have scripts on the stage, so it can be tricky to tell if the import worked. Check Motion, Pen, Control and Sensing to make sure all the WCBlocks show up.

Again, the awesome part of WCBlocks is that all of these blocks control BOTH the screen turtle (default arrow in Snap!) and the pen carriage on the WCBot. When drawings on the screen exceed the size of the paper, the pen will lift, the carriage will move to follow the screen turtle, lowering to resume drawing when the carriage comes back within the boundaries.

Caveat: This assumes that the WCBot was reset properly to the top left corner before drawing. If the WCBot isn’t calibrated properly, the carriage will slam against the edges. There are no limit switches on the WCBot.

 

So, sure, a basic square.

Since the actual draw loop is exactly the same as a standard Scratch/Snap/Logo square, let’s look at how this is different.

 

WCB Wash Brush runs the brush through all three water trays, swishing at each one. This block will pull the pen from whatever position it’s currently in, and leave it raised above the last water tray.

 

WCB Get Paint() send the brush to a particular paint tray, lowers it and smushes it around. This is where you’ll notice how much of a difference a few mm of height can make on your brush. :) It leaves the pen raised above the paint tub.

 

This draws an acceptable monocolor square. With screen LOGOs like Scratch and Snap, a common next step is to introduce more colors into a shape. But since the mechanical components of changing color with the WCBot are non-trivial, there’s some complexity and extra blocks. Notably, we need to keep track of the position & heading of the brush so that we can return to it after the color change.

 

When I do stuff like this, I use a Snap! specific feature called Script Variables. These aren’t complicated, but they are different from how things work in Scratch. They’re properly local variables, meaning that you can call them into existence with a block and use them in a script, but they don’t persist after the script is finished.

 

I’m going to use these Script Variables to hold the X position, Y position and direction of the brush while the Wash Bursh and Get Color () blocks do their thing. Then use use the Go To X:() Y:() and Point in Direction() blocks to reposition the brush before we lower it back to the paper.

 

This is a headache, especially for kids. As a result, I often have the WCBot set up to use a pen for initial LOGO drawings. Pens are great. They have small, consistent line weights. They don’t need to wash or refill ink in the middle of drawings. When you have a class full of projects, run them with pens. Once a drawing works with pens, then consider using the watercolors.

 

When you’re ready to do that, you may also consider creating a dedicated block that does this whole procedure. In the orange variable tab, you can create your own blocks. This is similar to, but much more powerful, the purple Custom Blocks in Scratch 2.

Here, I’ve taken the complicated stuff (recording position) from the earlier script and bundled into a block I call WCB Wash & Color ()

 

This takes a single number (color choice) as input, and then does all the stuff from the program above. As a result, I could rewrite the multicolored square into a much cleaner script.

In my experience, this is the key to using the WCBot and Snap! with elementary age kids. My goal is for them to grapple with the hard fun of LOGO in a physical medium. I do as much as I can to abstract away the complications of the WCBot and let them focus on the programing challenge of designing in LOGO.

 

This brings us back to the rabbit hole I mentioned at the top of this post. Given the chance, I use Brian Silverman & Artemis Papert’s fantastic TurtleArt when doing screen Logo. It’s beautiful, powerful, focused and elegant. I realize that I have another post lurking on why I prefer Turtle Art to Scratch and Snap for screen LOGO, so I’ll leave my endorsement as it stands.

 

One of the awesome features is that TurtleArt includes an Arc block as a primitive. There have been deep arguments about what commands should be included as primitives since the invention of LOGO. While kids can create circles in Snap!/Scratch using small loops (Repeat 360 [FW 1, RT 1]) , it’s difficult to get those to easily mesh with the measurements in the rest of their drawings. The Arc primitive means that students can easily fit a curved roof to a rectangular house by tweaking the radius value, even if they don’t know “radius” as a vocab word. Changing either of the  two parameters for the Arc block produce obvious changes in the shape, and those changes are predictable. Even though the Repeat loop can produce similar shapes, it asks for a much deeper understanding about how the circle is created. I think students build towards more interesting designs faster using the Arc block, so I tried to recreate it in Snap for the WCBot. One version is included in the sample program as WCB Arc.

 

The problem isn’t that this is complicated. The problem is that it still doesn’t work well on paper.

Both this version and the alternate which scales the Turn parameter rather than the Step, run into trouble sending tiny values to the CNC Server. I found that small steps work better than small turns, but there’s still a mismatch between what appears on the screen and what the WCBot draws.

I don’t know if there’s a clean solution to these problems. When the WCBot programs render vector art (SVG files) into motor commands, they are able to operate on entire figures and compute the whole motion to draw an arbitrary circle. The way the Snap! interface works, it’s sending individual commands in a long sequence. Complex curves require some of those commands to be for very tiny motions that seem to fall below the WCBot’s thresholds.

Design Do Discover at CI 2017

I’m so excited for this!

For the last 4 years, I’ve watched jealously as Angi Chau and Jaymes Dec built Design Do Discover into a powerhouse MakerEd event. The first D3 happened right when I moved to Korea, and I had just resigned myself into watching the proceedings on Twitter for eternity.

Then last June, I posted on twitter when we landed in SFO. Almost immediately Angi asked if I had flow in for D3 at Castelleja and invited me to join the fun as a last-minute coach. What fun! I finally got a chance to work alongside Angi, Jaymes, Heather Pang, Lindsey Own and so many other MakerEd / Fablearn allstars. More importantly, I was able to connect with a host of maker-interested teachers from around the Bay Area. Really, it’s the best way to deal with jet lag.

Back in Korea, I was asked to build a list of MakerEd or Design PD opportunities for Chadwick faculty. Despite the great and growing crop of events in the states, I couldn’t find any good anglophone options for D3 (and Constructing Modern Knowledge’s) brand of deep dive learning anywhere in Asia. Chadwick is generous with PD funds, but the costs and strain of trans-Pacific flights made even the most affordable events into a steep ask.

As a direct result, we’re now accepting registrations for Design Do Discover at Chadwick International, March 24th – 26th 2017.

If you can’t find the tool you need, build it yourself, right? In this case, it’s built with the cooperation and guidance of Jaymes and Angi personally as well as Marymount and Castelleja.

We’re offering the same learner-focused, material-rich, expert-strewn environment as D3 at Marymount and Castelleja, but here in Songdo. We’re bringing over several veteran coaches from previous D3s, as well as experts from international schools and our local community.

If you’re an international educator interested in building the hands-on skills necessary to bring MakerEd experiences into your classroom, come join us at Design Do Discover!

Making (Specific) Stuff

One of the weird downsides of teaching at a school committed to rich #makered experiences for all students, is that I don’t spend a lot of brain cycles developing new arguments about why broad, equitable #makered is crucial. I just get to do it.

As such, fewer polemics. But more concrete, tangible, useful stuff.

Next week, grade 5 starts their biggest (in terms of dedicated classroom time) integrated design project. The design prompts violate Gary Stager’s post-it rule, but they’re pretty concise. You can check out the four prompts if you life. I’d appreciate any feedback on anything you find confusing or unclear.

Last spring we ran a giant “build a speaker” activity for grades 4-7, simultaneously. I built this little video as a intro/tutorial. As it turns out, building the hands-only camera rig was more long-term useful than the video. Many elementary kids find it easier to create their own task specific instructional videos when you remove the twin perils of showing your face and narrating your actions.

 

Finally, I’ve been really inspired by the work on LEGO linkages done by the Tinkering Studio, and my lovely Twitter colleagues Josh Burker, Ryan Jenkins and Amos Blanton. We cut some vertical linkage boards at the beginning of the school year, and those have been good frameworks for students testing movement ideas.

But we’ve struggled to attach motors to the vertical boards. Most of my colleagues use LEGO Power Functions motors, which are small and squat enough to attach straight through the board. Sadly, we only have a few motors and fewer battery packs. Anything that relies on PF motors will stay an experiment, not develop into classroom staple.

We do have a huge pile of NXT and EV3 motors, but they’re much heavier and awkwardly shaped. They couldn’t mount flush with the TECHNIC board, and their weight would often flex the axle. When I saw Ryan’s horizontal TECHNIC play surface, I realized it could help solve our motor conundrum.

After some iterative Illustrator, I came up with a modified TECHNCI surface that allows the robotics motors to clip in on the edges. This keeps the cabling accessible while still allowing a 40t gear to spin freely. I put the motors in the corners so that the plastic housings can also serve as the table legs.

The TECHNIC hole pattern comes from Sebastian’s work at the Tinkering Studio, tweaked a bit for the size and kerf of Chadwick’s laser cutter. If you have EV3 or NXT motors that you’d like to play with, you can grab the SVG files here. Share pictures of anything you make!

 

 

Creativity & Specificity

The original MakeyMakey Kickstarter video may be the most imitated document across classroom and conference MakerEd. Five years on, I’m still impressed by what students and teachers can create with the MakeyMakey, but I will die happy if I never see another banana piano.

This speaks to a larger imitative problem among teachers and students alike. We share provocations and lessons, publish great books full of amazing projects, always hoping that people will use those concrete examples to springboard into their own creative explorations. But it’s very easy for creative actions to become codified into rote projects.

For a few years, I’ve tried to explode out a persistent idea from that MakeyMakey video and have students build interesting video game controllers. In my first efforts, far more kids built squishy d-pads than water-bucket DDR.

Since I moved to Korea, I’ve had to be far more deliberate in creating prompts that actually encourage creativity, loosely marked here by deviation from an observable norm. In other environments an early exemplar project could serve as a inspiration/catalyst for the class. Here the first “successful” prototype exerts a terrifying gravitational pull, and very few students’ ideas are strong enough to escape.

As a result, I’ve had to up my game when creating prompts for these “open-ended” projects. It’s not enough to avoid specifying a form for the final product, or avoid showing examples. I have to go further and craft the prompt to steer around the low-hanging/easy answers.

To compound the difficulty, you can’t drown students with “don’t do” instructions. For starters, this shifts the tone from an opened design challenge into a game of how to outsmart the teacher. It’s fine for these challenges to have some puzzle-like elements, but the teacher can’t be the law-giver at the center.

Labeling something that kids “naturally” arrive at as an invalid/bad solution is almost as destructive to the iterative tinkering mindset as a class full of cardboard NES controllers. :) Instead, dive deep on specificity of the task. When kids have a super-wide field, they often steer towards bland, generic solutions. Give them something thorny and idiosyncratic as a prompt and they’ll produce solutions in kind.

Here are three discrete avenues for video game controllers, all of which easily steer around to as ways to avoid the Play-Doh NES pad.

Literal Control – Create a game controller where to play the game, you have to perform the action depicted in the game.

This is the prompt that I don’t talk about with admin. Adults with cursory knowledge of videogames will assume this means a class full of cardboard guns. So choose a bank of sample games for them, even something as broad as “anything on this NES emulator.” Given the option, kids will produce picks and axes for minecraft, but that’s not such a bad thing. Swinging a cardboard tube repeatedly can be a revelatory experience!

Guerilla Co-Op – Make a multi-person controller for a single player game.

The archtypal version of this is multi-player Pacman, where each player has control over one of the 4 direction inputs. I’ve been making this in workshops since the makeymakey kickstarter, and saw video of Marvin Minsky describing it in 1982! Early arcade games are good targets for this – Asteroids, Frogger, Pole Position. Games that require diagonal inputs, or synced presses from multiple buttons, up the complexity considerably. I have an open bounty for kids to devise a 3+ player controller for Contra and beat the first level. Have not had to play out yet. :)

Puzzle Box controllers – Make a beautiful game controller that you can use, but looks like magic to everyone else.

I’ve only done this prompt once, so I think it needs more honing than the other two. Using a basic game, like Snake, Pacman or QUIX, a good puzzle box controller have a “trick” interface of some kind that frustrates the audience, but lets the inventor/magician play smoothly. Kid projects involved hidden ground contacts, or “buttons” that needed multiple contact points. One kid worked on a prototype in Scratch where the game controls changed with each button press, but never had a game that showed off that feature.

MakerEd update: Looms and Bridges

I dread Halloween for a number of reasons. The most trivial among them is that starts November and the traditional* post every day challenge. Working with that daily requirement forces me to realize how easily I fall into bad “essayist” habits with the blog. I don’t post about stuff until I’ve got something to say about the stuff, which in my saner moments I recognize is the exact opposite of the correct plan.

In the spirit of November, here’s the disjointed status of Makers.

The most elaborate Scratch+MakeyMakey project my class has ever seen reached something like alpha software and moved on to laying copper tape. Hence this, the most elaborate Bridges of Königsberg puzzle I’ve ever seen. I felt so math teacher proud about this. I laid down the law! Paths must not cross!

There was a full period of pencil sketching on the inside of their contraption before they even thought to reach for copper tape. They worked smart, using the raised edges, and running a long common ground through easily two dozen triggers. Then, after so much had been laid down, they discovered that they had taped themselves into a corner. “Isn’t there some way we can put stuff between the layers of tape?” Yes. now is the time when we talk about insulators and conductors.

Nate Kellogg asked about how our MS kids are using the 3D printer. Up until this week, my honest answer would have been “not as much as I had hoped.” The kids who actually built the machine display some ownership over it’s continued functioning, but they don’t seem to have any interest in using it in a significant way. I wasn’t sick with grief over this, but it was a bit surprising to me. I was happy to see that when other projects needs some thing, the printer would get called in to service, which represents both a crucial skill set and a mind shift for middle school students. But… I thought all kids were crazy for small plastic trinkets!

This week, I found the small plastic trinkets for which our students bring the craze. Makers and gentlenerds, the Rainbow Loom.

Are rubber band bracelets a thing with your kids? Then these designs will drive incredible traffic to your printer.

We started out using this great SCAD design for a closed ring loom. The commercial kit uses linear strips of the pegs that mount onto a base in various configurations. It’s pretty flexible, but bulky and not well suited for designs that extend off of the loom itself. The circular loom we’ve been printing is perfect for those, and turns a design that’s a tricky mess on the normal setup (the HEXAFISH**) into something that’s super easy and compact.
There have been more 5th and 6th graders in the lab this week than ever before. I know the about the “whistle trap” for 3D printing (although I can’t remember who coined the phrase), where the device becomes a tool to make a certain thing rather than something that enables student design. In my head I pretend that the loom isn’t a whistle, in part because of the changes they’re making to the base design in OpenSCAD. But really, I’m willing to risk it because of the crazy velocity, the sheer churn of kids coming into the space and asking about what they can make.

In other groups we have a RC plane under construction, a bunch of 555 timer projects (bad move: starting kids with breadboard projects more complicated than a pushbutton LED), a skeeball game, and powered paper airplanes. But the other lesson I remember from previous Novembers is that it’s better to post half the story in an 20 minutes than try to cover everything in an hour.

* aka I’ve done it twice

**strictly speaking the N-Fishtail.

Design vs. Demonstration

Great makerspace activities students are grounded in a design cycle. I know that’s a loaded phrase and there’s any number of fancy posters that use meticulously groomed verbs to describe the process. (For reference, ours has research/empathize/plan/make/test.)

In every case, the design cycle requires that students have an open-ended goal and the ability to engage in a test/revise/reflect loop. Whatever the task, students need to be able to measure/evaluate their own work against a clear standard or goal, then continually modify their work and test again.

This is different from many scientific inquiry cycles in that students are not generating, isolating, and testing specific hypothesis. I’m obsessing over a clear way to express that distinction, because our fist grade team is about to start a unit about “physical forces,” which basically translates into age-appropriate demonstrations of Newtonian principles. Those labs can be exciting, and teachers are familiar with the powerful “ah-ha!” moments they can inspire in students. While I’m happy to make use of that pedagogical tool in the Makerspace, I need to find a careful/neutral way to express that demonstration labs, in and of themselves, are not design activities.

I’ve tried and failed to make this distinction before, and have instead wound up debating wether all demonstrations need to be “hands on.” There’s plenty of valid reasons for “hands off” demonstrations in science class (Item A: FIRE), although youtube makes very few essential. I can still describe precisely several demonstration heilige JP’s chemistry class and those were as refined specimen of hands-off teacher monologue as I’ve ever witnessed.

The distinction between science labs and #makered doesn’t hinge on whether students remember the science better when they’re building their own baking soda volcanoes or watching a crazy masterpiece, but on how the learning environment constrains or empowers students. Even if students “make” and “test” the transfer of kinetic energy, the results can only be “yep, that’s physics” or “you messed up.” That’s not design.

Demonstration labs are valuable but they don’t allow for broad, self-directed engagement. When students can taking actions and making choices, based on their new/developing understanding of an idea, then you have a powerful learning opportunity. A classic example of this is water bottle rockets. Last year, our 6th grade team built a wind tunnel with a modified scale to measure drag. The wind tunnel opened up a way for students to easily test their plastic and duct-tape creations; one that didm not require adult interference, one that provided clear data, and didn’t end in a high impact collision. Few 6th grade rockets are sturdy enough for multiple launchers. None maintain a consistent aerodynamic profile.

Without the wind tunnel, debates over weight distribution and fin design would end in appeals to external (“Mr. Cook, is this right?”) or personal (“ got a better grade on the science quiz, so my fins are best”) authority. When the wind tunnel was available, those fights only happened while waiting for another group to finish testing their rocket.