My Evolution as an Ebook Developer
I have been thinking lately about how different my habits as an ebook developer are now than they were one, two, or five years ago. And about how that evolution is absolutely about working toward making better ebooks. I can say without reservation – and with a healthy dose of regret – that some of the ebooks I’ve made have terrible mark-up. But also that the ebooks created under my watch these days are excellent.
I can say without reservation – and with a healthy dose of regret – that some of the ebooks I’ve made have terrible mark-up.
But let’s back up a bit. The learning curve of a traditionally-trained typesetter to the work of ebook development is steep. I’m no dummy but I don’t come at ebook development from, say, a web development background. (And those people who did went running, screaming back to web dev work.) When I started to make ebooks, I didn’t really know HTML or CSS or any of the technical bits and pieces that go into making an ebook. Imagine a typesetter who is used to fussing with line endings and paragraph spacing trying to wrap her head around the very nature of reflowable EPUB at the very same time that she parses HTML rules, what’s possible in a valid EPUB, and the cascading part of cascading style sheets.
There were missteps.
It’s safe to say that many of those missteps came from relying too heavily on the tools we use. For example, and brace yourself for this: InDesign does not export sound ebooks. In fact, without knowing how to trick ID into clean HTML, the default export is a mess – even on cleanly-styled content. Other tools have good intentions but are, say, created by tinkerers who don’t have the semantics of an ebook’s markup at the top of their to-do list.
In the past three years or so, I have shifted how I think about ebooks to include accessibility at the forefront of how I develop ebooks. That, in turn, has had a profound effect on how I approach the markup and styling of all the ebooks that I touch. The publishing industry is now producing nearly everything they publish in concurrent digital and paper formats. One would think that this would address all of the accessibility issues presented by a print-only marketplace. But, and brace yourself again, electronic publishing is not synonymous with accessible publishing. Exporting ebooks until they look decent in iBooks, for example, does not mean that the code under the hood meets even the most generous of accessibility baseline standards.
The lesson to be learned here is that over-reliance on tools to do our thinking is an enormous problem. The tools aren’t evil and aren’t trying to sabotage our work. But the engineers creating those tools are making decisions for a larger business generally, and their goals likely don’t align with ebook developer’s goals of making good ebooks.
But I like to think of myself as a Galapagos turtle – slow to change, but evolving well and likely to last.
I know that it has taken me far too long to come around to thinking about ebooks from an accessibility point of view. I blame my slow-to-change typesetter mentality (it’s not my fault – it’s on page one of the typesetter handbook to resist all change). I was also being hella overwhelmed by change in the early days of my shift to ebook development. But I like to think of myself as a Galapagos turtle – slow to change, but evolving well and likely to last.