Publishing Digital Products alongside Print Books

My colleagues and I at Georgetown University Press (GUP) continually ask ourselves how a publisher can create and release content simultaneously in print and digital formats. We are not alone in asking this question, but for us, digital encompasses far more than an e-book.

Our challenge is creating interactive digital products that complement or stand in place of print products.

As director of Georgetown Languages, a separately branded section of GUP that focuses on publishing foreign language learning materials, I am charged with producing textbooks, reference works, and research-based books for language teachers and linguists. Although books can aid language learning, mastering a language involves more than simply reading books. The subject demands interaction; it demands additional audio and video resources.

For more than six years, we have been creating new media chiefly for Al-Kitaab, a series of Arabic language learning textbooks. Most notably, we created companion websites for the first three of four textbooks featuring interactive, self-correcting exercises with audio and streaming video (alkitaabtextbook.com). These websites were each launched simultaneously with the publications of new editions of the print textbooks, each including an accompanying DVD in addition to all the audio and video files accessible via the websites.

Much of the core content that was online also appeared in the book. This project presented a huge workflow challenge for us. How do we copyedit the text and follow a consistent style? How do we collect comments from the authors and apply them consistently in both print and electronic products? Who at the press serves as the project manager and produces the digital product? Further complicating these questions is the fact that these books contain a large percentage of Arabic content. Arabic is written and read from right to left, and software developers tend to address problems introduced by Arabic last when building products. This directly affects accessibility of right-to-left languages on e-readers, for instance, and makes it more difficult to sell e-books with Arabic and English in them. No one wants to buy an e-book filled with characters or whole paragraphs that appear as empty boxes instead of actual Arabic or Arabic content that is presented in left-to-right sequence. Did I mention that no one at the press knows Arabic well?

So how did we do this? The E&P manager, Deb Weiner, and I put our heads together. Deb served as the coordinator of the print products, art director for illustrations and book design, and coordinator of the replication of the master DVDs. I acted as the de facto project manager and producer of the digital product. Because no one at GUP is proficient in Arabic, I hired someone with advanced knowledge of Arabic—a student intern from the university—to help us better grasp what we did not know and to serve as our in-house Arabic proofreader. Authors were asked to submit the manuscripts as two distinct Word documents—one for print and one for the website. Before Deb received a manuscript, I developmentally edited it, ensuring consistency across products and confirming that the structure was clearly tagged for print production and for digital template application. I worked with the authors to create a log of needed illustrations and to catalog and create the thousands of audio and video files the authors had to record and submit. To log everything (art, audio, video files), we used tables in Word. Efficient? Not really. Buggy? Yes. Accessible to everyone at every stage of the project? Yes!

Why did we not use an XML or another flexible workflow? Why did we rely on Word? Why did we silo our workflows?

1. Time. We needed to move quickly because the last edition of the book included a DVD that quickly became technologically problematic and caused customer service issues. It made sense to move everything online, but we needed to reach the market before other publishers did. Because these textbooks are used on a specific timeline, the books needed to reach the market with little to no gap for students who changed editions. Further, the authors were still conceiving of and receiving guidance from us about what was technologically (and financially) possible. We were still not sure what kind of content we would receive or how radically it would need to be revised. All these factors meant, to us, that we did not have time to find the right tools and workflow before we made decisions about how to move ahead.
2. Language. Most systems are geared toward left-to-right languages, and we did not wish to use our most valuable product as a test case for a right-to-left language. Yes, in theory, XML and other markup languages are language-agnostic, but we have often found that, with Arabic, even small issues create larger ones down the road.
3. Technology. When we started, we did not yet know what the steps would be to create the digital product, and it was difficult for us to conceive of what tools we might need in the coming years. For the same reason, we were very unprepared for how difficult it would be to silo the workflows.

The road was bumpy—very bumpy. Here are some of the lessons we learned:

• Thorough conceptualization and development. Allow a lot of extra time for early development prior to production. The more you can do developmentally, the more smoothly production will proceed. We developmentally edited the material for structural consistency; copyedited and tagged everything in both manuscripts thoroughly (especially crucial, as the books were not all in English); and created detailed logs of all audio, video, and art and tagged their placement in both manuscripts.
• Single source. By the third book, the authors and I agreed that they would only submit a book manuscript, tagging elements that they intended to include online. I developmentally edited the print book and then pulled the relevant elements out to create the online manuscript, eliminating multiple reviews. If you eliminate redundancy, you reduce errors, workload, time, and cost.
• Invested authors. Make sure your authors are invested in the end product, understand the challenges, and are excited about the prospect of a digital component. To be successful requires even more work than just creating a print book. You need the authors’ vision and ability to push the envelope in their field in order to create something new. Especially if the content is in another language, you will need their expertise to review it at every stage.
• Repurposability. Build a digital product only once. Avoid making one-offs, where the functionality only suits a single product or content type. Use templates that are flexible enough to use for a variety of products.
• Expertise. Hire or develop in-house content expertise. Depending on the subject, this could be the acquisitions editor, or it could be an intern or editorial assistant dedicated to the project. There are things only experts can add or envision about their field, catch when reviewing online materials, and understand about how experts and students might use a digital product. Do not underestimate the value of subject expertise to a project’s success.
• Single project manager. One person needs to be able to keep the big picture in mind. This requires an awareness of the full scope of the project and an understanding of the implications of decisions and changes made to the content, whether it appears in the digital or print edition. For us, oversight meant that I reviewed every requested change to the printed book. For example, each vocabulary list was in the book and online, and each word had an audio file associated with it. The author might correct the book and forget to correct the website—or would forget that a correction required a new audio file for the website and for the disk that came with the book.
• Single repository. Think about digital asset management (DAM) and content management before you start. For us, this was not simply about version control; it was also about tracking thousands of audio and video files for distribution on two platforms (disk and website) and managing the final formats of various media (illustrations in .jpg and .pdf, as well as video in .mov, .mp4, and .flv) in a DAM archive. I created a FileMaker database where we logged finished files and maintained a DAM archive of those files on our server. The benefits of asset management go beyond efficiency in the production process to ongoing usability of those assets. For instance, the marketing department can locate our assets to use them in campaigns and to answer customer inquiries.

In retrospect, there are many things we could have done better, and there are many tools that might have helped us over the past several years. We are actively discussing workflow options at the press with these experiences in mind. Our focus is to make it more efficient and to fully integrate digital (text and other media) production with print. This is a huge task. These lessons we have learned will help us make a more informed choice and rethink what our best workflow should be. GUP will continue to publish complex multimedia products for print and digital distribution for the foreseeable future, and we know we need to find new, efficient ways to do that.

Did You Know?

• MS Word’s AutoText feature allows you to store your frequently used queries or comments so you don’t need to retype them. It’s efficient, encourages consistency, and reduces typos because you don’t have to rethink what you have to say to the author or your colleagues.
• When conceiving of projects, more and more it’s important to consider multiple uses for things. Be sure to think about how an element (e.g., a table, or list) will function in an e-book, or on the Web. And while we don’t always control what goes into a book, frivolous elements should be avoided—especially if they will not translate well into a multipurpose publication.
• When you are working with electronic publications, it’s best not to ever remove content. Instead of deleting information, it’s best to use the comment tags.