I had a fun conversation with John Pettigrew on his ‘Talking Through My Hat‘ publishing podcast recently. If you’re in book publishing, his series is worth subscribing to. He has regular conversations with wonderful publishing entrepreneurs, including Michael Bhaskar of Canelo, Kate Wilson of Nosy Crow, and Emma Barnes of Consonance.
Over at Electric Book Works, we’re often deep in the plumbing of the Electric Book workflow, the software we created for making books in multiple formats. If you’re curious about that work, I have written a few pieces there that may be interesting.
‘Producing The Economy with the Electric Book workflow‘ is a case study in multi-format book production, explaining how we built a huge, open-access economics textbook for web and print publication. It’s a great example of the symbiosis of print and digital publishing:
… the practical matter of skills has framed the evolution of publishing as ‘print vs digital’, when of course the conversation should be about print and digital. Not just because we’re stuck with a multi-format world whether we like it or not, but because print and digital formats are symbiotic. …
Print books generate instant credibility. They carry a sense of permanence and authority that digital formats cannot muster.
… Web publications struggle to muster the authority of a printed book, but they scale instantly and allow for a range of funding models.
So, when a book needs to make an impact, it simply must be in print and digital formats. It cannot have impact without the authority of print. And it cannot have impact without the scale of the web.
In ‘Book production with CSS Paged Media’ I explain in more detail how we create print books using HTML and CSS. It has lots of pictures. And also explains:
In our team, we dedicate a significant piece of everyone’s time to technical skills development – both editors and designers – to reduce dependency on developers. And, as our technical lead, I have to spend at least half my time learning or training others. A commitment to digital-first publishing is a commitment to a serious learning curve.
And in ‘Publishing research in useful formats‘ I explain how and why it’s important not to bury research publications in inaccessible PDFs; and the exponential value to be had from publishing as web pages in particular. Ultimately, if you can publish in multiple formats at once, you get a bunch of value, since different people will have different needs and preferences:
It can be very powerful to hand a high-quality printed book to an influential person. A beautiful printed book lends a project real credibility.
Many people like to download and print out PDFs to read on paper, or to use PDFs in PDF-annotation apps on tablets. Those PDFs must be optimised for use on screens, including clickable navigation and reasonable image sizes. (That is, they are not the same as PDFs for book printing.)
Many people do their reading on their phones today. Mobile-friendly web pages are much easier to read and bookmark on a phone.
Many people like to read long-form content on an ereader, like Amazon Kindle. A key feature of this is the ability to highlight and annotate as you read, and to see what others are highlighting. If your research is available in the Kindle store (or other stores like iBooks), it’s easy for people to find and annotate it like this.
Web pages are easy to share on social media. Today, we get many of our recommendations from contacts sharing links on social media. So website versions of research can be critical for getting others to share your work in this way.
Search engines likely rate web pages higher than PDFs, for various reasons. So research published as web-page content (as opposed to PDFs for download) will be far more visible and popular in search results.
You can get in-depth analytics from website publications. Using a service like Google Analytics you can see what people read most, what they search for, and where they are, right down to city level.
Well-constructed web pages are better for accessibility: for instance, for read-aloud screen readers and high-contrast displays for the visually impaired. And good accessibility has the added advantage of being useful to voice-driven services, such as Google Assistant, which can read out web pages in response to a user’s voice requests.
Website versions can be updated instantly, should information change.
In the days before the Göteborg Book Fair, its director Maria Källsson defended the fair’s decision to allow one (and only one) right-wing extremist publisher a platform there:
How we are to tolerantly deal with intolerance is a major dilemma in our time. It is true that we can expel extreme exhibitors from the fair. After all, we decide who is allowed to have a stand there. But we can’t expel them from society. In order to understand our approach and our principles, you have to understand what the book fair is. The book fair is an open arena for free association and freedom of expression, and it does not forbid opinions. That principle comes with a price—even detestable opinions can appear at a book fair.
The Frankfurt Book Fair faced similar ‘dilemmas’, and defended their decisions in similar ways.
The argument that we should ‘tolerantly deal with intolerance’ seems satisfyingly logical. But it hides an abdication of responsibility that leads to terrible things – especially when espoused by publishers, whose job it is to make ideas seem credible, and the fairs that celebrate them.
If you genuinely believed detestable opinions can appear at a book fair, you would allow child pornography, manuals on genital mutilation, recipes for chemical weapons, or handbooks on torturing information out of people. All of these publications doubtless exist, and yet we would never allow them space at a book fair. We recognise here, so clearly, that freedom of expression doesn’t apply to promoting cruelty. It would be absurd to tolerate even one of those publications at a book fair.
And yet right-wing extremist views, which are primarily racist, escape prohibition. Racism, inexplicably, is not considered as harmful, despite the fact that it has driven every genocide in history, and continues to fuel the neglect, bullying, oppression, torture, and murders of people across the world. And it thrives in a world, contorted by hypocrisy, that allows racists freedom to express themselves even as they silence others. Perhaps racism is so widespread and so common that this seems normal.
Like racism itself, Källsson’s argument that we should ‘tolerantly deal with intolerance’ is not rare. It’s a symptom of that particular disease of comfortable people: the mistaken belief that neutrality is a virtue. This dangerous myth suggests that it is possible to debate racism with racists, as if hatred had a logic we might disprove if only we could work it out. And, as a result, our penchant for debate gives racist organisations a platform to ride, like a perfect wave, right into the centre of our lives and our politics.
So we must remind each other, patiently, over and over again: for as long as racism exists, neutrality is not a virtue. The same goes for misogyny. At best, neutrality and debate reinforce a cruel status quo.
The shadows of the human mind will always harbour terrible ideas. There is neither value nor virtue in making them stronger. As the folktale goes, the wolf that wins is the one we feed, and no one bears a greater responsibility for that than publishers.
On a mailing list recently, a friend asked: should my workflow use an HTML editor or markdown? There is, of course, no easy answer. It depends what trade-offs you want to make. At Fire and Lion we use markdown for book production, and I know very smart people who think that’s crazy. They’d pick an HTML editor any day.
What worries me about working in an HTML editor is that it must make assumptions about what the user intends. That is, HTML editors abstract what you see from what you’re storing. What you see is what you hope you get. The real source format is what the user types, but HTML editors effectively discard it, jumping straight to rendered output and hiding its structures from view. Non-technical users often have no idea what they’re actually storing, and very little control over it.
And those assumptions are the root of all editor evil: they inevitably lead to a hidden mess of legacy markup. As users edit, and especially as they paste from other sources, their editing software has to make guesses about what formatting and what HTML elements the user wants to keep and what it can discard. You only have to glance at the source of a heavily edited WordPress page to find a teeming mass of unnecessary spans, redundant attributes and inline CSS.
Over time, the HTML gets messier, and that mess is swept under the rug of the WYSIWYG view. And as it gets messier, it becomes less portable, and conversion tools become less useful. Suddenly I can’t just reuse my HTML somewhere else without unpredictable results. For any given reuse I lose hours to cleaning up my HTML, effectively creating a whole new fork of my project, and losing the ‘single-source master’ feature of my workflow. I’m sure every new HTML editor aims to solve that problem, but I haven’t found one that’s solved it yet.
So that’s why I remain a champion of markdown-based workflows: there is no abstraction in the editor, because I’m only ever working in plain text. The simplicity of plain text means my content stays clean as I go, because there is no rug to sweep a mess under.
The bare bones of markdown have other spin-offs, too:
- Markdown is more portable. By ‘portable’ I mean between people and between machines. For non-technical people, markdown is more open than HTML: it’s instantly readable and copy-pastable. A format that’s useful without a developer in the room is exponentially cheaper to work with, especially when you have to move it between machines.
- The contraints of markdown force us to keep document structures simpler, sticking to fewer, standardised elements.
- And diffs of plain-text markdown (in Git especially) are easy to read. We can use them in editorial workflows as is.
However! Those who prefer HTML editors are right that markdown has serious constraints. Or, rather, that HTML5 (like many markup languages) provides more features than markdown can provide natively. For instance, markdown can’t produce tables with merged cells, create plain divs and spans, or manage nested snippets for things like figures. They’d argue rightly that the markdown editing experience can be clunky, especially to those accustomed to Word-like UIs. And that non-technical users mostly don’t share my concerns about messy underlying markup: they just want an editor that looks great and is easy to use.
Like tabs versus spaces, I don’t expect this debate will ever be resolved. What matters is that we each pick our own trade-offs, and respect the trade-offs others make.
I love you, InDesign, but it’s time to let you go. We just can’t be together in a multi-format world.
InDesign is expensive, so I can’t have my whole team working in it. It’s so powerful that it takes years of experience to use it without making a mess. And it’s fundamentally incapable of producing both print PDF and ready-to-use HTML from a single master file, despite some amazing hacks.
Adobe has tried valiantly to turn this page-based, hot-lead-replacement into a multi-format tool, but its roots in print are just too deep. Making books in InDesign and converting them to high-quality ebooks and websites is a rocky journey that leaves even the smartest typesetters bloodied and broke.
At Fire and Lion we make a lot of books for screen and paper (mostly for publishing companies and non-profits). To our clients, what matters most is that the books are well-crafted in every format, and that working with us is problem-free. Behind the scenes, we have to do something special to make that possible.
So the first thing we do is avoid using InDesign for setting everything but the most heavily illustrated books. We don’t do page-by-page layout and convert to HTML later. In fact, we do exactly the opposite: we make each book as a little website, and then output to PDF.
To put it another way: Fire and Lion makes responsive websites that respond not only to screen sizes but to the pages of a book. And we do it so well that, looking at the finished product, you can’t tell the difference between our books and those you’d get from a typesetter working in InDesign.
We’ve been lucky to work with clients who’ve let us make their books with this cutting-edge toolset. You have to be brave to accept a GitHub repository as your open files, rather than an InDesign package; but it’s brave people like that who move our industry forward.
Nothing we’re doing is a secret: our workflow is open. So when we’re not making books, we’ll be talking about how we make them. If you’re working with similar tools, or curious about ours, let us know.