I spent most of yesterday making a final (hopefully) set of tweaks to my new cloud computing book—or at least final until such time as I decide substantial revisions (i.e., a new edition) are called for. As I'm sure everyone has experienced in their own way, getting to 100 percent (or as close to 100 percent as reality allows) always takes far more time than it seems as if it should. Especially when you are getting profoundly sick of the whole enterprise and just want it over with. I'm going to give everything a few days to settle but here's hoping that, once everything percolates through Amazon's system (they seem to use something of an "eventually consistent" model for their publishing platform as for other things), I'll be able to call the production end of things a wrap and feel confident promoting to a broader audience.
Given that, I thought I'd take the opportunity to do something of a postmortem, both in the interest of sharing possibly useful information and to document a few things for myself. This is, by no means, intended to be a definitive guide to publishing a book. Rather, it highlights things I learned in the course of this experiment.
As many of my readers know, by day I am Red Hat's cloud evangelist. Thus, this book was only a pseudo-personal project. I wrote much of it on my own time, but it leveraged a fair amount of material I had previously written for one outlet or another (blog posts and the like), as well as material others wrote and which they gave me permission to use. My goal was to pull together my thinking on cloud computing and related trends within this context. It wasn't and isn't really focused on profit.
Up-front decisions:
Publisher. I decided to publish through the Amazon CreateSpace publishing platform. To some degree, this decision came about from following the path of least resistance. The timeline for this project expanded and contracted based on a variety of external factors as I rethought various topics. Some of my thinking about the best way to approach certain aspects of the book also morphed. Certainly a publisher could potentially have helped me through some of these questions. At the same time, they'd also likely impose constraints, based on marketability which, as I've indicated, wasn't a top priority for me. At the end of the day, I felt comfortable tackling the project on my own and it just seemed easiest that way. (At one point, we did consider making this an "official" Red Hat project, but that didn't come to fruition for a variety of reasons.)
Length. My initial thinking was that my book should be a "normal" length, which my research suggested was somewhere around 60,000 words. I've come to think that, while there are reasons to have the heft of a typical book, it's not really necessary—at least in the context in which I was working. I recently wrote a post about how short books are more practical today than in the past. That said, although I trimmed some material that I came to see as filler, I added other material. And I rather liked the "guest posts" others let me use even if they were partly there initially to pad things out.
Organization. One of my colleagues, Margaret Rimmler, suggested the idea of short chapters based on the look of Jeremy Gutsche's Exploiting Chaos. That basic concept fit well with leveraging existing relatively short (1,000 word or so) blog posts and the like. The chapters in my Computing Next are longer and tone is considerably different but I did ultimately stick with the idea of having chapters that are relatively standalone.
Format. Where I broke considerably from Exploiting Chaos' look and feel was in my approach to graphics. I initially was headed down the road of having a graphically rich book with lots of full-bleed photographs and the like. However, I came to rethink this approach. For one thing, I realized it was going to create quite a bit of incremental work and cost; I'd have to use a full desktop publishing program like InDesign or Scribus (with which I had just about zero familiarity in both cases) and I'd need to print the book in full color. For another, much of the work would be irrelevant to the Kindle version. In the end, I decided to primarily just include graphics that were directly relevant to the book's content.
Footnotes. I struggled with this one a bit. I really like using footnotes in my writing. Not so much for the purposes of exhaustively citing sources, but as a way to provide additional background or context without breaking up the flow of the writing. Unfortunately, footnotes on a Kindle aren't ideal as they're essentially hyperlinked endnotes that tend to take you out of the flow more than a digression would. That said, I decided to just use footnotes anyway because it's what I'm used to.
Tools. With the book now primarily text, there was no particular benefit to working in a program that let me see that text as it would appear on the printed page. (I'd need to format it eventually, but the writing now didn't need to reflect layout considerations to any significant degree.) I ended up using Scrivener on my Mac. One of the really nice things about Scrivener is that it's very easy to work on, label, group, and rearrange individual chapters—a great match for the style of my book. Once I got to a mostly complete first draft, I exported the text into iWork Pages and then worked on it in that format for the balance of the project. In general, I find Pages is less annoying than Microsoft Word in a variety of ways although, as we'll see, I did ultimately export from Pages to Word in order to create the Kindle version.
Editing:
Several colleagues read through the manuscript with greater or lesser degrees of rigor. I did a front-to-back fine-tooth comb read after the manuscript was complete and integrated. Furthermore, a decent amount of the content had been previously edited in some form or other. In spite of all this, I decided to engage a copy editor (a former intern of a magazine editor acquaintance of mine).
Lots of corrections. To be sure, some of them were stylistic nitpicking but also corrections of no small number of grammatical errors and misspellings. I can't say I was really surprised, having been writing and being edited for many years. Past a point, you just start reading what you expect to read and not what's actually on the page. The lesson? You absolutely must have a copy editor do a thorough review. And, in general, even friends and acquaintances who are good writers mostly won't read an entire book with the care needed to really clean it up.
(I initially considered hiring someone who would be better equipped to edit for content, tone, flow, etc. but the couple possibilities I had in mind didn't pan out and I didn't really want to spend a lot more money.)
Cover:
The cover arguably makes less difference to Amazon purchases than it does in a book store. Nonetheless, you want something that looks professional. I downloaded a template from Amazon and worked on it in Adobe Photoshop Elements. (I'm certainly not a design professional, but I do have some design background and training.)
Kindle:
Creating a Kindle version wasn't as straightforward as I had hoped/expected. If you expect to just take your CreateSpace PDF and upload it to Kindle Direct Publishing and have life be good, you're probably going to be disappointed. I'll probably do a separate post on this, but I'll note here a few specific issues I had.
- Small inset photos won't display that way in the Kindle version. (These were head shots of the guest authors in the case of my book.) I ended up just taking out all of these photos, as well as photos in the section breaks that were just there for graphical interest.
- You may have to manually create page breaks.
- Depending upon the word processing program, you may have to manually change certain styles to be explicitly bold or italics as opposed to using a bold or italic font. (In other words, if a heading uses the Gill Sans MT Bold font rather than Gill Sans MT with a bold setting in the word processor, it won't display as bold on the Kindle. (It doesn't help that Word seems to make some of these substitutions on its own.)
- You may have to create a Table of Contents manually depending, seemingly, on the phase of the moon. You basically do so by inserting a "toc" (without the quotes) bookmark where you want the Table of Contents to be, inserting the text you want in the Table of Contents (without line numbers), and then creating a hyperlink for each line to a bookmark at the corresponding chapter. Yes, it's a pain in the neck. It's probably best tested by downloading the mobi file created when you upload your draft Kindle book to Amazon and opening it with a Kindle or Kindle app.
The good news is that, for many books, it doesn't seem as if you need to get all down and dirty with HTML or ePub code; you can just stick to your word processor. But, in my experience, you are going to have to adapt your the document created for the print edition to display nicely on a Kindle. (And it makes sense to think about the Kindle version as you're designing the book.)
No comments:
Post a Comment