A little over four years ago, my father died. He was, as many have said of him, a force of nature. Short and portly, with a dark shock of hair worn proudly wild, he told rambling, exaggerated stories. He overindulged. He played a passable clawhammer banjo. He sometimes alienated people with his strong opinions. But he was wildly creative, and the work he did in exhibit design left a permanent mark on the field. In the weeks and months following his death, I found myself wanting to document all this.

His life, not mine

Drowning in the emotional soup that is losing a parent, I was hesitant. My writing was unorganized and fragmented, and I was worried anything I did would become too much about my own experience. I’d started sifting through photographs, noting how Michael’s physical appearance changed so dramatically over the course of his life. It occurred to me that simply creating a timeline might be the way to start. Perhaps focusing on the defining milestones in Michael’s life—career milestones, marriage and children, actual events over my own memories—would keep the focus in the right place.

I chose Timeline.js, a nicely flexible open source tool for creating customized timelines. It was easy to manage, and it allowed me to capture both personal and professional eras and specific events in his life. But the words I was using to describe these events were still mine, and it felt lopsided nonetheless. I wasn’t trying to recreate my memory of Michael.

The solution, I realized, had been flooding in for weeks. It came in the form of those stories and memories and reflections from the people who loved and respected, and even fought with, him. I organized these reflections generally by era, and scattered them throughout the timeline as emotional ballast against the facts of my father’s life.

Over the next couple of years, I’d add additional recollections and details as they came floating in. Occasionally, someone would share details that I’d gotten wrong and I’d make a correction. Ideas percolated. I tried adding an interactive map of his work projects, but ran into technical stumbling blocks and set it aside. Four years later, the site remained largely unchanged since his death. Until recently.

The physical and the digital

I’m not the only one who felt the need to document my father’s existence. For as long as I can remember, our basement was stacked with box after cardboard box of paperwork. Bulk pallets of flat cardboard waited in the corner to be folded into more boxes. Year after year, Michael packed those boxes with his work files. After he died, I found myself staring at around 75 linear feet of paperwork dating back to at least the ’60s.

I started by calling various archives that I thought might be interested in housing the material—RISD (his alma mater), the Massachusetts Archives, the Brookline Public Library. No dice. Turns out storage space is expensive, and so is digitizing physical material. My disappointment was twofold: it was a sting to discover how few people seemed interested in my father’s career—something that loomed so large to me having grown up watching it unfold. Beyond that, though, I knew there must be tons of culturally valuable material in those boxes, historical material that might never see the light of day. Defeated, I moved the collection into storage and continued closing out the estate.

Clearing out my father’s belongings was a daunting task. Reams and reams of randomly-sized copy paper. Broken toys, wind-up toys, wooden toys, books about toys. Boxes of old cell phones, walkmen, remote controls, laser discs. And then I found the short stack of DVDs. I knew immediately what I was looking at, and a sense of relief hit me.

Several years prior, Michael had embarked on an attempt to digitize the thousands of slides he’d taken over the years. He never completed the process, but he did manage to ship off a huge carton of lord-knows-how-many-pounds, and received these 22 discs in exchange. There is a rich conversation to be had about my father’s fetishization of technology, and the preservation of obsolete media. But when I first sat down in front my computer, my external DVD drive whirring away, pouring through these images, all I could think about was getting them online so others could see them.

Documenting a designer’s world

The discs offer exciting glimpses into the history of Michael’s career and by extension, into the history of exhibit design and even Massachusetts history. We’re talking about images dating back to the ‘60s: graphic design work, curriculum design work, museum installations, and amateur street photography.

Michael’s early work pushed the boundaries of exhibit design and helped redefine the notion of what the museum experience should be. His work incorporated the use of computers and technology to assist learning before the phrase “user-centered design” even existed. I’ve spent hours combing through photos of San Francisco’s Exploratorium, the Boston Computer Museum and the Boston Children’s Museum, the Franklin Park Zoo, the National Scouting Museum, and so many more.

There are scores of images of his work with the EDC, where he helped design controversial curriculum used in 1,700 schools across 47 states, to give more than 400,000 students insight into human behavior. There are classroom photos of workshops held in the DC Public Schools, and photos of Boston City Hall in the ‘70s. There are photos of (what I believe are) Berkeley and Cambridge protests in the aftermath of “Bloody Thursday” at People’s Park, and photos of the very first Great Boston Kite Festival, of which he was a co-founder.

His work explored race, poverty, pedagogy, urban development, government, technology—subjects we’re still grappling with in major ways today. I immediately bought a hard drive, and transferred over all 14,000+ photos.

A content strategist’s approach

Between then and now, I’ve been slowly chipping away at turning this hard drive of images into a functional proof-of-concept for a searchable archive. It’s been slow but incredibly rewarding, and being a content strategist has been a mixed blessing throughout. On the one hand, I know how to handle large collections of content. Something as simple as identifying the project depicted in a set of images raises a host of questions around metadata assignment and taxonomy, for example. Get too far into the work without answering those questions, and I could find myself having to rewrite metadata for thousands of images. Because of this, I mapped out a systematic approach:

• Review the collection
• Map the subject domain
• Choose a metadata schema
• Choose a database platform
• Prepare content
• Implement MVP
• Test, expand & iterate

Of course, being a content strategist by trade makes it painfully easy to overthink each one of those steps. And practically speaking, the process has been far less linear than my initial plan called for.

I’ve tried to channel one of my hardest life lessons: don’t let perfection be the enemy of good. After doing a lot of reading and research into professional archival processes, I have just enough knowledge to keep my wheels spinning, and at some point I had to just stop reading and start building. I made a few key functional decisions:

Platform
I had a long list of technical requirements, not least of which included: being open source, having an active support community, the ability to manage large numbers of image files and eventually other media types, and offering a user-friendly back-end and front-end display platform. I ended up choosing Omeka, which is specifically designed for museums and archives. It allows me to customize both the design and functionality of the database (to the extent of my ability), and is flexible enough to accommodate strategic shifts around metadata and architecture. I’m not convinced this is the best long-term solution, but it’s working for now.

Metadata & taxonomy
There are a number of reasons to use an established schema for this collection, including maintaining interoperability should I want to integrate the material into another system. Omeka’s out-of-the-box schema is Dublin Core, and I’ve stuck with it for now. Based on my initial content models, it works well enough but there are some gaps. I’ve also had to define a fair number of controlled vocabularies to ensure consistency across such a large collection. Project discipline is just one such vocab, which includes terms like educational curricula, exhibit design, signage & environmental design, and so on.

Account gate
The initial prototype required an account for access. This was initially intended to help with early usability and beta testing, but I’ll likely make accounts an optional function in the future [ed: As of March 2018, I’ve ditched the accounts so visitors can dive into the collection right away]. Philosophically, I’d like to err on the side of open accessibility and an account requirement undermines that.

Sample size
I opted to start by adding only a small number of projects to the prototype. Assigning even basic metadata to an image, like location and date, can require a fair amount of research, which takes time when there’s only one person on the job. Keeping the sample size small meant I could actually get something live much sooner. Of course, that assumes it’s critical to have basic metadata complete before adding the images to the archive, which is an assumption I’ve started to question (but that’s for another post).

Of course, I have an unending list of things to tackle. I’d like to revisit the initial content modeling I did, which will impact the metadata schema and vocabularies I’ve been working with. As I learn how people discover and navigate through the material, I’ll continue to adjust those to make access even easier (Omeka makes this relatively painless by allowing me to edit the collection’s metadata in bulk). The front-end design of the archive is probably the hardest for me to let go of. It’s a very conventional design, with limited functionality; all you can really do is flip through the images, one by one. Kind of a snore. Pages are built using PHP, similar to WordPress, so any design customization I do is limited by my nearly non-existent PHP skills.

This is always the way with personal projects. I’ve come to terms with the reality that this will likely never be a “finished” product. I have big constraints. But I also have big ideas and, better still, I have a compelling collection of material. As clunky as this first iteration is, I’m so happy to be able to share it, knowing that it’s one tiny step towards getting Michael’s life work online for anyone to explore.