## Archive for February 21, 2012

### Bret Victor’s “Inventing on Principle,” and the trade-off between usability and learning

I have had several people now send me a link to Bret Victor’s video on *Inventing on Principle. *It is a really impressive demo!

His system reminds me of Mike Eisenberg’s work on SchemePaint. Mike wanted the artist to be able to interleave programming and direct manipulation. In SchemePaint, you could draw something by hand, then store the result in a variable to manipulate in a loop. Or you could write some code to tesselate some graphical object, then add tweaks by hand. It was beautiful. The work that Mike did on SchemePaint led to his wonderful work on HyperGami, a CAD system for origami, which was the start of his Craft Technology group. That’s the group from which Leah Buechley graduated — she did the LilyPad.

People are sending me Bret’s video asking, “Wouldn’t this be great for learners?” I bet it could be, but we’d have to try it out. At one point in his lecture, Bret says, “Why should I have to simulate the computer in my head?” Because that’s the point of *understanding* computer science. Bret’s system looks like a powerful visualization system, and visualization can be used to lead to real understanding, but it isn’t easy to design the visualization and context such that learning occurs.

The problem is that visualization is about making information immediate and accessible, but learning is about changes in the mind — invisible associations and structures. Sometimes good usability makes it easier to make these associations and structures. Tools like Scratch and Alice increase usability in one direction (e.g., syntax) while still asking students to make an effort toward understanding (e.g., variables, loops, and conditionals).

My first PhD student was Noel Rappin, who explored the features of modeling environments that lead to learning. He had a CHI paper about his work on helping chemical engineers learn through modeling. Our colleagues in chemical engineering complained that their students couldn’t connect the equations to the physical details of the pumping systems that they were modeling. Noel built a system where students would lay out the physical representation of a pumping system, then “look underneath” to see the equations of the system, with the values filled in from the physical representation (e.g., height difference between tanks).

He ran a pilot study where students would lay out a system according to certain characteristics. They would then manipulate the system to achieve some goal, like a given flow rate at a particular point in the system. When Noel asked the pilot students if they gained any new insights about the equations, one student actually said, “What equations?” They literally didn’t see the equations, just the particular value they were focusing on. The system was highly usable for modeling, but not for learning.

Noel built a new system, where students could lay out a model, and values from the model were immediately available in an equation space. To get the flow rate, the student would have to lay out the equations for themselves. They would still solve the problem by manipulating the physical representation in order to get the right flow rate, and the system would still do all the calculations — but the students would have to figure out how to *compute* the flow rate. The system became much harder to use. But now, students actually did learn, and better than students in a comparison group.

Bret’s system is insightful and may have some terrific ideas for helping learning. I’m not convinced that they’re new ideas yet, but an old idea in a new setting (e.g., JavaScript) can be powerful. I worry that we get too entranced by improvements in usability. In the end, learning is in the student, not in the system.

Recent Comments