Executive summary: the tool I want for teaching programming doesn't yet exist, but could be built by combining the IPython Notebook, Towtruck, Etherpad, and Slide Drive. This would be a better web-based tool for teaching programming than anything currently available, and would alleviate the most critical bottleneck programming-for-everyone efforts face: the shortage of competent tutors.
A lot of people say harsh things about PowerPoint, but as I've discussed before, the alternatives are all unsatisfying as well. HTML5 slideshows don't allow authors to mix text and graphics free-hand the way people do on a whiteboard; instead, the two have to be segregated into blocks. Screencasts are unsatisfying too: they don't display first-class content , and, like slideshows, aren't interactively hackable.
But all is not lost: the pieces we'd need to build a first-class online collaborative teaching and presentation tool now exist, so long as we're willing to compromise a bit. Here's what I think they are:
1. The IPython Notebook is a "living" lab notebook for computational science that allows users to mix HTML with snippets of runnable code. One way to think about it is that it's a tutorial whose code examples can be run and modified in place; another is that it's an interactive re-thinking of Donald Knuth's idea of literate programming. People are already using notebooks for teaching, and while setup continues to be a hassle, it's clearly better than traditional, static, alternatives.
2. If you haven't seen Towtruck, you should check it out. Initially, it looks just like a two-pane in-the-browser editor showing CSS and HTML on one side and the rendered page on the other. What it adds is interactivity: at any point, I can share my session with you, so that everything either of us types is immediately visible to the other person. Based on what I've learned in the last four months running online tutorials for Software Carpentry, this is an excellent way to do one-to-one or one-to-few tutoring, especially when there's an audio channel to go with it (like Skype). It's more efficient than "mail me your code and I'll mail you back my thoughts" (and bulletin-board workalikes like Stack Overflow), and I believe it will prove to be much better at fostering the kind of ad hoc peer-to-peer instruction that's common in online gaming.
3. Etherpad is also a real-time collaboration tool, but is discussion-oriented rather than task-oriented. Most conference calls at Mozilla use have an Etherpad session running at the same time so that people can take minutes (in the main document pane), ask questions (in the chat pane), and socialize (ditto). Like Towtruck, it doesn't ship pixels around as video, but instead sends playback sequences (basically, the instructions needed to make my browser reproduce what you see in yours and vice versa).
4. Finally, the Slide Drive project that David Seifried started, and which Jeremy Banks has been enhancing as part of GSoC 2012, has been exploring a promising alternative: create slides in LibreOffice Impress, export them as SVG using the tools Marco Cecchetti has been building, then connect those to a voiceover using Popcorn.js. There's a lot of duct tape holding everything together, but it's proof that voiceover replays can be integrated with first-class web content.
The tool I want to teach programming would combine all four of these. Learners would start with an IPython Notebook containing explanatory text and hackable code snippets. An audio voiceover would be sync'd with the content, highlighting paragraphs and triggering execution of snippets at the right times (though of course people could switch it off if they'd rather just skim). Whenever learners want help, they would be able to share their session with peers or tutors (classmates, strangers found on Stack Overflow, or paid tutors—lots of models are possible). The helper's browser would then be slaved to the learner's , and there'd be supplementary panes for note-taking and text chat (plus a button for launching Skype or some other VoIP tool).
What wouldn't it include?
- Whiteboarding. I really like being able to mix words and pictures freely in my presentations, but HTML and web browsers (still) suck at that—as mentioned above, the best they let you do is embed an image in a block of text . That said, embedded images have gotten us through the last twenty-odd years, and there's no reason to delay the good until better comes along.
- A debugger. Debuggers are great tools for helping novices understand what actually happens when their programs run—for example, the visualization and rewind capabilities in Philip Guo's Online Python Tutor are just jaw-dropping. I definitely want 'em, but again, what's already in the IPython Notebook is pretty cool on its own.
- Anything other than programming. Software Carpentry is not just a Python course; its core includes material on the shell, version control, and SQL, none of which fit comfortably into the model described so far. This interactive Git tutorial shows that it can be done, but once more, I'd be OK leaving that out of Version 1.
Even without these features, this tool would help remedy the most critical bottleneck that Software Carpentry and other programming-for-everyone efforts have: the shortage of competent instructors. I didn't learn how to play Homeworld in a classroom; instead, a 14-year-old in Florida took pity on me after crushing me a few times and showed me how to maneuver my ships more efficiently . This tool's Towtruck/Etherpad features would directly aid casual online mentoring, i.e., they'd help someone who knows something to tutor someone who doesn't over the web for a few minutes at a time, rather than just in blocks of a few hours on the weekend at the local library. Yes, Stack Overflow and other bulletin board systems support asynchronous over-the-web transfer of knowledge as well, but their write-it-all-down model is less effective than direct real-time collaboration . It's less fun, too, and if we want to draw people into a community, we need to make it fun.
Another way this tool would help is through record and playback. This is the web-native equivalent of screencasting: rather than sending you a painted-in-pixels video of what I did, I send you a transcript of how I did it that you can replay in your browser. This comes almost for free as a side effect of the Towtruck/Etherpad functionality, since they depend on one browser being able to tell another what to do. If those instructions are recorded, then synced with a voiceover or other multimedia using Popcorn (in the way that Slide Drive syncs things), it becomes possible for someone to record a how-to or a what-to-do so that others can play it back days, weeks, or months later, without needing to install something like Camtasia .
Is it going to happen? I don't know. The pieces may be there, but at a guess, one talented programmer-year (TPY) would be needed to create a usable prototype, which makes this roughly a hundred thousand dollar project. I do know that it would be a lot more interesting than most of the current crop of online education projects.
 Stuff in screencasts that looks like text isn't really text: if you pause the screencast and try to select a few "lines", what you'll get is pixels arranged in patterns that resemble letters rather than the letters themselves. The same is true for diagrams: those things that look like boxes and arrows are just colored pixels too. This might not seem like a big deal, but if the content can't be selected and copied, it probably can't be indexed by search engines, and is probably opaque to accessibility aids as well.
 For security reasons, we probably wouldn't let observers actually type things into the IPython Notebook—not unless we were sure the background Python process was really well sandboxed.
 As Jeremy has been discovering, SVG-in-the-browser is not a way forward. Neither is plopping a canvas on top of your rendered page.
 At least, he said he was a 14-year-old in Florida...
 BBS-style systems may be more cost-effective, though, since good answers are findable months or years later—I think there's a role for both.
 And if properly designed, those "recordings" would be forkable and mergeable, which would move us one step closer to the "GitHub for education" that keeps coming up. This in turn would make it easier for people to elaborate and comment on this kind of how-to presentation.