On Writing a Book With Google Docs and Amazon KDP

Published on December 20, 2013 (↻ February 5, 2024), filed under Development and Everything Else (RSS feed for all categories).

This post is outdated.

Google Docs is okay to write short books and when making limited use of the comment feature. Amazon KDP’s HTML format is a technical disgrace, and Amazon needs to fix it. A few thoughts and tips on completing a book using either.

Google Docs

Docs, which seems to say “documents, spreadsheets, and presentations created with Google Drive” (I struggle naming the Google product) is a great choice for these document types because it’s backed up online and nicely integrated into all of Google. No matter a former Googler, using Docs was absolutely my preferred choice to write the manuscript of my last book.

Doing so I believe I’ve maxed out Docs’ capabilities—not in features, but in performance. I ran into three distinct problems:

1. Linearly decreasing performance: The more I wrote and the more people worked with me, the slower Docs became. Yet that was only partially surprising.

2. Lost edits: Google Docs is somewhat susceptible to network connectivity issues. On slower connections I occasionally (fortunately rarely enough not to just abort the Docs experiment) lost edits. I’d write a paragraph, there’s a hiccup, and only a reload—losing some work—would help.

3. Lost comments: Here we—my editor and I—ran into a really strange bug. We lost a bunch of comments. Lost may not be accurate in that we saw them in the “Comments” menu (and had received emails, too), but they just wouldn’t show up in the document itself. Which is, not all of them. This cost us a lot of time and nerves because comments are most useful if you can see them in the sidebar, alongside what the commenter highlighted.

I’ve shared the conclusion: If you plan to write a book with Docs do it for a shorter book (up to 100 pages), but not for longer ones, and not if you anticipate a lot of comments. Then Docs will be great as usual.

Amazon Kindle Direct Publishing (KDP)

KDP is Amazon’s platform to publish and sell books. It comes with its own technical standards and peculiarities. I’m generally fond of KDP, but I like to share some things to watch out for and, please, for Amazon to fix.

Though KDP accepts HTML, Word, MOBI, EPUB, RTF, PDF, and plain text, none of the respective formats that a Google Docs document can be converted into (HTML, Word, RTF, PDF, and plain text) would display correctly. That includes using Google Docs’ formatting defaults. I don’t want to make this another negative for Docs nor KDP but suffice it to say that it blew the secret desire that I could write a Docs doc and, voilà, it worked in KDP (feature request, Docs team?). That leaves us with HTML here then, of course, a web developer I’d take matters into my own hands.

There are three problems I ran into with KDP HTML, and they’re all grave:

1. Random, nonsensical HTML requirements: I could actually write a rant here that would fill a book on its own. The bottom line, only some HTML elements are allowed, and three custom ones have been introduced, of which one should be normal HTML (<mbp:section> → <section>), one dropped (<mbp:nu>), and the last one be revised (<mbp:pagebreak> to be done via CSS). Most attributes have been stripped. CSS has been cut to the stem by allowing only a very limited number of properties.

2. Random, nonsensical encoding requirements: UTF-8 encoding is prohibited, and that is enforced in the upload process. One’s only allowed to use ISO-8859-1 with the exception of spades, clubs, hearts, up arrow, down arrow, alpha, beta, and gamma. Which is not a glyph-related restriction, however, as using entity references works fine in a good number of cases.

   The characters I found safe are at least ““”, “””, “‘”, “’”, “—”, and “…”, if you use the references ““”, “””, “‘”, “’”, “—”, and “…”. “ ” works reliably, too.

3. Poor documentation: The technical documentation is incomplete, inconsistent, and not very usable. It doesn’t list all HTML and CSS that is supported. It’s inconsistent in how it presents the technical information—information about CSS, for example, is only available in side notes. It’s hard to find what’s needed (I googled most). And that’s not getting better for all the Amazon-proprietary code like standardized IDs for e.g. table of contents. ^*

I was very tempted to label the code requirements ridiculous. Why? To make a point as I’d, at this moment, put $100 on the table that KDP was primarily the responsibility of a, and quite possibly a single one at first, software developer. And software developers are not web developers. What Amazon would benefit from is to allow all of HTML and CSS (as much as possible) as well as either free choice of encoding or UTF-8 as the standard. (Amazon, I’d be in to help with this ^†. I’m sure there were reasons for some of the decisions but I’m prepared to find solutions that make KDP more interoperable and easier to use.)

What that leaves us with is a lot of work for every author or their assistant to figure out what works and what doesn’t, and how to write code that only sucks sooo much. KDP HTML is cumbersome and time-consuming to work with.

KDP HTML Template

These were the pain points when writing a book with Docs and KDP. They may or may not help to avoid all of that pain. But here’s something that can, the essence of the HTML document that I used for 100 Things:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="iso-8859-1" />
    <title>(Title)</title>
    <link rel="stylesheet" href="default.css" type="text/css" />
  </head>
  <body>
    <mbp:section></mbp:section>
    <mbp:pagebreak />
    <!-- and repeat -->
  </body>
</html>

If it resembles “the World’s best HTML template” that’s probably no coincidence. I like to keep things to a minimum.

^* As long as Amazon doesn’t improve this there’s actually potential to set up an improved, user-tested KDP guide, and make that a commercial success. Dealing with a number of KDP issues I’ve already seen some books on KDP publishing that aim at exactly that, but they’re not complete, either, and really not that good. It’s sad to see how Amazon created a niche business here.

^† That is, I’d be open to conversations. That doesn’t mean I’m generally up for hire again, but just that there are companies—Google being #1, but also including Amazon—I’d always listen to.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)