Three things every editor should know about modern publishing
This was originally a talk at the Professional Editors Group in Cape Town in 2017. I’ve since updated it for 2023, mainly to provide up-to-date examples and links.
Today, every passage you edit will sooner or later be read on screen. This digital world desperately needs our craft and high standards, but what does that mean for our daily work? In this talk I’ll pick out three big, important issues, and talk about some of the tools we’re using to tackle them.
- The first is text-only editing. That is, the end of word processing as we know it.
- The second is real-time, collaborative editing.
- The third is automagical pagination: how do we edit when there’s no such thing as ‘page two’?
So what does this digitisation thing really mean for editors? Essentially, it means you’re editing text that will be read on a screen and on paper; and that changes the way we edit.
If you’re going to edit for the screen, the single most important thing is to actually read on a screen yourself. If you aren’t doing any of your reading on screen, you simply cannot edit for the screen. Just like you can’t fix a car if you’ve never ridden in one.
That said, we are all busy people and there is an infinite amount to learn about computers: the rate at which the technium evolves far outstrips the rate that we can understand it. Even the greatest minds in computing readily admit that the Internet is now bigger and more complex than any one person understands.
So the trick is to not try too hard to learn it. Rather, just start using web- and screen-oriented tools and the learning will come when you need it. No one went to a whole seminar on how to use email before they sent an email.
Text-only editing
First, what is text-only editing? Text-only editing is editing in plain-text files. When you do this, you’ll probably be using a particular writing structure called Markdown. For instance, let’s use Stackedit to write plain-text markdown. Type on the left, and on the right Stackedit turns our plain text into formatted HTML.
What we’re seeing here is the separation of content (which is structured text and image-references only) from formatting and design.
What are the big advantages of text-only editing?
- Smaller, faster files.
- Consistency. Computers need perfect consistency (the digital age is a wonderful place for obsessive copy editors), and plain-tetx files help and encourage us to produce consistent documents.
- Less hidden mess. Text-only means fewer copy-paste messes (when you copy paste into a new document and the fonts go all weird), because I’m getting only and exactly what I’m seeing. This is unlike a Word document, where Word is trying to store all kinds of information about each piece of text you might copy and paste, like font and size and colour.
- Less file corruption. Because there is simply less going on, there is less code to go wrong.
- Better version control. If you use a tool like Git for version control, plain-text files give you a great view of the history of your changes.
Collaborative editing
Collaborative editing has literally changed the way I write, edit and deliver documents.
What is collaborative editing? In short, me and someone else editing the same online document at the same time. The biggest tool for this is Google Docs, but there are many others.
One of my favourite new applications is First Draft Pro, which helps writers structure and finish their long-form writing. First Draft Pro provides a range of powerful tools for writing in various genres, including the ability to collaborate with others.
What are the major pros of collaborative editing?
- It lets you solve problems together. Publishing is weird because it’s always been a team sport played by lonely freelancers, working one at a time. Collaborative editing instantly makes the team aspect real and useful.
- You can use commenting for feedback and discussion. Track changes just isn’t the same as actual live annotation.
- Instant delivery of work and real-time review. As soon as you’re ready for your collaborators to check something, share the doc and the ball’s in their court. And you both know you’re looking at the master document.
So much editing is problem solving, and collaborative editing means the publisher-editor-designer are effectively always in the room together at the same time.
I cannot believe that Google Docs has been around for years and people are still editing in MS Word. I promise, promise, promise you want to move all your writing and editing into Google Docs, First Draft Pro, or another collaborative editor.
Automagical pagination
Lastly, what is automagical pagination? Well, on screen, our software and screen size are going to decide how much text is on the ‘page’, the visible area in front of us. On screens we often refer to this as the ‘viewport’. If you’ve used Kindle, iBooks, or Google Play Books you probably know what this looks like.
Here are some examples of things editors need to look out for when their text can reflow into different viewports.
- Hyphenation and non-breaking spaces. Of course you never want to put a hard hyphen into a line because that line will be made and remade in countless different lengths, and you don’t want your hyphens turning up in the middle of a line. You also don’t want the space in a number like 100 000 breaking over a line, so you need to learn how to insert a non-breaking space. And there are several other glyphs that have similar complications, like ellipses and en dashes.
- Cross-references. That is, referring to other places in the document. On screen, you can’t say ‘see page twenty’, because ‘page twenty’ is completely different on my computer and on my phone. You can’t say ‘Click here to go to the figure’, because in print there is nothing to click. And you can’t say, ‘in the figure below’, because on screen the figure might shift position. Common solutions are to introduce numbering systems for sections and figures, or to completely rephrase cross references. (Some smart digital-first workflows let you insert a variable that becomes a page reference in print, and is a hyperlink on screen.)
- Elements that appear on screen but not in print. For instance, let’s say you want to include a YouTube clip in an ebook, but you can’t have the clip in the print version. In some systems, it is possible to mark certain elements to appear in one version but be completely hidden in another.
- Minimalist courage. For maximum compatibility with unknown reading systems, you have to use fewer, more carefully-chosen features. You can’t have ten different variations on headings or boxes. Pick very few features, and treat them consistently with the same styling rules. Make no single-instance exceptions (e.g. never say ‘I’ll make this one heading smaller because otherwise it’ll look wierd here.’)
- Strict content hierarchies. You have to place every feature of the book in a hierarchy, as if your whole book was a tree of trunk, branches and leaves. Computers need hierarchy, but this is most important for accessibility: people using assistive devices, like screen readers, will use your hierarchy to navigate the document.
There is lots more we could go into here but there isn’t enough time. These and other issues will, and probably already do, come up in your work. The trick is to look out for them, and to be curious about how they might be solved.
My team and I area always keen to share and learn, so do reach out if you’d ever like to check in with other multi-format editors.