This post is part of my research for Mozilla on a tool to help novices learn to be Web-builders -- a "Scratch for HTML5"
Yesterday, I sat down with Scott Gray from the O'Reilly School of Technology while we were both at Strata in Santa Clara. (Disclosure: I am currently a freelance writer for O'Reilly Radar). Considering Scott's long history of teaching programming online and our shared reactions to some of the latest efforts that purport to do that, well, let's just say that we had a particularly wonderful chat.
Scott actually left a great comment on my interview with Julie Meloni in which he talks about the importance of "cognitive load" with learning tools and services:
There are two types of cognitive load: extraneous, and germane. Extraneous cognitive load comes from efforts focused on tasks unrelated to the learning outcomes you're trying to achieve, and germane loads are those that are related to the learning outcomes. Great instructional designs are focused on reducing extraneous cognitive loads and increasing germane loads.
A few other ideas we touched upon yesterday:
Constructionism: "Learning by making" (versus, say, "learning by doing" in which "doing" often means just "clicking.") Problem with many of the "learn to program" offerings today is that they've fallen into this "lecture video plus multiple choice" mode of instruction and assessment.
Project-based learning: Learners should have a project -- this isn't just a loosely formed learning goal (as in, "I want to learn JavaScript") -- but something they are building. Learners should be able to quickly build something along the way too. And feedback is crucial.
"Go perpendicular": Messiness and mistakes are a good thing. A learn-to-code tool shouldn't be so constrained that learners can't make and learn from their mistakes -- and just as importantly, that they can't "go perpendicular" when those mistakes uncover new and exciting paths.
The split-screen: What would a Mozilla learn-to-Web-build tool look like? Well, Firebug is a great place to start -- a split screen where you can see the source code, highlight, edit, debug, remix and the like. This is part of the feedback piece (as in, make a change in the code, see what happens on the screen).
The tool versus the curriculum: Scott made a good point about separating curriculum -- as in, "this is a course on how to learn HTML5" -- versus a tool. How do we build the latter without getting bogged down with the former?
What are the limits of what we can do in the browser?: Could a tool support not just HTML5 and JavaScript, but other languages as well (flip a switch, for example, and the tool could help you learn Python, for example)? How much can we run client-side? A good reminder of the importance and the possibilities of making the learning platform extensible.
Role of teacher/coach: Pretty self-explanatory, but I'd add here the importance of social learning -- learning about the Web, on the Web, for the Web, with the Web