tMoRPH Hackathon

Gathering of invited participants to explore hack solutions to developing technology based art for consumption in low-bandwidth environments.

Description of User Experience:

Virtual Hackathon with events and efforts distributed across a full week of activities.  Kick-off, team formation, self-organized development efforts, mid-week progress presentations, final presentation and discussion.

Content Type: 

Idea generation and solution exploration for digital mixed reality art production in remote low band-width locations.

Identified “Best Practices” for Mixed Reality Production:

• Personal investment in the project is a key factor for an educational and collaborative experience. 
• Remote working is a great opportunity for international collaborations.
• A dramaturgy that treats the spectator as a participant is necessary in XR performance.
• Artists need to accept structure and facilitation, especially in complex technologically mediated projects with tight deadlines. Without structure and facilitation, there is not enough time to come to a consensus on a creative direction.

Important Lessons Learned for Hackathon’s:

• It was noted as a positive aspect of this Hackathon that it accommodated a broad range of schedules and lifestyles. It is important to acknowledge that self-care and relaxing activities are an important part of the creative process, and the relatively relaxed atmosphere of this Hackathon allowed for this kind of acknowledgement.
• While spontaneity is valued by the artists involved in the Hackathon, it may be useful to allow creators to choose the projects ahead of time. This way, artists would have an opportunity to think about which projects best align with their interests.
• Coding is not necessary in a Hackathon! This time is best used to explore creative ideas, rather than to perfect technology. There is not enough time to solve complex technical problems.
• There were many participants with a theatre background, and not many participants with a coding background. Future Hackathons should represent a greater variety of skillsets.
• It is important to make clear expectations about the shape of the creative process in Hackathons. There is often a brainstorming period, followed by a period where many ideas are cut so that the project can be completed by the deadline. This period of cutting can be emotionally taxing, though it may be less so if participants anticipated it.
• Scaling up is possible with a larger support team of mentors and moderators. It would be possible to have a public audience if the theme were well thought out and the expectations were set. Tripling or quadrupling the amount of participants is possible.
• People with coding experience all ended up in one group, making it so that most group’s had no coding experience. However, the only solution to this would be to assign coders to groups, which would inevitably result in coders not being as invested in the projects. This is a difficult problem!
• Some participants undersold their own skills on the application forms. For example, some who reported that they were not tech-savvy were, in fact, tech-savvy. This meant that it was not always clear who should be approached for help in a particular area.