When I first started designing, I took handwritten notes. Scribbles, really. Each note said something like “dloor up 7 after…” I have horrible handwriting under pressure in the dark. Also, I didn’t write very quickly, so I’d leave a lot of trailing sentences as the play progressed and new cue mishaps grabbed my attention.
Frankly, I didn’t yet have a process, and I was designing in a panic. I used notes as shorthand to trigger my memory of what happened particular run, and then doing the notes meant reconciling that memory with the director’s divergent memory and then taking an appropriate measure to correct that cue for the next run.
The problem with me and this method became clear the first time I designed my annual summer juggernaut - the ten repertory shows of Cherubs. Each show ran an hour, and teched in an hour and forty five minutes. After tech, I would have one dress run to make any last adjustments, and then performance. Each night you tech two shows, and then the next night you tech two more. At the end of my first week of Cherubs tech I had a pile of incomprehensile scribbles like “Fade out the drone when she does that thing upstage” with little memory of the play itself. I needed a better way.
And I didn’t just need it for Cherubs. I looked at the designers whose careers I wanted to emulate - Andre Pluess, Lindsay Jones, Ray Nardelli, Josh Horvath. These individuals are unbelievably prolific, if you haven’t noticed. I think Lindsay pulled off something like 30 shows in 10 states last year. They worked everywhere, all the time - in Chicago and regionally. In watching their processes, I noticed patterns in how they organized their notes, cues, and files into standard formats and structures no matter how different the show was.
I experimented with excel spreadsheets and text files. The disorganization and lack of clarity continued - though I did notice that I had a speed increase and a greater percentage of complete sentences because I’m a faster typer. So I was capturing more of the same bad information I worked on self-discipline in the moment and looked into some preliminary shorthand lessons. It didn’t click with me. New problems started emerging as I experimented with new methods - I would bring a level up one day only to bring it down again after sitting in a new seat only to bring it up again after sitting in the first seat again. I was pushing and pulling my hair out.
The breakthrough came for me when I thought about the nature of the information I was trying to retain. Levels. Cues. Moments. Memories of the events of a run. Records of previous runs and notes. Whether I had taken care of a note or not. Notes from a director. Notes for a stage manager. Notes for myself.
I decided to create (ta da!) a relational database and see how that worked for me. I broke the information of my work into core models - cues, subcues (like fades and layered sounds in a cue), notes. Five years later, it looks like this:
Not the greatest interface, but it’s been built incrementally with only my brain, so it works great for me. Notes are in yellow there. As a show progresses, I scroll through my cue list. If I have a note, I just type in one of the yellow boxes and I have a quick pull down menu of basic types of notes to give me some quick context - “Director” means it’s something I need to ask the director. Its direct, and in practice, simple. I should note while the data structure is complex enough for me to use this system in every show, it’s also flexible enough that I can ignore great sections of it when time demands that of me. I really only use the subcue table, for instance, when I run using CD playback shows where overlapping sound files still need to be managed. Computerized playback often makes that paperwork more or less moot, so it just sits there.
By capturing the data I also noticed an immediate benefit - separating the data from the display of that data by taking it off a piece of paper or a spreadsheet freed myself to use the data in new and different visualizations. I could create a new layout that automatically created a cue list easy for a stage manager to read:
Or a quick pull list of notes to do in a hurry:
With six or seven shows and some troubleshooting, it became a system that I trust more than my handwritten notes and my swiss cheese memory. It became a way to freeze those pure, immediate reactions that I have in the space and in the moment and use those to inform my notes. And since I began analyzing the way that I captured information and the structure of the information that needed to be captured, my handwritten notes have become decidedly more disciplined and focused.
But that’s what works for me. What’s important is the way that you structure your own capture. You need a way to capture all the relevant data that you can fit into your bucket, and a way to intuitively and simply filter that information later. We are flawed creatures, and it’s not only possible but likely that at some point you’ll try to fool yourself into thinking you took one action when you took another.
There was another important capture that took place in recent months - the company members of the side project sat down and captured through a brainstorm all the roles and responsibilities of the company so that we could better enlist and provide support to Artistic Director and theater operations superhero Adam Webster. By capturing and filtering the things we did as individuals over the course of a season, we began compiling a bible of simple manuals for tasks and procedures that were involved with running a theater - everything from filing taxes to taking out the trash to repatching the lightboard. We took this information out of our cluttered minds and put it in a repository where anyone can come in and take over, and in doing so the problem of “running a theater” became smaller and more manageable. When you look at the life cycle of company membership, that kind of capturing and filtering process creates institutional knowledge that is the difference between the life of a theater company and its demise.
This is one of the reasons that I think creating a database of Chicago Theater is a worthwhile project and not simply navel-gazing. It is made up of collected and searchable and therefore endlessly useful data. If it is successful, it creates a model for other public resources of data in the theater community that by necessity would be more accessible than say, TCG’s data that Scott Walters used to such great effect. It captures hard facts that can be organized to suit your purpose that day. It allows us to check things that we believe are true (”You know what Chicago needs? A production of Our Town in April 2009!” They’ll never know what hit them!) against the captured data of collected memory that inarguably is true.
On a side note: Speaking of manuals, I’ve been exploring the utterly hilarious Poignant Guide to Ruby in my learning process of the Ruby on Rails programming environment for the CTDB. I think the devilvet in particular will appreciate the use of off-the-cuff cartoon foxes and elves to spice up the process of (yawn) learning a programming language.
When you’re reading and writing a manual, I cannot stress enough the importance of retaining your sense of humor. This is the thing that I often forget.
Now before I get all mission accomplished on you, we still have a long way to go yet. This is another “sneaky peek / prototype / call-it-what-you-will” in progress program. We have structured the project to be more or less open source and community-driven, which means that the version you see now is a) ugly and b) in progress and c) read-only during the beta test period. The view mechanism and the data we’re assembling, however, is pretty robust. Dan Granata and I have assembled a team of beta-testers/contributers who are AS WE SPEAK playing and testing with the input forms and getting all the kinks worked out while they upload new data. Watch Dan’s blog later this evening for more info on the beta test program and how you can contribute.
