In 1997 I was a developer at an advertising agency in the early days of the web world. I built interactive kiosks and cd-roms etc with a great team that I’m still friends with today. At that time internet content was thin, almost everything was about creating infrastructure. It was a technology-lead world. Once a technical infrastructure was made, developers looked around for content to fill it with. Everyone needed “content providers”. The cart was leading the horse.
It was in this era that I first came across the Apollo Lunar Surface Journal, which although updated regularly is technologically the same website today that it was back then. It was enthralling. Here was a website where content came first, and what amazing content it was. I couldn’t believe the volume and depth of the information on the site. Back then web audio was ruled by RealNetworks and ALSJ had realaudio and tiny thumbnail video clips of some of the Apollo missions. You could listen to an audio excerpt and read along in the transcript, transporting yourself back to the late 60s and early 70s listening to the men and women of Apollo take risks and work problems–you can still do this today.
I would occasionally revisit ALSJ over the years (later also discovering the ALSJ’s sister site, the Apollo Flight Journal) and in 2001 I started to imagine what could be done with all of that rich content if newer multimedia tools were used to tell the story more accessibly. I built a prototype in Macromedia Director that used the transcript timeline timestamps to scroll the transcript automatically as an audio clip played providing the timing.
It worked, but as any good prototyping experience does, it illustrated to me just how immense the task would be to create a multimedia experience for an entire mission:
- The audio clips were incomplete and spotty
- The audio clips had been edited by the people contributing to ALSJ to remove dead air. This made them useless for establishing a timeline
- The transcripts were in HTML, needing to be translated to a workable data format manually
- The timestamps were inaccurate
- The transcripts contained many errors, introduced either when originally transcribed by typewriter in the 70s or in scanning in the 90s
These were only the data issues. I also needed to come up with an interface that would allow someone to scroll through a mission that was a week long, displaying photography, video, and technical notes for any point on the timeline. I decided to mull this over and consider my options, that was 10 years go and I’m still mulling.
The scale of the work required to execute any version of my multimedia Apollo project idea was always the biggest deterrent to getting started–or at least the biggest distraction from any starting point. I would think of ways to cleanse one part of the data, then would remember that I would have to do it for hundreds of pages of transcripts. What if I missed a detail in a step that would cause me to have to do it all over again? etc etc
In 2010 I came across the spacelog.org website. This site is contributed to by a small group of people on a google groups mailing list who are space flight transcript enthusiasts (yes, there’s a group for everything). They had done a lot of work digitizing the transcripts for many of the Apollo missions using a componentized approach–the transcript data itself was separated and structured differently from the display of the data on the site. This is modern web development in action, in contrast to the ALSJ’s HTML pages where the display layout of the pages is also the data itself making it very hard to work with.
I was immediately interested in the tools and techniques the Spacelog guys had used to store the transcript data. Depending on how clean and accurate the data was I thought I might be able to repurpose the Spacelog data format for use in a multimedia app thus fixing a few of the data source issues I listed above.
I joined the Spacelog google group and enjoyed the conversation with the site developers and transcript enthusiasts. As time went on it became apparent that even if I used the spacelog data format, the effort required to make a multimedia mission reconstruction would be enormous. But I also realized that I might actually be the right guy to take on the transcript problems of one of the largest mission challenges in the books: Apollo 17
Apollo 17 was 13 days in duration and the transcripts are 4,300 typewritten pages in length. Also, much of the mission audio was just digitized and released in 2010 via the Internet Archive. Digitizing and restoring the timeline of Apollo 17 would be a mammoth undertaking.
I thought I could help because I have spent years as a software and web developer. My formative years were an era where web technologies were still new and in flux. In the 90s every new project usually meant learning a new language. Even the largest projects were small enough for one or two people to finish in a few months. This was the era of “code until it works, and make it work no matter what”. In short, I was trained by my environment to be what coders refer to as “a hack”. I always got the job done somehow on-time, but it wasn’t always pretty. But pretty didn’t matter because, in those days, nothing lived long before being built all over again.
Considering the mission materials I had to work from and the ecosystem of tools and techniques I could apply to the task, I thought I had a good chance of automating a huge amount of the work. In short, digitizing Apollo 17 would be the ultimate hack job which is fine as long as the resulting timeline and transcript are correct and digitally accessible.