Expert publishing blog opinions are solely those of the blogger and not necessarily endorsed by DBW.
In my previous post, I offered a few ideas on how to make ebooks feel unique by taking advantage of some visual design cues.
But I neglected to mention one crucial step: test, test, test your EPUB and MOBI files on multiple devices and apps.
A simple example: try using a very light blue for a chapter title. How does it look on ian Pad and on a Kindle Fire? Probably nice. Now how about in night mode? Or how about on an e-ink device, like a Kindle Voyage? Is it legible, or is it too light?
You can use a media query to target e-ink Kindle devices and use black instead. But I would recommend just starting out with a color that works everywhere. Simpler is better when dealing with the large universe of reading systems, as you don’t know how many readers are still using Nooks or legacy Kindles. You don’t want their books to break, which a media query might well do (especially on older Nooks).
So always test your ebook in as wide of a range of environments as you can. And don’t forget: don’t try to sideload your MOBI on iOS devices (iPad, iPhone). You need an .azk file, which you can create with Kindle Previewer. Here’s a guide on epubsecrets.com that describes how to move it to those devices.
Table of Contents
I also advocate designing the inside-the-book table of contents instead of leaving it as a plain-vanilla list. Amazon requires the contents listing, so you might as well make the most of it.
Since my last post for DBW, Amazon has decided that it will reject books if the contents listing is at the end of the book.
Some ebook makers think that a simple listing of a book’s chapter numbers doesn’t need to be in the front matter and would be as useful in the back. After all, it should be discoverable from a reading system’s navigation tools, and a long, boring list of Chapters 1–63 won’t eat up the sample that is available on retailers’ bookshelves.
But a book with chapter titles and subtitles should go in the front, as these titles can give potential purchasers a good idea of what’s in the book as they peruse the sample.
Without getting into too much arcana, Amazon wants (demands) the listing near the beginning of the book. Plain and simple. So, that’s even more reason to pay attention to its design and integrate it with the rest of the book.
A Text-to-Speech Tip
A common practice I discussed in the previous post involves capturing highly designed text as an image and adding it the EPUB, using alt tags (for TTS, or text-to-speech) to provide the information captured in the image.
A friend on Twitter, Jiminy Panoz, mentioned that TTS doesn’t always work as it’s intended. In his testing, among other problems, he found that Talkback on Google Play for Android only announced ‘’image,” but not the alt text, and similarly, iBooks on Mac OS10 VoiceOver ignored alt tags altogether.
So some more things to look for when testing your books.
Ebook Typography and Page Layout
Plenty of designers—and readers—complain regularly about awful ebook typography. We deal with what seems like an endless variety of apps, devices, generations of apps and devices, reading system preference choices, algorithms, enhanced typesetting features, etc. that we can’t control. Is there any hope? Should we even bother?
Justified or Ragged?
First, a word about preferences. If you spec text-align: left in your CSS, you might sleep well thinking that all your books will avoid raging rivers of word space running down through your paragraphs and instead display a nice, ragged right edge with even word spacing throughout. Well, that dream could become a nightmare for good typography fans.
Not all iBooks preferences are within the iBooks app, though. Here’s a screenshot of the preferences available in the iPad’s settings, outside the reading app itself. (I’m sure ebook developers know about this, but do many readers?)
Even if you spec text-align: left, this full justification setting will override. Not to be left out, the Kindle iOS app justifies text, too.
Don’t Go Breaking My Dash
I’ve got friends in the business who avoid trying to fix horrible typography: em dashes landing at the beginning of a line, ellipses breaking across lines. If that’s how the reading system operates, that’s how it operates. If a user chooses to read her book at a huge font size, we should allow for that and keep text flowing with no impediments.
What kind of impediments? A trick used by some ebook developers is to bind an em dash to the word preceding it by using a non-breaking space in front of the dash, and a regular space at the end.
Note that you’ll fail validation if you use , so use the numeric entity.
For the same reason, some folks bind “Mr.” to “Jones,” “Chanel No”. to “5.” Why in those cases? First and foremost, to aid in comprehension, but also to avoid the tiny pause needed to process the text when a line breaks after “Mr.” And finally, because it can be downright ugly.
A problem might arise if you add a non-breaking space after the em dash as well, or use too many of these spaces in a paragraph for other purposes. What kind of problem?
If a user reading on iPad has set her preferences to full justification, then iBooks won’t be able to break a line before or after the em dash, or between “Mr” and “Jones.” Depending on font size chosen, this could push the whole group to the next line, leaving some gappy word spaces behind.
A similar issue arises with hyphenation: if you distrust dictionaries in reading apps and turn hyphens off (epub-hyphens: none), you could see rivers of space at various font size settings. With preferences set to full justification and without being able to hyphenate, the reading system has no choice but to push long words to the next line.
Choices Have Consequences
If you are eager to bind words and symbols together using non-breaking spaces—to improve the reading flow, avoid comprehension confusion and ugly line breaks—you have to be ready for the results. And since we developers don’t know how any given ebook reader will set up her device, that’s leaving a lot to chance.
Keep It Together
One thing that really bugs me when reading an ebook with subheads in the flow of text is when an h3 (or any header) lands at the bottom of a page. I find that harder to live with than an em dash beginning a line or a “Mr.” separated from his “Jones.”
Isn’t there an easy fix? Just specify page-break-after: avoid !important; in the CSS for any head, and you’re safe. Right? Wrong.
That command is only a wish for many reading systems. Even the !important is toothless.
So what to do? Add a div around the head and the next paragraph and give it CSS of page-break-inside: avoid !important;. This does the trick (usually, anyway).
This is useful elsewhere—to keep stanzas of poetry as distinct units, for example.
Of course, using page-break-inside: avoid can cause lots of white space on the preceding page. If you’re reading in landscape on iBooks, for example, your two columns won’t line up across the bottom. But remember: let it go. This isn’t print.
The question to always ask is: What’s most important, and helpful, to your client and to your readers?
To get all the ebook and digital publishing news you need every day in your inbox at 8:00 AM, sign up for the DBW Daily today!