My Evolution as an Ebook Developer

Photo: Galapagos Turtle
  • Sumo

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.

4 Responses to “My Evolution as an Ebook Developer”

  1. Kira Gale says:

    Laura,
    Please write a book about your experiences and suggestions. It would be very helpful. Are you planning to write more about this?

  2. Jean K says:

    Hell’s Bells, Laura! You and I both know that you’ve evolved way faster than any Galapagos tortoise. There is a learning curve to any technology.

    I highly doubt that the first stylesheet I ever wrote was perfect in any way. It worked. Sometimes good enough = not broken = done.

    And then you learn. You learn from experience and other people’s code. You learn from the brilliant and you learn to recognize the schlock. Consultants may learn about schlock earlier than independents by nature of the point that consultants see code written by a whole bunch of people over a relatively short but continuous time.

    You learn from QA. You learn from industry best practices. This stuff doesn’t happen in the blink of an eye or by some Matrix-like USB port in the back of our heads (although it’s scary to think that some people think this is a neat idea to explore for reals).

    I see this post as autobiographical. You don’t have to apologize for growing as an ebook developer. Yeah. This stuff isn’t rocket surgery, but it’s also something that didn’t exist in its current form just 20 years ago. It’s being invented as you go.

    And damn. Now I feel like the old crank. Sorry. 😉

  3. Andy Culbertson says:

    It’s like that for programmers too. We’re always learning better ways to do things, so looking back at our old code brings a cringe.

Leave a Reply

Your email address will not be published. Required fields are marked *