» 2013 » November
robert | November 14, 2013 ‐ No Comments
robert | November 8, 2013 ‐ 3 Comments
Here’s my issues with transmedia hackathons:
- the emphasis is on the race to end, not the journey
- 48hrs is far too long
- some hackers come with products pre-built
- who is anyone to judge the results?
Transmedia hackthons, storyhacks, transmediaJams – the bringing together of arts and technical people have so far all suffered by framing the event as a competition rather than a collaboration. In fact the bigger the prize for the winning team, so the less collaborative everything becomes: all the teams rush off to their corner space and secretively work away… individually each person doing what they usually do.
In our Interactive Narratives meetup group, one of our members, who likes to be known as Hot Coffee (don’t ask!) wanted to see how feasible it would be to create a transmedia experience in 1 hr that had to be demonstrated to the group in 10mins or under.
The results were an incredible insight. After an hour we performed our 10min experience and it generated so much conversation, feedback and discussion that we could have gone away for another 2 hrs to further develop the idea, came back to re-perform it and then listened to another hour of feedback and so on. And that’s just on a 10min experience!
So here’s how I’d organize a storyjam:
- no more late nights. Let’s work smarter rather than longer.
- no more judges. You be the judge of your own work and use the feedback from the other participants as a yardstick
- no more prizes. The learning experience is the reward.
- Goal: create a transmedia experience that lasts 10mins or under.
Day 1 (assume Saturday)
- 9am: form teams (more below) and explain the day
- 10am: teams collaborate on designing a 10min experience
- 11am: first two teams perform their experience. If the experience isn’t ready then they don’t get to talk about it – this is the penalty for not doing something. With 2 teams, the performance will take 30mins (ok its 20mins but I’m keeping the maths simple), add 30mins per team for feedback – that’s 2hrs gone!
- 1pm: lunch
- 2pm: second two teams perform their experience.
- 4pm: spend another hour re-designing the experiences
- 5pm: Go home and get some rest or go to a coffee shop. I don’t recommend alcohol – drinking lots of water is much better for getting the neurons firing (and your liver will thank you).
Day 2 (assume Sunday)
- 9am:if the teams have been in groups of teams (see note about too many teams) then mix up the groups so everyone gets to see something new. Now the first two teams re-perform their experience. Get feedback. I expect that the feedback might be shorter on the reiteration but let’s stick with 30mins each
- noon: lunch
- 1pm: second teams re-perform
- 3pm: All back together to share learning from the past two days.
- 4pm: Go home.
Nowhere in this format does anyone perform their experience to someone not creating their own experience: there are no voyeurs or passengers. The emphasis on the two days is collaborative, peer-to-peer learning by doing.
Some might argue that 10mins isn’t long enough but you will be incredibly surprised and delighted at how rewarding it is to focus on, say, one beat of what might be a larger piece.
Team size should be 2-4 people ideally with different skills (writer, artist, actor, coder, producer, interactive, no known skills etc.)
If there are more than 4 teams then group into sets of teams.
It’s quite important that someone in the group has a concept they’d like to champion. Therefore it’s best for everyone with an idea to pitch it to the group and have people join that group to pursue it. Anyone that can’t find one other person to support their idea will need to either go home or join a team with an idea they can support – not hang around moaning or trying to subvert the group they join.
*** to be continued ***