Expert publishing blog opinions are solely those of the blogger and not necessarily endorsed by DBW.
Last week, I led a webinar on ebook quality assurance, or QA, and discussed its many facets and challenges. I focused on the nitty-gritty of code, device fragmentation, and other aspects of working with EPUB and MOBI files.
I got great feedback on the webinar via Twitter, and I also received many questions during the presentation that I wasn’t able to answer. I wanted to take a moment to answer those questions in full.
Let’s start with a basic question:
What is a “universal” EPUB?
When I say universal EPUB, I mean an EPUB file that is intended for multiple distribution channels. A single EPUB will display differently on various devices, thanks to each device’s technical makeup. When you QA an ebook meant to be sold everywhere — including Amazon, after it is converted to a MOBI file — you take into account each platform’s rendering engine and level of support for displaying an ebook’s given code.
Via trial and error, you can customize your ebook’s CSS file to tailor your content’s overall design for each platform. You can even go further and create media queries to specifically target Amazon’s ereaders. However, keep in mind that your code will only go so far, depending on a device. For example, an iPad’s rendering engine is much more robust than a Kindle DX’s — so, YMMV. You can create individual ebook files geared to specific platforms, but at one standpoint, the strategy is not very cost-effective. I’ve found that the majority of folks making ebooks create One EPUB For All.
What advice do you have if non-coders are doing at least some part of QA? Do you have any advice for breaking up the QA process (validation vs. user experience) for those who do not have coding skills (i.e., an editor or production editor who may know how to address problems within content)?
I think non-coders can take a step back and approach ebooks as just readers, and focus on the user experience; open an ebook on as many devices and possible and flip through them. Are headers or captions appearing isolated from their paragraphs or images? Are illustrations not rendering correctly or scaling according to the device’s orientation? Does text disappear in night mode? Sometimes there’s a bigger-picture issue at play that goes beyond what’s in the code — namely, structure and navigation. Is the ebook easy to follow? Do you feel anchored within the text, and not “lost”?
The devil’s in the details, though, and I will always recommend getting into the code whenever feasible. (Adobe Dreamweaver’s split Design View would be a great approach to the code, because it allows you to see the changes as you make them and understand how the HTML and CSS work together.) Developers can translate HTML elements for editors by aligning them to print-centric terms; so your <h1>’s could be chapter heads, your paragraphs are your <p> tags. An editor will likely care most about why their content is presented in a specific way; the developer will focus on how to accomplish that. Something as simple as “Add more space above the B-head” may be enough to translate to a developer, “Increase the margin-top:; of all h2 elements by 1 ems.”
I’ve never created an ebook. If I export one from InDesign, will I end up with a file that still needs tons of tweaking?
The short answer: Yes.
The long answer: Yes, though it may very well be for stuff the reader isn’t going to see, if your file has been set up properly (i.e., no local styling, paragraph styles mapped to CSS, defined paragraph styles for every element of your book, etc). Your metadata will definitely need to be revised — that’s in your OPF file. And a basic EPUB export from InDesign isn’t usually valid — that is, it won’t pass epubcheck. You’ll definitely need to crack the book open and address those issues.
However, while this may seem like a tedious undertaking, think of it this way: you now have 100% control over your design and content. You can change whatever you want. Having that access to your ebook is pivotal and a great way to learn the basics of HTML and CSS in action.
Do you have any suggestions for other applications to proof ebooks, aside from Adobe Digital Editions?
Adobe Digital Editions can be problematic to use, but that can be said about any application used for proofing ebooks. First and foremost, understand that the various applications I discussed, including
are not meant to replace actual, physical devices. These should be used as supplements for an electronic reader or tablet. You won’t know how a book looks on an iPad unless you load it onto one. There is variance in rendering, even within previewers meant to help you guide your ebook design. For example, in the desktop app for iBooks, large images can split across pages, though this may not necessarily occur on an iPad. And there are other readers that will completely override the styling you specify! (I’m lookin’ at you, Nook. You too, Readium.)
(While I remember: Speaking of iPad, to preview ebooks on iOS there’s also Book Proofer — I have not used this utility personally, but I am aware of it, knowing you need an iTunes Connect account for ebooks to sell with Apple. Liz Castro has a good piece touching on Book Proofer.)
Of course, I understand that devices are expensive, and can become costly necessities. These free utilities are great to have if you have no access to a device. However, if you can afford to get your hands one, I strongly recommend it.
When will EPUB 3 be fully adopted widespread? If I’m planning a 2014 release, should I gear everything toward EPUB 3?
This is a loaded question that I unfortunately can’t fully answer! EPUB 3 is the current revision of the EPUB standard, but devices aren’t up to speed in supporting all the features incorporated within it. To get an idea of this, take a look at the Book Industry Study Group’s EPUB 3 Support Grid. No device supports every single feature.
You can build a basic EPUB 3 file with EPUB 2 fallbacks — so if a device can render EPUB 3, it will, while another can simply render EPUB 2 instead. You build for both opportunities. There’s an online repository of sample EPUB 3 files available, so you can unzip these ebooks and investigate how they work.
I’ve seen ebook developers state they no longer support MOBI7. What is your position on that point?
Well, most of Amazon’s device offerings support KF8, which is very similar to EPUB 3 (i.e., some HTML5/CSS3 under the hood). Ownership of dedicated eink devices is not as robust as tablets, so to me it makes sense to look to the future and the potential for content. This means leaving MOBI7 behind. (While Amazon is still keeping the DX around, we can safely assume that the MOBI7 format is obsolete.) I will say though, your ebook will look OK on legacy devices as long as you take steps during your ebook QA to tag content consistently and keep your styling to a minimum. This approach is best for straight prose content meant for reflowable ebooks. For anything complex and heavily designed or illustrated, toss MOBI7 out — your reader will probably not use an eink device to access this content anyway.
Any thoughts on QA strategies for books with heavy use of foreign characters/accented characters?
Ebooks written in foreign languages filled with accented characters will likely need to rely on entities. Entities come in various flavors, such as hexadecimal (hex) and decimal. The most common entities I’ve personally seen in ebooks are hex entities. You can tell when you’re looking at a hex entity when the letter “x” immediately follows the &# present. There are also named HTML entities, such as & amp ; for &, which are a little more human-readable.
Use entities for your special characters. NEVER use images. This will make your content look inconsistent and render it inaccessible to readers with impairments, even if you provide alt text for the images.
Keep references like this handy, as looking at a page of source code filled with entities will probably make you dizzy. Make sure that if you specify a font for the text that the font includes support for those special characters. I would let an e-reader default to its own stored fonts and not utilize an embedded font.
Do you have a QA checklist itemizing what to look for based on platform or device?
Keep in mind that the devices you perform your QAs with will depend on the content you’re reviewing. For example, an ebook created with Kindle Comic Creator will only be looked at on Kindle devices and apps (i.e., most likely the Kindle Fire), right? If you have a simpler ebook, like a novel, you’ll probably want to check the book on eink-centric platforms, like Kindles and older Nooks.
Now, to look at the bigger picture in ebook QA, there are some basics you should look out for no matter what book you’re reading. Check out this handy starter checklist on eprdctn.org. Once you go through multiple QA sessions, you’ll find patterns of things to check and review to make note of.
Do you have any questions about ebook QA? Do you have ideas for future webinars? Let me know in the comments!