Tracking Changes in Digital Publishing

Photo by Rodger Evans. CC BY-ND 2.0 via Flickr.

A digital publishing program like ours, which prides itself on being platform agnostic, offers exciting potential for variety in the look and feel of final publication formats but also ensures that some of the production processes typical within a press can never be completely standardized.

As I mentioned last week and will write more about in the future, we have a responsibility to host the projects we publish, and while that hosting environment might be centralized, the process of migrating a project there from its development environment is very much determined by its underlying structure. There isn’t a set of steps we can apply to all the projects in the production pipeline because each project requires a different approach.

The process of copyediting a project must take into account the format and structure of the project.

Likewise, the process of copyediting a project must take into account the format and structure of the project. SUP, like any other established press, has a pretty streamlined process for this stage of production when it comes to books. Page counts normally indicate a ballpark timeframe for how long copyediting will take, and most professional copy editors are already familiar with the file types they’ll be working with. They are presumed to know how to leverage the affordances of basic software like Microsoft Word to manage and track their work. In other words, in most cases, a trained copy editor with a knowledge or specialization in the subject area knows exactly how to handle a manuscript and get the job done.

But what happens when the manuscript has been composed in an online publishing platform like Scalar, Drupal, or WordPress rather than with traditional word processing software? What if the “page” count ranges anywhere from three hundred to two thousand? What is a page, anyway? Is it only something that contains human-readable text or that has a unique url attached to it? Is it anything with an html or txt extension? And if we’re shifting from the idea of a page to a file, does it include source code files? To what extent should a source code file be edited? Should this be part of the copyediting process? Or is this process already worked into the project’s development by the author and her team of programmers? Even if source code should be part of the copyediting purview, where do you find trained copy editors with expertise in both the project’s subject area and also in whatever programming language the author and her developers have chosen for the project?

These are questions publishers of web-based interactive scholarly works will need to address, and they’re the ones I’m contemplating this week as I begin planning for an upcoming publication’s copyediting phase.

A good copy editor has experience and knows a book’s subject area… The digital copy editor needs to have a certain level of digital literacy as well.

The reality is that we’re still probably several decades away from a time when we have available a diverse pool of trained copy editors fluent in JavaScript, HTML, PHP, and several major publishing platforms, as well as Middle East studies or philosophy or southwest American geospatial history. So in the meantime, we necessarily need to start with the basics.

A good copy editor has experience and knows a book’s subject area. A good copy editor for a digital project should be no different. But at the very least, the digital copy editor needs to have a certain level of digital literacy as well. The ability to work directly within a platform like Scalar is a valuable skill. A copy editor with experience in web design or blogging will likely have the ability to adapt to a variety of environments like those used for the projects we’re publishing. This means aspiring copy editors should familiarize themselves with these platforms and be comfortable working in applications beyond the basic Microsoft Word.

Of course working directly within the digital publication environment means that editors must track changes themselves. We are currently at work on devising a system for our copy editors by which they can make changes directly within the platform or content files but keep track of those changes outside the platform since, for now, such a feature isn’t quite fully developed within the typical web publishing environment. While Scalar is considering and developing a copyediting function for its platform, most other systems, including custom-coded ones, aren’t built with professional or academic publishers’ workflows in mind. Copyediting is a necessity in a program that delivers quality, peer-reviewed scholarship, so as authoring-platform organizations continue to develop new applications and improve on existing ones, we hope that they will consider the growing need for features that scholars and publishers want in digital modes of scholarly communication.

Add a Comment

Your email address will not be published. Required fields are marked *