> For the complete documentation index, see [llms.txt](https://secondwavedigitaltheatre.gitbook.io/flinders-phd-research-project/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://secondwavedigitaltheatre.gitbook.io/flinders-phd-research-project/spotlights/fast-prototyping.md).
# Fast Prototyping
One of the reported struggles theatre makers experienced when working in a digital space is the need to *prototype* new tools. In technology development, [prototyping is important](#user-content-fn-1)[^1] ‘at some point of the development cycle to perform hardware/software validation or test interfaces to real-world stimulus’. Similar to the rehearsal process, prototyping allows companies to test methods that they believe will work, but which might lead to new discoveries or highlight problems that need to be solved.
Much of the second wave digital theatre I have discussed uses existing tools like Zoom or VRChat which are familiar enough to theatre makers and audiences without extensive testing; however, some theatre makers have created their own tools, which required dedicated testing within a rehearsal-like context to ensure the products work. [Clemence Debaig](/flinders-phd-research-project/appendices/research-participant-information/interviewees/clemence-debaig.md) said: ‘you can't just take the way we used to make theatre, and then just add tech on top of it. You will have to change the ways of working massively'. She noted that this was a struggle when working with some types of venues, festivals, producers, or performers, who had not found a new workflow for prototyping their show and testing the technology.
Theatre makers had to learn to quickly switch into new technologies or pivot between performance options, so many now think about prototyping work in several formats or using quickly-made tools. They also needed to consider budgetary constraints, a common problem in traditional theatre as well. [Per Myles and Pye](#user-content-fn-2)[^2]: ‘When you are creating your prototype, it is important to find the best tools available without spending money to execute it’. This process typically requires extra time and dedicated attention, as researching and trying tools, or even making tools from scratch, is an important part of intentional integration of digital tools into theatre. [Josh Coates, theatre maker and writer of the Substack newsletter *etude*](#user-content-fn-3)[^3]*,* considers the dual struggle of making digital theatre during the pandemic:
> We made it \[[*Sunday Morning*](https://joshcoatestheatre.cargo.site/Sunday-Morning)] on a shoe string budget and it felt rushed and unfinished. We needed the financial resources to develop the technology involved. It was a complex show and trying to do it in a diy fashion just didn’t work. And why would those who work in digital worlds want to collab with theatre makers? There’s a lot less money involved.\
> \
> When talking to fellow artists who were looking to make more ambitious online work, they shared this frustration. They needed the money and time to develop their performances with a team of creative technologists or programmers and they were being pushed back time and time again.
While theatre makers upskilled a great deal during 2020 and 2021, many of them faced significant hurdles in the amount of funding and types of technology they had access to. Most persevered on a small budget, which could lead to wonderful, unique, and creative performances, or could lead to low quality shows. The results were hit-or-miss - this section aims to discuss these developments and offer options for support. Other producers supporting technological / theatrical development include [Brendan Bradley ](/flinders-phd-research-project/appendices/research-participant-information/interviewees/brendan-bradley.md)who founded the Integrative Technology Lab at NYU focused on helping students develop their processes for using new technologies from a creative perspective: ‘how can you bring a game mentality, dance mentality, a filmmaking mentality, a drama mentality to using this technology?’ Groups like [OnBoardXR](/flinders-phd-research-project/appendices/research-participant-information/field-research/onboardxr.md), Streamed Shakespeare, and ‘The Show Must Go Online’ stumbled into development and rehearsal processes that worked for them, after about a year figuring out how to train in and document their tech development processes. Here are some issues that arose that might impact the ability to quickly prototype a technology for your show.
[^1]: Borgstrom, T., Haritan, E., Wilson, R., Abada, D., Dauman, A., Chandra, R., Mielo, O., Cruse, C., & Nohl, A. (2009). System prototypes. *Proceedings of the 46th Annual Design Automation Conference*. p. 1-3. .
[^2]: Myles, R., & Pye, V. C. (2023). *Innovation & digital Theatremaking: Rethinking theatre with 'The show must go online'*. p. 37. Routledge.
[^3]: Coates, J. (2024, November 29). Thursday 28th November 2024: the 76th etude. *etude*, (76).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://secondwavedigitaltheatre.gitbook.io/flinders-phd-research-project/spotlights/fast-prototyping.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.