DemoCampToronto11

This evening’s DemoCampToronto11 was notable in its failure: I’ve been to most of the previous ones, and the vast majority of the presentations have been decent. Not so tonight: of the five presentations, there was only one (Sunir Shah on “Design Bibliography”) that I’d consider a good one. The others:

-AutoSSL was certainly a good topic: an original Internet product being created by the presenters themselves. But the presentation was a combination of a demo (fine) and an attempt at a marketing-type presentation (not fine). There were objections from the audience to the diagram shown, which although not done in PowerPoint seemed to violate the spirit of the “no PowerPoint” rule of DemoCamp. I think the idea of the rule is that you should show the thing itself, not show something about it, and the audience made its unhappiness known. (Interestingly enough, the demo itself failed to work but this didn’t seem to bother the audience particularly. “Just give us a demo” — even if it fails!)

-Firestoker was a similar lost opportunity, again an original product improperly demoed. Every demo needs this to be explained: what is it? I had to figure out what Firestoker was by looking at a bunch of screenshots.

-Andrew Reynolds’ demo of the Selenium test tool was well done, but he was just demoing something he’s a user of (not builder of), and already available to all.

-My Studio Assistant: Arnold Wytenburg showed something that I have no doubt would be useful to many artists, but it’s just a website builder for a particular category of business, like so many others. Nothing particularly unusual or interesting about it.

Solutions? The DemoCamp organizers are already on the case, Jay Goldman having announced at the end of the event that they’d be looking at “refactoring” DemoCamp, and inviting comments. Here is my first thought:

There is already something in place at DemoCamp to address the what-is-it question, in that every presenter starts off by answering four questions: Who are you? What will you be showing us? What do you hope to give the community? What would you like back from the community? But it’s not working. One modified approach might be to replace these questions by a recommended (or required) structure for presenters to follow, something like this (where “X” is the thing being demoed):

1. Say who you are.

2. Set the context. Say who would use this. And if X is meant to solve a certain problem, say what that problem is. (The “pain statement”. See this video about elevator pitches by Sean Wise, also starring my former Sympatico colleague Peter Evans in a non-speaking role.)

3. Give the demo together with an explanation of what is being demoed. If a problem is being solved, say how X solves that problem. If not, say what X is, and how it’s useful or interesting or otherwise worthy of the audience’s attention.

4. Give any commentary on implications / uncertainties / future plans / whatever. It is crucial that this come after the demo.

(Repeat step 2-4 as many times as desired: sometimes there are multiple features or multiple uses.)

5. Make any offers to, and requests of, the community.

6. Take questions.