It’s hard to believe, but if you are an indie author you may find that thinking up and writing 25,000 – 100,000+ words of content for an eBook or print-on-demand book is actually one of the easier parts of the indie publishing process.
Most writers like the activity of writing itself. The process is not always out-and-out fun and it is still very much work, but it is usually enjoyable work. The real drudgery comes after typing the words “The End,” and sometimes even after the first few major revisions. The tediousness sets in when you reach the stages of “line-editing” and formatting, particularly if you are building an eBook version.
As you can infer from the only-slightly sarcastic title of this post, I’m going to offer up some “service journalism” for all you first-time indie writers out there who are thinking of publishing to Kindle. Tis’ my hope that you can learn from my baptism by fire and have a smoother publishing experience!
Here in part one I’ll cover a few of my recommended “do’s” for formatting. The don’ts will be reserved for part two.
• Read the “Building Your Book for Kindle” guide before your manuscript is in its final form
Seems pretty basic, eh? But taking the time to do this and following a few of the Kindle guidelines while you are writing and editing can save you headaches further on.
The more important advice to heed is to avoid using things like tabs, manual indents and unnecessary line breaks and carriage returns. These can cause problems in HTML and you’ll likely end up having to go back to remove them afterwards.
One of the mistakes I did when writing 25 Principles of Health and Weight Loss was write in block paragraph format with my initial manuscript. This is using blocks of text without indentation and with an empty space (or carriage return) between paragraphs, essentially the style used on this blog. I’ve gotten into the habit of doing this because it works well for computer screen reading.
However, as I moved to the proofing stages, I found this format didn’t transfer as well to the smaller and more book-like Kindle screen. Paragraphs seemed to run together and it was generally not pleasing to the eye. Eventually I had to bite the bullet and remove some 2,300 paragraph and return symbols from my working draft and add in first-line indents.
• Download an HTML editor and learn the basic tags:
The KDP formatting guide would lead to believe that once you save your Word document as a filtered web page it will transfer over just fine to Kindle. Sadly, the truth is usually different. While in some cases you might get lucky and have a clean conversion to HTML, oftentimes you won’t be so fortunate.
The trouble with converting a word processor file to HTML using the “Save As” function is that you typically end up with messy code that can cause all kinds of formatting inconsistencies. Programs like Microsoft Word insert lots of style definitions and spans that you most likely don’t need. And if any errors arise out of the conversion process, they will be carried over when you convert the HTML file for Kindle.
The best way to combat this problem is to download an HTML editor and touch-up the code of your converted eBook files. You don’t have to become fluent in HTML, just slightly conversant. If you can pick out a few of the important HTML tags like <p> for paragraphs, <b> or <strong> for bold, <u> for underline, and develop an understanding of how style definitions work, you’ll have a way to clean up some gremlins that might arise from the conversion process. A good way of learning is just to convert a very short Word document, maybe a page or so of text with some different elements, and then playing around with the resulting HTML code in the editor.
There are numerous free HTML editors available for download on the web. I personally use HTML Kit-292, while Notepad++ is another popular option used by many eBook authors. If you are a user of Adobe Creative Suite then Dreamweaver would also work well.
Authors who take their formatting really seriously will often advocate building a style sheet from scratch in an editor so that you have full control over the layout and appearance. If you’re doing something complex like a graphic novel or comic book, this step is probably necessary. But if your book is uncomplicated and mostly text, like a novel, you can usually get away with converting directly into HTML from Word without having to make too many touch-ups after the fact.
If working with HTML is too daunting, there are many eBook formatting services that will be happy to do the grunt work for you. At a price of course.
• Preview your eBook on an actual, physical Kindle (if possible)
Sure, the Kindle previewers (both the downloadable program and the web-based emulator inside KDP) are nice. But don’t put complete trust in them that they are replicating what your eBook will look and behave like on an actual Kindle. There is something tactile and reassuring about being able to read your work on the device itself and verifying that things like hyperlinks, page breaks, and bookmarks are working correctly.
If you own a Kindle, you can email a converted MOBI file directly to your device and it will perform like an eBook downloaded from the Kindle store. You can find your Kindle’s email address in the on-board settings menu or in the “manage your Kindle” section of the Amazon website. The naming format is usually something like JoeBlow_8976@kindle.com.
• Think hard about how many tables, graphics, and artistic flourishes your book really requires
You can manipulate and add to the appearance of your Kindle book in a variety of ways, but bear in mind that some enhancements work better than others. Tables built in word will transfer fine into HTML, but tabular data isn’t always handled well by Kindles. On the other hand, bulleted lists usually display fine.
While I don’t want to discourage anyone from pursuing an ambitious eBook vision, those of us who are programming-challenged or averse need to recognize that using lots of tables, images and fancy formatting will increase the odds of stuff going wrong on a DIY eBook formatting adventure.
So as you go through your content creation, take the time to think about how your draft work might translate to an eReader and if there are opportunities to streamline its appearance. Are all those images necessary to the book, or are some added in gratuitously? Could some of your tables be shortened or even simplified into list form? Do you really need to position yourself as the next Dave Eggers by using 500 footnotes in the course of your roman a clef?
Remember that first and foremost you are building a “book.” It’s likely that your readers are going to be most interested in your story and your writing (in most cases). Using a fancy drop-cap at the start of each chapter can look cool, but a reader engrossed in your words might barely notice it. Keep the emphasis on having good writing that is formatted cleanly.
Coming up in part two, a look at some of the many, many, many, don’ts of Kindle formatting!