Hederis is a visual book production and design tool. We combine the power of automated book production with a visual interface, industry best practices, and lots of customisation options. Our goal is to eliminate some of the pain points throughout the book production and design lifecycle.

I got my first publishing job, a year after graduating from college with a philosophy degree and no clear direction for my life beyond just exploring interesting things. The job was at a very small math journal publisher, where we coordinated and published peer-reviewed papers formatted in LaTex and compiled into journal issues. This was my first exposure to markup-based workflows.

I’ve worked with a lot of different ways of making books since then-using FrameMaker, InDesign, XML-based automation, and HTML-based automation. I’ve worked as a production editor and a layout specialist for print books, built ebooks and managed ebook production, and built automated toolchains for print and ebook production. Based on what I’ve seen, at most publishers the primary workflow options fall into two categories:

1. The traditional InDesign workflow: An author submits a text file (usually Microsoft Word). That file is copyedited and then flowed into InDesign. The pages are laid-out and designed in InDesign (either by in-house typesetting staff or by an external vendor; generally taking days or weeks to complete). Any text edits are made directly to the InDesign file, rendering the original text file obsolete. Once the print layout is complete, an EPUB is created via a combination of InDesign export and various cleanup steps, or through some other process (generally taking days to complete).
2. Markup-based automated workflows (typically via HTML): An author submits a text file, OR an author writes directly in markup (generally via some sort of WYSIWYG authoring tool). That file is copyedited, and then converted to markup if it wasn’t already. Book production staff convert that markup file simultaneously to all output formats (typically PDF and EPUB) via scripts (generally taking seconds or minutes to complete). All text edits are made to that source markup file; design is also controlled via markup (typically CSS, these days), and is generally templated.

Here’s a general representation of the two primary workflows, side-by-side, with each color representing the person who would be responsible for performing that piece of the workflow. This is a slightly-modified version of a slide from my presentation at the W3C publishing summit on traditional vs. automated workflows.

Obviously the markup-based workflow is hugely appealing from a business standpoint: you’re reducing costs and cutting out a lot of time and manual processes, which enables you to bring products to market faster.

Unfortunately, it’s hard to meet existing design quality standards via automated workflows, and most designers aren’t ready to abandon or change those standards just yet. Computers don’t (yet) have the same interpretive perception that people have, which means they tend to make choices that humans would consider bad design in order to adhere to the computer’s hard-coded rules. This, in turn, means that people end up having to clean-up the computer’s “mess”, which nullifies some of those time and effort savings.

Pagination is one of the biggest pain-points throughout the book-making process, especially when using automated/markup-based toolchains. This was a recurring theme at the PagedMedia working group meeting: the frustration and time involved in what I call the “update loop”: generate a print file, go through each page of the print file to make sure the lines and pages are breaking cleanly, identify a bad break, go back to your source text file to attempt to insert a fix, regenerate your output file, check the pages again, and so on over and over.

At Hederis, we’re combining the concepts of WYSIWYG design and automated publishing in an attempt to solve the problems I’ve seen time and again in both the traditional and automated book-making workflows. We’re streamlining areas that we ourselves or our publishing colleagues have struggled with (for example, print pagination, semantic markup of source files, or creating a book design for an HTML-based workflow), while letting users keep those processes and tools that are so entrenched and distributed that they become difficult to disrupt (for example, Hederis will happily accept Word files as the source file format).

We’ve already done quite a bit of experimentation with pagination in the browser, currently using the “box” method (as opposed to the “column” method). This means that we take the user’s file, convert it to HTML, and then split that HTML into discrete boxes of content (in the column method, the full content is placed in one big container that uses CSS columns to emulate pages). We’ve found pros and cons for both methods, but have found this to be the most reliable and scalable given our current resources (but we’re eagerly watching this space for developments!).

User experience and user needs are at the core of our product. We’re not solving for ourselves, the technologists, but rather for the people who do the bulk of the book-production work, and who need their tools to “just work” so that they can focus on the quality of the product they’re creating. We want to solve the real problems that are holding book publishers back and give them easy access to modern technology without asking them to become programmers. It’s been an interesting challenge, and we’re excited to explore even more ways to apply automation and new tooling to publishing’s unique problems.