Rejection from Future Programming Workshop
The Future Programming Workshop solicited demos of tools that I understood would produce the next generation of screencasts. Here’s the solicitation from Jonathan Edwards:
The revolution will be screencast
Richard Gabriel and I are planning a workshop at SPLASH focused on screencast demos: The Future Programming Workshop. This will be a workshop in the sense of a writer’s workshop: the participants will present their talks/demos and the group will critique them. After the workshop people will revise their screencasts to be published on our website. Please signup at the website if you are interested.
I submitted a video of my Keystrokes project, a tool for recording and playing back text movies. However, I discovered too late that the content was to be generally on the future of programming, and the presentations just happened to done using screencasts as a medium. My proposal of rethinking screencasts was therefore very off-topic, and I’m slightly embarrassed that I submitted.
The reviewers found my video clever and not clever, and that it was too much of a demo.
Unfortunately your submission was not accepted by the program committee. I have included comments from the reviewers in the hope that they will help you to improve the presentation of your ideas. Rejection can be upsetting but I encourage you to press on with your work nevertheless. Thank you for submitting.
Reviewer 1
—————-
This is a poor movie about a decent idea. The idea is that instead of making “pixel movies” (screencasts) to provide online programming classes, one should instead make keystroke movies, with sound. What this does is that as the sound plays the editor gets driven into the desired state as the keystrokes are replayed. The advantage of this is that the student can pause the video and play with the editor in the corresponding state. This is great, **provided the student doesn’t break anything**. Because if they break something then the keystroke movie is going to get wedged pretty quickly.What happens if the student moves the cursor to where the keystroke movie isn’t expecting it. This seems easy to solve. But what happens if the student breaks the code, so that perhaps it won’t even parse. Unless the student understands the error then they are going to be watching a fairly confusing keystroke movie. This ultimately is the reason people like pixel movies — the producer/director can guarantee what the student is watching. Another problem with this approach is that if students are not being forced to type along they may go into a more passive watching mode. Much of the experience in online programming courses is that you need to get students to learn by DOING, not just watching.
As for the bad movie part — starting with 2:30 of bad haikus, that don’t really explain what the idea is in any significant way, is not very good. If the PC chair had not mandated us to watch the first 5 minutes of every video this one wouldn’t have made it past 1:30. Maybe not past 1:00. This isn’t a subtle creative opening it’s not cute and it’s not clever. Use the time to do a better job of explaining the idea, what’s good about it, and what it’s weaknesses are too. One idea would be to start w/ a screencast of a pixel movie and then have the student say “but what if I do this, oh, I have to go type all this stuff to get me to exactly this place in the process and then I can experiment”.
Reviewer 2
—————-
There were many things to like about this video. It had a clever, somewhat mysterious introduction that pulled me in. There’s obviously not a lot of new technical contributions here, but I think the idea of a text movie being both watchable and immediately editable is a compelling one that I really haven’t seen in any other type of tutorial context before.There are several unanswered questions about how to handle deviations from the recordings. My understanding is that we’re looking for kernels of interesting new ideas here, not finished solutions, and this seems like one that provokes a lot of interesting possibilities. For example, what if the deviations themselves were aggregated and made visible back to the author of the video? There could be all kinds of data mining opportunities to learn what viewers did or did not understand, or what they wanted to change. There are also many interesting social science questions about the potential impact of this kind of stream of consciousness on people’s understanding of design rationale in solutions.
This would have been an A if there were any clever technical contributions that provided other insights into programming language design.
Reviewer 3
—————-I am puzzled and slightly annoyed by this demo. Whether or not you found the Haikus cute, what was the point of replaying them? And what was the point of changing 13 to 12? I feel like he is making some subtle ironic or meta point that is going over my head. The shifting viewpoint from teacher to student was confusing – I had to replay the video and stare at the little pause/play icon to understand what was happening. At only 9:20 long there was plenty of time to say something about how it works and what the limitations are but we are given nothing. E.g. he claims replay is independent of font size, but then how does scrolling get replayed? What if the student messes things up? Or what if the wrong versions of library packages are installed? I am left full of unanswered questions. This video was more a koan than a demo.