Node.DC goes Deck Lightning
Making every Meetup Attendee a Presentor
Last month at Node.DC, a tale of two node.js apps, I sarcastically responded to a “what should we do next month” inquiry with the outlandish idea of each attendee writing a small code example to show off a module from the core Node API. The joke, to my surprise, didn’t find itself quickly tossed to the side, but was fleshed out by a few others until, end of the night, it was what we were doing in June. Welp, June has come, the Meetup has happened and despite my worries things wouldn’t pan out, all seemed to go relatively well.
What follows is part recounting for those who couldn’t make it, part reflecting for if we do this sort of MeetUp again.
The Idea
Have every attendee be a speaker by assigning well defined topics at the door. Have each of these topics be related by a common theme. Time box each talk to 90 seconds. Provide some tooling to make this all happen without much waiting around.
This idea comes from PechaKucha, a presentation format where the speaker MUST have 20 slides and each slide should only be on the screen for 20 seconds. A few months ago Social Tables ran an internal conference where each employee had to give a talk about the Event Industry.
The Module
The thing that I was most worried about was patching all the talks together. Meetups that require slides before hand are better because the organizer knows things are set up and presentations can slide between each other without any problem.
The next thing that worried me was how to enforce the time limit. People like to talk. People think 90 seconds is a life time. People can spend 90 seconds telling you their name. We could not have this sort of thing happening.
To solve these two problems I created a hack of a cli tool called deck-lightning.
This tool takes two things:
- a number of seconds for each slide
- a list of markdown files
Each file is that turned into a slide and each slide is auto transitioned after the provided number of seconds.
This solved the time problem nicely. The tool is a hack I whipped up between sessions at JSConf and needs lots of love, but the files were stitched together and each one transitioned nicely so hack project for the win.
The Hat
Part of my original joke was that we could each just pick modules out of a hat and get to work. Sadly, hats were in short supply so we settled for a coffee table. On the coffee table we laid out slips of paper with core node module names. To help people pick modules that matched their skill set, Jonathan and I invoked the indisputable “emo-sort”, organizing modules by how difficult we felt they were.
As people walked in the door I tried to provide a quick bit of context, suss out their knowledge level of Node and than direct them to the dwindling list of modules. For the most part I think the result of emo-sort was a helpful guide. And while its not as cool as picking out of a hat, it really helped to match people’s skill sets to module difficulty.
The Coding
Once modules were passed out, pizza consumed, beer opened and small chat had, we got to coding. Well, others got to coding. One of the things we decided to do to make sure the examples were a success was to keep a few more experienced node devs free. This let us walk around and help people install node, debug small implementation errors, etc. I think this really helped this meetup become a learning experience.
We had each speaker use gist.github.com to put together their slide. This made it easy for us to blend the slides and have a uniform platform without having to have people install software.
The Gathering
OK. So coding went well. OK. So stitching the files together went rather well (had one but, but last minute additions do that ☺). But when it comes to gathering the gists there is a need for LOTS of improvement.
Admittedly Ed and Dan seemed hesitant about my suggestion that people just tweet gist urls at me and I field them into some local directory. Jon was even worried enough that he forked deck-lightning to handle raw gist urls so my handling wasn’t as crude as copying gist-content into individual markdown files. I didn’t think their concerns too threatening and so completely missed two of the incoming gists. Luckily it was really easy to create a quick second deck for them and we covered their modules at the end.
Next time I think a google form would be wise. This way gists can be tied to the module they are coving and any gathering of social network info can be done at the time of submission rather than the time of module delegation.
The Talks
90 seconds is just right. A few people got cut off, but as we got used to how long 90 seconds really is the speakers adjusted and were able to aptly cover their topic in the allotted time. In retrospect this is most likely because we choose rather simple topics for each person and it is definitely something to keep in mind next time we do this.
A few presenters thought that they were going to get to run their code during the talk. Sadly this is not something deck-lightning currently supports. That said, with runnable.com it might be something we could do in the future.
A slight problem we did have with the presentation format was that each user only got one slide. There were a few examples where a few slides would have let them show off their code better. I’d like to do this via a better integration into gist.
These few bumps aside, I think everyone did a great job talking about their code sample. It seemed like everyone was relaxed. We even had a speaker who had never programmed before!
The Slides
Click here to view the slides.
Future of Deck Lighting
All of this reflecting leads me to feedback for deck-lightning. If you are interested in making any of these happen, please feel free to open a pull request.
- Switch from deck.js to reveal.js: This way a presenter can have a vertical slide chain.
- Parse gists, don’t just script tag include them. This is so the end result can be a single file that will load without internet.
- Display an up-next component near the end of each slide so the next presenter knows they are almost up.
- Play a sound near the end of each presenters time so they know to finish up.
