I remember that when I was a kid, I “made” a Logo program that played 20 questions with you. I put “made” in quotation marks because what I really did was copy it out of a book. I don’t think that I understood what two-thirds of it did, but in the end (after spending hours figuring out which quotation mark or parenthesis I’d forgotten this time), I managed to get it running and was pretty proud of my little program, even if it was just an exercise in manual copy-and-paste.
I kept this experience in mind this past week at Girls Learning Code because there’s definitely a trade-off between understanding all of the components versus getting something cool faster.
I want to make an important point here: You can’t cheat this spectrum by adding explanatory text.
A good example of this is Hopscotch, which the girls played with on their last day. It’s a cool HTML5 tutorial that shows you how to draw shapes and stuff and lets you draw and customize a puppy face:
The top of the screen tells you some instructions and teaches you the next step. The left-hand pane at the bottom is a text field where you can type whatever you want, and then it renders on the right-hand pane.
This reminds me actually a lot of our design for Storything.
But there were a few issues:
- I went past the girls’ desks who finished the activity quickly and asked them to explain to me what their code did. They had no idea.
- One of them said to me: “We’re making ellipses, but I’m not sure what an ellipse is.”
- Even the girls who customized their puppy beyond the defaults: “If you want to change his color, you write ‘white‘ somewhere, but I forget where, it was in step 5 I think.”
- There was a lot of brute-force trial and error to simply get to the next step.
- When Hopscotch’s regexes failed, it taught them the wrong lessons. For example, at one point it wanted spaces where there didn’t need to be spaces in order to be correct JS. So their code was rendering properly, but they weren’t getting the “Good job! Move on to the next step!” feedback.
This might seem like a case against follow-along tutorials, but we also need to take a look at what the girls did during their free time.
Often they had parts of the afternoon to work on whichever project they wanted to, and the overwhelming choice throughout the week was to work on their Scratch games.
More specifically, the most compelling experiences that kept drawing them back was the girls who chose to follow a tutorial, making, for example a complete underwater game by following a set of steps.
Because they were able to create a compelling product faster, it seemed to keep drawing them back. They wanted to tweak things, add more optional features, and ultimately customize it (using their own images and such) making it their own. And the more time they spent on their game, the more they were able to explain to me what the parts did.
Although some girls who had prior experience understood most of their game, the majority of them did not. They understood bits and pieces. They understood enough to experiment a little.
Contrast this with the python interpreter: after their first day of learning how to make a madlibs game in Python (which they all enjoyed), I don’t think anyone went back. It was just too open-ended and they didn’t know about any Python tutorials to follow. (I bet if I’d handed some out, some of them would have gone back to make some Python games: next time.)
I think there’s three important lessons to come from all this:
- Just because you have explanatory text doesn’t mean they’re reading it. It’s totally possible to read juuuust enough to go on to the next step, and many people will choose that path.
- Don’t underestimate the value of a polished product quickly. Most people don’t want to work on something that looks janky, even if they made it from scratch. (pun not intended.)
- Customizing something that already looks awesome to be yours is a strong draw. I think this ties very closely to the “remix” element of the web.
There’s probably a “right spot” on the spectrum above that varies a lot depending on your audience, how long you have them for, etc. But I think these three lessons apply regardless of the audience.
