In recent weeks both my colleague Amy Lauters and I have been blogging about turning a box of memories she received during her research on wives of farmers into an interactive documentary prototype. We both have perused the box’s contents and have made a loose inventory of what was inside.
The general contents included the following:
- Family history
- Family genealogy
- Memorial Day photobook
- Newspaper clipping
- Church anniversary brochure
- Checking registers
- Composition books
The composition books comprised the majority of the contents. Those books, along with the checking registers, featured a woman named Elsie’s near-daily records of her life. Her entries are often succinct: “Baked” for July 1. Others are slightly more descriptive: “Cleaned kitchen and got things ready for Xmas” for December 21.
These entries, which number in the thousands, boast a wealth of details about Elsie’s daily life for more than two decades.
But they and the other materials raise some questions: What story or stories do they tell? How can they be told through these entries? How will users be able to engage these stories? And what front-end and back-end structures need to be in place for users to engage these stories?
I am leaning toward a database documentary. Within this structure, the materials for exploration are coded into a database. The website interface then offers users means to explore those materials through user queries, directed queries, algorithms, and linking, among other ways. Taken together, these options manage and present extensive information without overwhelming users.
Story structure changes within the database approach as compared to a time-based documentary narrative. Instead of a prescribed order, the data remain open. Multiple storylines may emerge. Multiple themes may emerge. All may contradict each other. All may provide no closure.
That lack of order and closure suggests that the meanings within the documentary database are unstable. Arguably, all meaning is unstable, and no universal interpretation of any text exists. A better term here is “negotiated.” Part of that negotiation is what users bring to the experience.
Another part of that negotiation comes from how the website frames the entries. Backgrounders, timelines, and artists’ statements provide explanation for the materials appearing on the websites and — how’s this for an old-school reference — CD-ROMs.
Still another part of that negotiation comes from the curation process. Items are chosen to be included within the database. An idea or theme guides those decisions. Often, creators make those choices, but sometimes, as in the case of 18 Days in Egypt, users make those choices by submitting their own materials.
In the case of the memory box, for example, we might choose certain entries based on their uniqueness, their adherence to a theme, or their connection to broader contexts. Or, we might decide to add all nearly 7,000 entries.
Either way, we face a lot of work moving forward in preparing the materials, creating the database, and coding the website.
Preparing the materials here means turning the cursive-written texts into digital ones. That could mean scanning each entry as an image, preserving the original handwriting, which uses the Palmer method. While definitely of its time, the handwriting is somewhat difficult to read. The images also would take up considerable space and might slow user searches.
Another option might be converting the handwritten text into type, perhaps including a scanned image here and there to show the original entry. Text makes for easier database creation and management, and it would require less storage space, hopefully making for faster user searches.
Creating the database would be the next step. The preference here is inexpensive but still meeting our basic needs. Another preference is to pay upfront, not a subscription. A subscription isn’t sustainable long term, at least not without grant funding or a more permanent home for this project.
Coding the website can go one of two ways (suggestions welcome if you know a better one). Korsakow is one tool that might be a useful starting point, but I wonder if the data quantity might be too much for it. Another option would be to delve further into the coding, using something such as Python or a MySQL / PHP combination. All of these options have a learning curve.
All of this thinking does bring us to another question: Is the prototype just for Elsie’s story, or could we set up this project to include entries from other people’s archives? More on that as things develop.