Posted on Thu 26 May 2016
What's Magic About a Magic Hack?
We recently ran the world’s first magic hack, bringing together magicians and technologists for 2 days to develop new ideas. I’ll be frank, we had no idea if it was going to work....
We recently ran the world’s first magic hack, bringing together magicians and technologists for 2 days to develop new ideas. I’ll be frank, we had no idea if it was going to work. We were hoping that people may generate a few new ideas for tricks, and if we were lucky some distinct products that people might go away and develop. What I wasn’t prepared for was the tidal wave of creative possibilities that the event produced. The final show case featured everything from mind reading gongs, voodoos dolls, possessed picture frames and balloons that exploded on command (read more here). But the depth of ideas that were produced over the 2 days showed that the ideas that made it to the showcase were just the of the iceberg.
We thought hard about how to bring together these two, distinctive, different communities together. So in the interests of sharing and learning I wanted to put together the lessons we learnt about why we thought it worked. We've put together 7 steps to making a magic hack...
1. Curated group of amazing participants
The primary secret of any successful hack is the people in the room. We were lucky enough to have an amazing group of people for the 2 days. But saying ‘amazing people’ is not much use if you’re trying to organise your own hack(!) So what helps bring out the amazingness in them?
Individuals who brought an attitude of openness and were willing to collaborate with others
The people who came were all interested in being open and working together with others. We spoke to everyone who expressed an interest in coming to the hack to ensure this was where they were coming from. Given the interest we had, we could have had a ‘turn up if you want’ approach, but we wanted a smaller group of curated individuals who were committed to collaborative development.
We were very clear from day one that the spirit of the hack was about collaborative development, NOT technical people there to build things for magicians, or magicians there to show technoloigsts how to do tricks. This arose from recognising that both disciplines had something to offer the other and formed the basis for the spirit of collaboration. This ethos of equal collaboration was reinforced in the guidance we sent out before the hack and during a presentation on the first morning of the hack itself. On a very tangible level, we also strove to get an equal balance of magicians and technologists in the room and give equal time to introducing technology and magic concepts.
Range of skills and talents
Within the individual disciplines, we had a range of individuals with different talents which meant we had a very diverse range of skills and experiences in the room.
From a tech perspective we had people with different specialisms including hardware and software, meaning we were able to be more flexible in the thinking and development of effects. From a magic perspective we had magicians who specialised in a range of different performing environments including everything from corporate mentalism to children's and family magic. This meant we could develop effects for a range of audiences and situations.
2. Active roles of equal status
Both groups had an active and equal role to play throughout the hack. Whether it was in the introductions, design process or build phase. We wanted to avoid the feeling in hacks that ‘the techs are building now so there’s nothing we can do’.
Two things helped achieve this:
Firstly designing in a role for both participants throughout.
During the early stages, a key part of this was the collaborative design process. Rather than have people put forwards individual ideas which might have veered towards being over techy or over magical, we wanted them collaboratively develop ideas using the best of both worlds. We also wanted the magical and technical thinking to have equal status. To facilitate this we created a design card deck. This had 2 packs, 1 pack of magic effects (taken from a taxonomy of magic), and 1 pack of technical cards. The technical cards broke down the possibilities into ‘inputs’ (e.g. touch), ‘outputs’ (a motor moves), ‘brains’ (computing functions, like a decision) and materials (e.g. wood). The group would take 1 card from the magic deck and 1 from the tech deck and see what magic trick they could invent by combining the two. People could add more magic or tech cards if they felt an effect couldn't be formed by the cards on the table. I think the exercise could be useful in other sectors, if you replaced the magic cards with any issue you are interested in, e.g. if you are interested in smart cities you could replace the magic cards with cards with public spaces on them and explore combining public spaces and magic.
A further key part was ensuring that the ideas for magic effects that were taken forward and built balanced the 2 worlds. To achieve this, we asked 1 question of every idea that the group wanted to build ‘Is it both technologically and performatively possible?’ i.e. can it be done and would a magician actually want to perform it? A positive answer to this meant magicians and technologists were more likely to be involved in the builds as ideas had to be considered from both angles throughout.
On a very practical level we didn’t have rigidly fixed groups, but did have clearly marked project spaces. This meant that individuals could move between groups and provide help where it was most needed depending on the stage of development of the idea.
3. Structured collaborative design process in the first day. Loose and open structure for the rest.
Like a good pair of flares. The start of the hack process (first half day) was defined and structured, but remainder (day and a half of building) was very open. This meant individuals were supported to design and work together when people were at the early stage of the hack and getting to know each other, but left alone to build when they begun to develop groups.
Particularly important points were:
A group session at the start of the day where we could explain the ethos and purpose of the hack
Enabling as much mixing as possible so that people were able to chat and get familiar with as many different individuals. The purpose of this was so that people didn't just fall into groups of people they knew or happen to have met over coffee, but rather followed the ideas. We did this by
Having a 30 minute unstructured meet and greet at the start of the day
A ‘meet 10 new people in 10 minutes’ session after the opening presentation
Two collaborative design sessions using the cards, but we mixed up the groups each time
Whole group discussion around which ideas were taken forwards
Making building groups open so that people could move around groups. Most ideas were collaboratively designed so a large number of people had ownership over them. This meant that while a core often stayed with a group, everyone was free to move around during the day and a half of building, and had some familiarity with each idea.
We strengthened this by having quick check ins at the end of the first day and start of the second where people explained the magic effect, and underlying technology, and asked for help if it was needed.
Social drinking and eating (shared tea break on the first day, buffet lunch on both days, beer and pizza on the first evening)
4. Wide range of equipment available
We ordered a lot of kit in for the hack. While there was not a large supply of any one thing, there was lots of variety so that people could try different things and have choice. Most of it was inevitably unused, but it did mean when someone wanted a flex sensor or electro magnet, we had one available to use as a proof of concept
We were also lucky enough to have a good connection to the place we were working in and good social capital meaning than when someone said 'I need a gong’, almost inexplicably we could get one within an hour.
5. Design fictions and use cases
As well as technical feasibility one core question was asked to vet every idea, can it be performed? Does it have a performing home? This meant that when the final sharing happened it was a mini performance of effects, rather than a description of what happened. I think this was really valuable as it meant that people got the effectiveness of the idea in use and kept ideas really practical throughout.
We had 2 people to help document, 1 from an event perspective (e.g. writing a blog, retweeting, making a storify), 1 from a tech and narrative perspective (writing up and documenting ideas that emerged). If I did it again I would have more people to document the tech and narrative, ideally 1 for each subgroup in the design sessions. The documenting of ideas is so important as so many good ideas emerge from hacks, but stay in the room.
7. Support staff
As well as the documentation need, there’s always a job to be done. Someone needs something, you need to sort out lunch, find tools, hand out Haribo, whatever. Having lots of support staff is invaluable and means the participants can focus on building and being in a flow state, rather than being drawn out of it for logistical reasons.
So there we go, 7 steps to a magic hack. But I hope they'll be more widely of use. What are your tips for hacks? Do they reasonate or have you got different experiences?
Open source magic is turning out to be a little more challenging than I first thought.In preparing for our magic ‘hack’, I've made a number of personal and broadcast invitations to magicians. How people have responded has...