This is an overview of a modern book-production process, designed to produce multi-format publications from a single, version-controlled content source. Team members can work simultaneously and remotely. This process might span weeks, months or years.
After research and workshops, the team writes a strategy and plan, and identifies the project director.
Any publishing project is like starting a business. It is always going to be more expensive and take longer than you think to get right. Good strategic thinking and careful planning reduce the gap between expectations and reality.
So, in workshops and through research, the team gets down on paper a clear and simple strategy, and a thorough plan for executing on it.
For more on this process, see ‘How we plan and cost publishing projects’, and EBW’s six keys to effective publishing projects.
It’s critical that everyone knows at this point who the project director is. This is one person, usually representing the rightsholder, who has ultimate authority over the project, including its budget, content, and contributors. In traditional publishing, this is the publisher or commissioning editor.
The project manager coordinates the team’s work. They keep the director up to date; manage schedules and briefs; ensure that everything happens on time and on budget; and troubleshoots when the unexpected inevitably happens.
The project director selects the best possible authors. The team briefs them thoroughly.
The project director is ultimately responsible for selecting the best possible team of authors, and convincing them to contribute – sometimes for money, sometimes for free. When the project director has not already identified their authors, the team helps to find great people and briefs them. Each project has its own author dynamics.
The team sets up technical infrastructure, including software and clear processes.
Based on the project plan, the team sets up its technical infrastructure. This includes the software and processes they’ll use to produce the book in all its formats. For instance, this might include setting up a master repository, a starting code base, automated and manual tests, deployment processes, metadata, staging sites, file-sharing locations, backups, project-tracking systems, and online access for clients and collaborators.
Working closely with the project director, the authors work hard to finish on time.
Once clearly briefed, authors need time and guidance to finish their manuscripts – their final, written work. To make this happen, the team works closely with the project director, who has the necessary authority to ensure that the writing is done on time.
Authors should be allowed to write in whatever software works for them. They must not have to think about their tools when they should be thinking about their writing.
The project director and team members provide constructive input on the authors’ work.
It’s rare that an author gets everything right on their first draft: writing is a painstaking process that usually needs cycles of feedback and revision. Working with the project director, the team reviews the authors’ work and provides constructive input.
A development editor, who specialises in communicating ideas clearly, refines the authors’ work.
Usually, authors are experts in their field and not experts at writing and pedagogy. So the team often includes a development editor to rework or refine the original manuscript. This sometimes means heavily editing the authors’ work, reordering sections, writing new connected passages, and removing unnecessary text. Good development editors are a rare and special breed – unsung heroes behind many successful publications.
Like authors, development editors should use whatever software works for them. They will discuss with the authors how to resolve problems together, and whether to try to track their changes in a document. It’s usually not possible to track the kinds of broad changes that a development editor makes. Real-time, collaborative software like Google Docs is best for this, so that team members can always refer to a single master document, and discuss specific passages in comment threads.
The copy editor improves and fixes mistakes in style, grammar, and consistency.
Where a development editor works in broad strokes to improve the overall structure and flow of a manuscript, the copy editor works on finer details: sentence style, grammar, and consistency.
Sometimes, a project budget won’t cover both a development editor and a copy editor. In those cases, one person can try to fulfil both roles. This can be sufficient, although they are never as thorough as two separate people can be. Combining development and copy editing can also be a false economy: when an editor improves a manuscript at a high level, errors creep into the detail. These errors have to be found and fixed later in the process, when changes are more expensive to make.
Copy editors should work in good word-processing software. Real-time, collaborative software like Google Docs offers is best, for version control, change tracking, and collaborative commenting. A single, online master document is critical. Offline Word or Excel documents are never used, because they have to be emailed and cannot be properly version controlled.
A designer creates the visual look-and-feel for the project in mockups of covers and pages.
When the manuscript is ready for production, a designer creates the look-and-feel for the project: landing pages, book covers, and page designs for web, mobile, ebook, and print editions. They work with a sample of the text to create mock-ups for the project team to review. Their designs include an example of every feature that the publication might include, such as headings, figures, quotations, question boxes, and so on.
A rights specialist gets permission to reuse others’ content, such as lyrics, illustrations, and photos.
You need permission to reuse other people’s content, no matter where you found it. This includes things like graphs, drawings, poems and lyrics, photographs, paintings, and more. As early as possible, a rights specialist starts gathering those permissions. It can often take months to find a rightsholder and get their permission.
The work of acquiring permissions continues in parallel with the rest of the production process.
A production specialist turns the edited manuscript into markup, stored in a repository that tracks all changes.
At this point, the creative stage has ended, and the production stage has begun. A production specialist turns the edited manuscript into its final, master form: a markup language, such as markdown or HTML, depending on the software they are using. Markup is any consistent syntax that both humans and computers can read.
The most popular markup languages are markdown and HTML. Markdown is plain text structured in such a way that it is easy for humans to read and edit. Markdown can be automatically converted into HTML. HTML looks more like computer code, with tags like <blockquote> around each piece of content.
The specialist also includes accessibility content, such as descriptions of each image for users who will use audible screen readers. Where these descriptions require subject expertise, they will consult with the authors or development editor.
The master files are stored in a repository: a project folder in which every change is carefully tracked. Some software stores content in a database instead, or in addition. The repository also includes the software code that transforms the master files into a finished website, ebook, PDF (for print or screen), or app.
This way, each project is a self-standing package, containing both the book’s master content and the tools for generating published editions. A project’s repository might contain any number of books, in a series or collection. The repository is accessible online, and safely backed up.
This stage is analogous to typesetting in traditional publishing, which refers to laying out the text into pages for print, usually using Adobe InDesign. Modern, digital-first workflows do not use InDesign for layout, because InDesign is not well suited to producing ebooks, websites and apps directly from a single set of master files.
The project manager commissions artists to create illustrations, take photos, and develop graphs.
If the publication requires artwork – such as illustrations, photos, or graphs – the project manager commissions artists and designers to create it. Planning, briefing and checking artwork takes time and experience.
A software developer writes CSS stylesheets that automate the layout according to the designer’s mockups.
Working from the final designs, a developer writes CSS templates. CSS (for ‘cascading style sheets’) is software code that controls how content is laid out on a web, ebook or PDF page. Once these CSS templates are written, layout can be automated.
Good CSS can be reused in many projects. It’s expensive to create at first, and then its cost can be amortised. This makes modern workflows cost-effective for large or long-term projects, such as very big books or series of books with similar features.
If special features require new software, the team briefs a software developer to prototype and refine them.
Good publishing software already supports a whole range of features and functionality out of the box. Beyond that, many projects have unique needs for which new software must be developed. For instance, special features for apps used in rural areas; custom code for a client’s unusual webserver; and interactive graphics from new data sources.
The team first develops a crystal clear idea of how new the features will work. This often involves doing research and creating visual mockups – drawings of every possible screen layout – before putting everything in a written brief for a software developer. The developer then works in cycles, starting with a simple implementation, getting feedback, and then building and refining before getting more feedback. Software development is expensive, so it’s important to be sure at every step that they’re building exactly what the project strategy requires.
For high-end print editions, a designer–editor examines every page and refines the automated layout.
When producing a high-end, printed edition, some of the finer points of book-page layout can’t be automated, because they require human creativity and problem-solving. A production specialist – with both editorial and design skills – looks at every page and makes nuanced adjustments.
For example, the last line of a paragraph that starts on page one might appear at the top of page two, which to a book designer is an unsightly blot. By saving a line on page one (perhaps by imperceptibly reducing the space between characters), they can keep that paragraph together. Or they might notice that, in a textbook, moving a figure from the bottom of a page to the top makes for a better learning experience, based on how the text flows. These many small human decisions combine to create truly beautiful, effective pages.
A professional proofreader reads every word of the final layout carefully, to find any small remaining errors.
Every publication must be checked with a fine-toothed comb for small errors and inconsistencies. This cannot be done by anyone who has already worked on the content, because familiarity with the content makes you blind to small errors. And it must only happen when further changes are unlikely.
A professional proofreader reads every word carefully, and marks all corrections. It’s normal for them to find an error on every page or two of a book. This is surprising to many people unfamiliar with publishing, but statistically speaking, a 60000-word book contains 60000 potential spelling errors, and almost as many potential errors in consistency, punctuation, and hyphenation. Good books are among the most complex products that humans produce. This is why professional, full-time proofreaders exist.
A production specialist will then implement the proofreader’s corrections; and another will check that they’ve all been implemented correctly.
A professional indexer develops the index for the back of the book, a well-crafted taxonomy for navigating concepts.
Many books require a good index – the alphabetised list of concepts at the back of a book. This is the most underrated piece of work in a reference book. It takes years of training and experience for a professional indexer to be able to capture names, events and concepts faithfully, in appropriate detail, and in a taxonomic hierarchy that instantly makes sense to a reader. There are awards for indexes that are as hard to win as Pulitzers.
When an index is required, a professional indexer with the right kind of experience creates one from the proofread version of the book. They will need days or weeks to produce the index, and then a production specialist will add it to the book’s master files.
The entire team checks print, website, ebook and app editions, and submits any crucial adjustments online.
At this point, the team can produce editions of the book that look like the finished product: PDFs (e.g. for printing), a website, an ebook, and an app. They use thorough in-house checklists to test these, and provide copies to the director and their collaborators for review.
Ideally, the director and collaborators can continue to edit and preview the book using an online content-management system for book production. This lets non-technical users edit, preview, and contribute changes to their books from anywhere, at any time. This will be important for ongoing updates after publication.
It’s showtime! PDFs go to the printer, ebooks to retailers, and apps to app stores. Websites go live.
Throughout this process, the team has been producing PDFs, websites, ebooks or apps for review. Now it’s time for the project director to sign them off for public consumption.
The act of publishing takes many technical forms. We ‘deploy’ a website to a ‘live’ server. We send ‘print-ready PDFs’ to a printer, who prints and delivers copies to a warehouse, or prepares to print copies for customers on-demand. We upload ‘distribution-ready epubs’ to retailers like Amazon Kindle. And we upload ‘app packages’ to app stores like Google Play.
The team keeps the website up and stable, and supports users. They work with the director to make updates.
Books are never finished. Especially if they exist as websites or ebooks. Updates and corrections are inevitable: webservers need security updates; retailers change their policies, users have support questions, funders want to know about book-website traffic. The team needs to have a system for managing all of this in the long-term.
Created and maintained by