What I Learned While Publishing the Dakota Stevens Series on Kindle
What did I learn from publishing the first novel in my new detective series on Kindle?
A lot of disjointed things that would take too much time and brainpower to construct into a narrative (I want to get back to, you know, writing), so I’m going to present them to you as bullet points:
(NOTE: If you don’t care about this subject and would just like to see a guy—me—pontificate in HD about typewriters for 30 seconds, jump to the end of this post and click the link.)
- The Kindle Direct Publishing (KDP) help page is helpful and clear, but it can only help you with those aspects of the project that are intrinsically clear and simple themselves, like entering your bank account information.
- As for the substantive part of the Kindle publishing process—the formatting—sorry, suckah, you’re on your own. Here the help page can’t help you.
- You have to build your own still to make the moonshine that is your book. With its endless stops and starts and workarounds, the process reminded me of the crazy moonshine still that Hawkeye and B.J. have in their tent on the old TV show M.A.S.H. At its best, whatever device you come up with is just a patchwork of four or five programs, and endless tips, tricks and homespun advice from those who have gone before you.
- In my case, I found myself exporting the original book from Apple’s Pages program as an ePub document, then loading it into an invaluable ePub editor called Sigil, then tinkering with the XHTML code, then saving it and loading it and testing it in Kindle’s Previewer (which also compiles the code into a .mobi file), then testing it on a real Kindle, then going back to Sigil to fix the mistakes, and at the end using another program, Calibre, to reconvert the code into a readable RTF (for your own reference), then uploading the final .mobi file to Amazon, testing it on their online “tester” (which in NO way resembles the action of a real Kindle), and praying as I pressed the “Publish” button.
- The biggest pain in the ass, without question, is constructing the Table of Contents and making it link up seamlessly with every chapter and section of your book. Your references to files have to be P‑E-R-F-E-C‑T; otherwise you’ll get error messages you don’t understand.
- I was glad I took an XML/XHTML course about 10 years ago, even though I had no idea at the time why I was taking it. Without a rudimentary knowledge of HTML and XHTML, a would-be publisher is lost, forced to determine purely by trial and error what certain tags mean and how they affect your document.
- Maybe this is a trick that programmers naturally use, but I learned to keep separate “revs” of every major change. When I got something to work right, I saved a new rev: “Working_ePub_document_Rev_A”—which in my case went all the way through Z and up to AG before I finished. I did it this way so that I wouldn’t screw up each incrementally better version of the file.
- I learned that, when in doubt, you should proof your manuscript ONE MORE TIME while it’s still in manuscript form (e.g., in Word or Pages). It’s 10x more difficult to make the changes to text when it’s in code format.
- Finally, the award for the Greatest Lifesaving Tip for When You Think You’re Done and the Formatting STILL Isn’t Perfect goes to a very smart guy named David Gaughran. In a masterful little entry on the Absolute Write Water Cooler page, he explains how to fix an issue with indenting that comes up when you think you’re finished: a document looks great on a Kindle, but there’s no indent (or a minimal one) on an iPad. Here is his brilliantly simple, elegant fix.
Now, if you’ll excuse me, I want to get back to writing—on my typewriters. And with that in mind, yesterday my best friend, documentarian Jason Scott, tested out his new camera equipment with me as the subject.
So, if you’d like to listen to me pontificate about typewriters, you’re in luck.
Comments (1)