Some weeks ago Bret Victor made a big splash with a talk called Inventing on Principle. His basic message was about the value of direct manipulation and instantaneous visual feedback. These aren’t new concepts, but Victor’s demonstrations were brilliant. They were elegant and persuasive in a way that words alone would not be.
As impressive as the talk is, there was something about it that nagged at me. I had the feeling that what he was saying and what he was demonstrating weren’t quite the same thing. Mark Guzdial of Georgia Tech is one of the few people I’ve seen to make a thoughtful critique of Victor’s approach, and he articulated my concern. You can read his commentary here: Inventing on Principle and the trade-off between usability and learning (interesting side note: Guzdial’s post drew comments from Alan Kay and Bret Victor himself).
What Guzdial says is something like this: make sure you understand your goal. If you want people to learn something, make sure they actually come to grips with that thing, and not an abstract and airbrushed version of it. Chasing usability (or entertainment) can come at the expense of learning, and if learning is your goal, you will have lost something important.
Guzdial provided an example of some educational software that was supposed to teach the relationship between the math (differential equations) and the physical system being represented (pipe flow). The software let you play around with pipes while the equations changed in real time. What happened? People liked the physical modeling (screwing around with pipes) and totally missed the underlying equations. But the equations were supposed to be the point of the exercise! So the authors had to retune the system to make the math more prominent. Now what happened?
The system became much harder to use. But now, students actually did learn, and better than students in a comparison group.
Let’s say you want to be able to play Beethoven’s Moonlight Sonata. The best tool I can give you is a machine with a single button bearing the label “Press this button to hear Beethoven’s Moonlight Sonata.” But I’ve probably underestimated your goal. If your goal is in fact to play the Moonlight Sonata on a piano with your own hands, then my music machine would be worthless to you. I would be guilty of putting you in a teeny-tiny task box. But beware! Now you need to spend years learning how to use the piano, a very expressive but demanding and not terribly user-friendly machine.
Any tool puts you in a box of addressable tasks. Constrained tools have small task boxes. Expressive tools are hard to learn. Finding the optimal balance between expressive depth and simplifying constraint is very tricky.
Now look at this tool that Victor built for using simulation to understand a math word problem.
It’s beautiful! And it works well as long as you don’t want to modify the essential parameters of the problem. But Victor isn’t helping us learn the metatools that he uses to create this environment. To be fair, that wasn’t his goal, but as a user, I feel like I’m locked in a pretty small task box. More to the point, it’s expensive to create these interactive gems, and there’s only one Bret Victor.
Victor’s real power is his ability to rapidly create and deploy these tools. In a twinkling he can size up a task that is worth studying, put a box around it and spin a tool. He does this so effortlessly, with such mesmerizing legerdemain, that we lose sight of this meta-skill. What Victor was really doing in his talk was illustrating the power of tool spinning, the rapid creation of customized, context-sensitive, insight-generating tools. Direct manipulation is good, but the nature of direct manipulation changes with the context, and the context can’t always be anticipated.
My preferred goal is to make tool spinning (and tool sharing) as easy as possible. If tool spinning is easy, if that is the expressive skill that we give our users, then small task boxes aren’t a problem. You can always make more tools.
Don’t use the thing Bret made. Do the thing that Bret does.