We recently discussed the motivation behind creating the Oyez Review eBook, but the story and method behind the effort definitely warrants an entry all of its own.
As with any technology, a lot of people believe that the work behind creating an eBook is hard, like you have to throw on your druid robes and take to a misty plain in the twilight for some intense chanting or become a half-human half-squid version of a programmer, typing away furiously into the dead of night and subsisting on a diet of Red Bull and cold pizza.
Neither of these are true, even though the latter comparison might describe my working habits. That’s totally unrelated to my eBook work, though.
The truth is, it’s entirely feasible for any editor or publisher to create an eBook version relatively quickly. Yes, there are costs involved, but most of that is labor. Anyone putting together a literary magazine probably already has a computer. They also probably have InDesign or access to InDesign, which makes things easy.
When it’s all said and done, there are three ways of making an eBook, but two and only two I can recommend. If you’re experienced enough with eBooks to know what an ePub or a MOBI is, skip ahead by clicking here. Otherwise, let’s put on our study caps for a quick primer to demystify the nitty-gritty of eBooks.
ePub, MOBI, and Bears, Oh My!
When we talk about eBooks, a majority of the time we’re going to be talking about either an ePub (often stylized EPUB) or Kindle book. Sound confusing? They’re basically just file extensions. The best, most helpful analog would be to think about digital music a few years ago—MP3 versus WMA. WMA, the Windows Media Player version, is a lot like the Kindle to the MP3′s ePub.
While there are some huge differences in the format, it’s in the best interest of any publisher to make editions for both—usually starting from an ePub. We’ll get to that a bit later. The important bit is that regardless of format, true eBooks—those that are not PDFs or apps—are packages of webpages.
Yes, you read that correctly. The eBooks you’ve purchased on your iPad, on your Nook, or on your old-school Kindle are all generated using standard web technologies.
I’m not kidding, if you can format a blog, you can format a basic eBook. It’s as simple as learning some basic HTML and CSS. The same markup that WordPress uses to make this text italic is the same markup used to make text italic in digital copies of Oyez Review. Given enough gumption, one could seriously learn this stuff in a weekend afternoon.
So we’ve established that both ePubs and Kindle (that is, MOBI and KF8 books) are made of basic HTML and CSS, so what else is involved? How do we tell the reader how to paginate the text? How do we tell it to reflow text when the reader changes the font or text size?
In most cases we don’t. We’re formatting the book, not programming the reading software. We may be using the tools and paradigms of a web programmer, but most eBook production—eProduction for short—is formatting and testing.
The Three Methods: The Bad, the Good, and the Great
There are basically three methods for taking your upcoming or current project from production files to an eBook, you can upload a Word or rich text version to a vendor’s conversion site, use InDesign to output an ePub, or code the whole thing by hand. Having played with each option, I have some fairly strong opinions on which is the best, but they’re opinions. Your mileage may vary. Remember to always evaluate the needs of your project before even beginning a conversion.
The Bad: Uploading to a Meat Grinder
If you’re reading this blog, you’ve probably seen ads or other marketing materials for “Easy eBook Conversion” or tools to help you “Sell your eBook.” Probably eight times out of ten, these are probably something like vanity presses operating in the brave new digital world. Sometimes, they’ll actually be ads from Amazon, Barnes and Noble, or Kobo for their Kindle Direct Publishing, Nook Press, or Writing Life programs. While the programs from vendors will almost always allow you to actually upload finished eBook files into their store system, a lot of “frictionless” systems will just ask for a Word or formatted text copy of your text and then spit out an eBook.
The problem with this model is that you get out what you put in. Sure, some “meat grinder” systems can make passable eBooks because the editor/author/publisher has put in some real legwork into making sure something of quality comes out, but a lot of these books end up looking like double-spaced Word documents in an eReader.
Is there anything wrong with that? Not if I’m reading a document for a friend or reading a potential submission. Do I want a book I paid for to look like that? Absolutely not. Not even in print. It’s not often easy, but I’ve returned eBooks for a refund based on formatting problems before. You shouldn’t judge a book by its cover, but something ugly and unpolished in an eBook is a complete and utter turn-off.
If you go this route with your books, please, please, please do your due diligence into using stylesheets or other formatting tricks to make your books look polished as eBooks. Better still, price out what a meat-grinder vendor is offering against hiring a consulting designer to help polish your basic files. Find an intern, find a student, do whatever possible to avoid bad eBooks!
The Good: Exporting an ePub via Adobe InDesign
As much as I use their tools and appreciate the work they do, sometimes I’m hard on Adobe (especially when it comes to subscriptions and backward compatibility). That said, they’ve done a fantastic job at making eBook exports from InDesign files easier and more reliable.
If you’re already using a recent version of InDesign (5.5, 6, or InDesign CC), you shouldn’t have too many big issues in exporting your document to an ePub, but here are some general quick tips:
- Be smart, use a book file. This should be a no-brainer for working with book length works. The upshot for eBooks is that it’ll ensure chapter/story/poem breaks as necessary.
- Go crazy with your Paragraph Styles. This is important, as it might save you a lot of crawling back through code later on to fix things. Be absolutely, ridiculously firm in how you apply them. Why? Because starting in InDesign CS 5.5, paragraph styles carry over to ePub. In the two versions since, that functionality is improved.
- Anchor your images. It’s been a while since I’ve had to use InDesign to export a book with in-line images between or among paragraphs, so maybe something may have changed. Just in case, it might be a good idea to anchor images, figures, or tables to text frames to protect against those elements being shoved to the end of a chapter in the conversion process. You could always crack open the ePub and restore these in the code, though.
- Use Images as Text Sparingly. Frontispieces can be a real pain, especially if you’re trying to make them work on older Kindles (my desk has fresh imprints of my head from this). Think about how images will be displayed on other devices before you take a frontispiece or other print element and swap several text frame for a “rasterized”/image version.
- Breathe. Look, doing this the first time might be frustrating. You have a certain vision of what your print edition looks like. Not everything we can do in print is possible in every eBook format just yet. Try not to replicate your print experience in a pixel-perfect manner, but instead think about how to create a reading experience of the same quality on an eReader. Think about elements like pop-up footnotes and hyperlinks that are exclusive to eBook formats.
My very first eBook conversion were done using InDesign CS5 and 5.5. Don’t use 5 for this. A lot of the tools aren’t quite where they need to be and you’ll find yourself re-writing a lot of code (especially for poetry). CS 5.5 was workable, but there might be issues with embedded fonts on a couple of platforms. I’ve heard through the grapevine that this is fixed in InDesign CC, but have not played with it to be sure.
While I wouldn’t call InDesign a meat grinder, there are some code-elements it introduces that aren’t always what you’d like. This is where thorough and meaningful paragraph styles come into play. I’ve always opened the code and fine-tuned everything, but your mileage may vary.
The Great: Creating an eBook from Code
Whoa, I know. Code. Terrifying right? Remain calm.
Code is not scary. Code is like playing with building blocks. Remember how when you were a kid you made an entire fort of building blocks? Remember those foam/cardboard bricks that you never quite had enough of to make an impenetrable fort, so you’d use smaller blocks. Little wooden letter blocks? Code is an unlimited amount of tiny blocks with which you can build to the sky and beyond.
If you really want to make a great-looking eBook, code it yourself. Don’t trust InDesign, don’t trust the meat grinder, put your hand on all the parts and trust that you’ll ship something you can be proud of.
Is it more work? It certainly can be upfront, but it’s almost always worth it. Once you’ve made a good template for a work, you can easily swap out some of the fonts, the CSS styles, and use it for future books. Getting everything look the way you want is half the battle. The rest is <p> tags with your specified class assigned.
Is poetry harder this way? Yes. I won’t lie, poetry lives up to its glory as a genre by being a tricky, complicated challenge to an eBook designer. It takes finesse, it takes some code that is almost as poetic as the content itself.
But don’t let that discourage you. Get creative.
What do you need to write the code? A plain text editor. You can do this in Notepad, but don’t do this in Notepad. Do it in a code editor (free, paid, go crazy), or anything that will automatically color-code your text.
My favorite is TextWrangler, a free app from the Mac App Store, but that’s just what I found myself using because it was highly recommended. The first step is simply getting all this laid out, the packages, the html/xhtml content pages, the images, get it all in a row.
After you’ve done that, it’s time to test. You’re going to test many, many times. Ideally, you’re going to test on several different devices, but that’s not always possible.
Formatting for Kindle? Use Kindle Previewer.
Testing and Release
Testing is one of the most important steps of an eBook conversion. Test. Test. Test again. Unfortunately, not all devices (ePub or otherwise) are going to perform the same. How? Consider that the output you’ll get in a KF8 Kindle book (for devices 2011-ish or newer) and MOBI (for devices older than 2011). Huge difference, especially for books that require a multimedia component, enhanced typography, or poetic typesetting.
You’ll also want to make sure that your images size and behave properly. Look for missed text-styles, dropped special characters (em-dashes that appear as hyphens, etc.). If you have several different eReaders, test on the devices themselves. If you don’t, you should minimally test using Adobe Digital Editions (for most ePub Readers, including the Nook), the Kindle desktop app, and iBooks (using Book Proofer and an iOS device or via the iBooks Mac app).
Be sure that your book validates against the IDPF ePub Validator—your vendors will check this before the book goes on sale.
Taking a print book to digital seems like a long, maybe arduous journey, but it doesn’t have to be. Take a look at your production workflows and remember that it is possible to overlap the two. A well-made eBook has the same effect as a well-made print book. Creating that same sense of delight in the reading experience is part of the job of being a thoroughly modern editor.
Still have questions? Feel free to get in touch. I’m by no means an expert, but I’m willing to help out.