Since beginning our collaboration, Gesel and I have shared a number of goals/hopes/expectations for the No Boundaries online prototype archive. Central among these is our desire to create something that connects to the body and liveness and performance. Yet, on its journey to online delivery, even the most stirring and expansive recorded performance becomes a data point in a database. For those of us attempting to make this translation without a software development background, we find ourselves in the position described by Melanie Aceto in Phase I of our progress blog as “having an idea without the ability to do anything else.”
My previous experience of running up against a translational wall occurred when I began to transition from making live performance to making dances for the camera. I had the good luck to begin the journey with amazing film collaborators. However, it was only after I learned to shoot and edit my own work that I could begin to conceive projects that more fully took advantage of the medium. Now, I have the same desire to roll up my sleeves and get my hands dirty in the creative process. But, this time, the bar to learning that new language seems impractically high, and the language itself feels much more foreign.
In a perfect world, Gesel and I would have been able to find a computer scientist collaborator among our academic colleagues. However, we discovered that our vision for this online archive was not in an area of research interest for our colleagues. Graduate computer engineering students were also possible collaborators. But, while our graduate student researchers provide much of the energy and insight that fuels our project, and we expect, support, and applaud their transitions to other work after graduation, the idea of handing over the principal software development to a student who would also transition out of our institutions felt more precarious – exactly because of our own lack of fluency in the language of coding. We were concerned that a graduating computer engineering student might take the keys to the castle with her, leaving us to recreate much of her work.
Because of this concern, we decided to seek and pay for help outside of our universities. But, at the beginning of this process, we did not understand what architecture we needed to build, who would help us build it, or how to find them. Did we only need a web designer? I should mention that all of this research occurred prior to our having any funding, since the “what” and “how” of our project needed to be fleshed out in order for us to write funding proposals; here again, our status as paid, tenure-track faculty at a university mattered in what we could do.
Because one of the problems we wanted to move toward solving was the fragmented nature of online dance content—i.e., how difficult it is to search for dance content online across multiple sources — we explored how existing online performing arts archives were built with the hope of figuring out how to build our own prototype so that it would play well with others. We discovered that the open-source software CollectiveAccess was being used by a number of existing or developing dance and performing arts archives, including those of Mark Morris Dance Group, Trisha Brown Dance Company, Martha Graham Dance Company, Brooklyn Academy of Music, La Mama, and Jacob’s Pillow (Jacob’s Pillow Archives, specifically). While we did not want to copy those resources, CollectiveAccess’s common use within the field increased the possibility of future interoperability and aggregation. We decided to move forward using CollectiveAccess as our content management system (CMS), and to go directly to CollectiveAccess’s developer, Whirl-i-Gig, to help us configure the software for our project.
It is worth mentioning that other open-source CMS’s used widely for digital humanities projects include Omeka, Drupal, Scalar, and the ubiquitous WordPress.
Working with Whirl-i-Gig and CollectiveAccess is proving to be an excellent choice. CollectiveAccess has features and functionality tailored to collections in the visual and performing arts, and Whirl-I-Gig’s expertise with performing arts collections is proving to be a tremendous asset. Additionally, choosing a commonly used CMS has, as we hoped, helped to initiate conversations with other institutions regarding possible future connections.
Going back to my earlier point, I still regularly feel my own lack of fluency in the language of computer science. As I write this, we are building and refining the back-end, i.e. the database in which the collection is stored and organized. We have tentative designs for the user interface, i.e. the front end, but the two pieces are not yet connected. When we make decisions about how to configure the database, it is often difficult for me to extrapolate and grasp what the ramifications of those decisions will be for the user. I am asking a lot of questions and learning as I go.
Published by