Stepping Into The Trap

Nearly 20 years ago I was a bright-eyed graduate student splitting time between Dr. Michael Bush’s ARCLITE Lab and Dr. Kirk Belnap’s National Middle East Language Resource Center. Among other responsibilities, I served as an advisor for those groups’ technology decisions, and those decisions were often complicated by competing priorities and inflated egos (often my own).

Almost all web content at the time was static, just words and pictures, but Drs. Bush and Belnap, and their collaborators across the country, knew that multimedia web content would represent a giant leap forward for foreign language education. The only way to deliver such content over the web was by using “plugins,” third-party programs that would run inside the web browser.

One of these plugins was Macromedia’s Shockwave Player and its authoring system called Flash. Content creators would pay for the Flash application with which they would craft animations, video and audio, and even interactions like drag-and-drop that were not possible with standard web programming. The Flash files would be exported as Shockwave files before being published on the web. Each user who wanted to view the Shockwave file had to install the free Shockwave Player on their personal computers. 

Although Flash seemed the obvious choice for delivering our multimedia content, there were dissenting voices in our labs. Flash content could only be edited in the Flash application, so we would be dependent on Macromedia continuing to sell and update that application. Worse, if the Shockwave Player ever went away, then all of our content would be useless. While we were having this debate, Adobe, the company behind Photoshop and Illustrator, purchased Macromedia. This gave us the confidence to proceed with using Flash because a company like Adobe would never pull the plug on such a popular product, right?

The Trap Snaps

Over the next fifteen years, Dr. Bush would retire, the ARCLITE Lab would be closed, and the content we had produced would change hands a few times. One day, now as a research professor in BYU’s Office of Digital Humanities, I received a call from the custodian of one of the foreign language courses we had created. “Yeah, so the course isn’t working anymore because Adobe shut down Flash and Shockwave. Is there anything we can do to recover the content?”

The answer was, is, and will nearly always be, “I’m sorry, no.”

Lessons Learned

In an age where technology seems to move so quickly, we may be prone to congratulate ourselves for creating content that was still useful 15 years later, but that’s not that long for well designed instructional content. I would rather argue that we were shortsighted for buying into a non-standard, proprietary technology such as Flash. Yes, Adobe is a massive corporation, and they’re not likely to go away anytime soon, but our investment in Adobe’s Flash didn’t even account for a rounding error on their balance sheet. They were not concerned with our needs when they decided to stop maintaining Flash.

Having learned from this and many similar experiences, I now ask one question of all new digital tools:  “How do we get our content out of it?” This question often shocks administrators because they assume I’m planning for the new tool to fail, but contemplating exit strategies for software is not planning for failure anymore than bright green EXIT signs portend a conflagration. And, even if there is never a fire, the signs are still useful when you decide to leave.

The more content we develop in proprietary systems, the more we come to depend on those systems. And this dependency is a greater danger than the threat of the software ceasing to exist. Such vendor lock-in means our content is held hostage, and we’re less likely to transition to other software even if that other software is better and cheaper. The more content we have locked into the proprietary software, the higher prices we are willing to pay to maintain access to our own content.

Principles to Avoid Lock-In

More than a decade ago, a DigHT student created an electronic edition of King Lear that included unpublished annotations by Arthur Henry King. King had made those annotations on his personal computer in the 1980s, and he had saved them to 5.25” floppy disks. Because King used the open ASCII standard for text encoding and saved them to his own media (the disks that were later discovered among his papers in the Harold B. Lee Library), his annotations could be published 30 years later.

This is why “openness” is one of the values of our Digital Humanities and Technology program: “DigHT courses teach—whenever feasible—free and open-source software that conforms to technology standards and that students may access without subscription.” This value does more than save students money; it teaches them to favor software that keeps their data accessible and usable for many years. 

Most of the computer languages we teach (HTML, XML, CSS, JavaScript, and SQL) are governed by standards that will assure the students’ code will run in the future. When we teach Python, we require students to conform to PEP 8 style guidelines. When we use proprietary software (e.g., Adobe Creative Cloud), we require students to export their work into standard formats (JPEG, PNG, MP4, PDF, etc.). We adhere to these standards not to be pedantic, but in acknowledgement of the liberating bonds of technology standards. 

ODH Efforts

Recently, ODH has transferred or recreated content from less-accessible formats to more open, standard, and enduring formats (e.g., HTML5, CSS 3, ECMAScript): Dr. Robert Reynolds helped restructure a set of Flash-based Japanese Activities, originally created by Dr. Masakazu Watabe. ODH Lead Developer Tory Anderson is overseeing the translation of Dr. Willis Fails’ interactive course packets in Spanish and Portuguese from Flash-based PDFs to a more stable and web-accessible format. The new versions of these instructional activities will work for decades to come.

Though these efforts give hope to scholars and teachers who have years of work tied up in unstable or dead technologies, ODH can also offer counsel—born of our decades of experience—to faculty as they begin their own technology projects. We hope to help others avoid the mistakes we have made in the past.

Jeremy M. Browne, PhD, is an Associate Research Professor and Coordinator of Digital Humanities Education in BYU’s Office of Digital Humanities. His research and development activities include multimedia dictionaries of Quechua, collections of short stories from Victorian periodicals, and best practices for healthcare NGOs working in Haiti.