Is Nonfiction eBook Formatting Still Terrible on Tablets?
The latest edition of UI guru Jakob Nielsen’s newsletter showed up in my inbox this morning, and it focuses on a topic near and dear to my heart: ebook formatting.
One might think that ebook formatting would be nearly perfect in 2014, but as we rapidly approach the Kindle’s 7th anniversary the Neilsen Group reminds us that badly formatted nonfiction ebooks are not hard to find.
There are still ebooks formatting with print-aping formatting:
To my disappointment classical texts such as Shakespeare’s plays have very little electronic support. Most versions available do not support annotations, or, when annotated, risibly follow the limitations of the paper medium, as in the screenshot below.
And there are still ebooks that fail to make use of links as a way of hiding text, in particular text that needs to stay hidden:
Custom sections that can be optionally read by those interested can be easily supported through hyperlinks, yet ebooks still have to take advantage of it. A “spoiler alert,” for instance, is unnecessary: instead the spoiler text could be placed on a separate page, accessible through a hyperlink. By inserting it in the text, the editors force the readers to go through those spoiler pages until they find the spot where they can continue reading.
And then there’s the issue with tables, images, and other illustrations. Sigh:
Textbooks and other non-fiction books frequently supplement text with figures, tables, and images. These are essential learning tools, but, somewhat paradoxically, their deployment in digital books is suboptimal. From the beginning beautiful images on high-resolution screens were a tablet strength, yet the illustrations found in ebooks are often low resolution and look unappealing. And the interactions around figures and tables are cumbersome. For instance, many times figures are shown on a separate page than their captions or tables may be split across several pages.
With all the problems that the Neilsen Group found, does this mean that ebooks are still as badly formatted as they were 7 years ago?
In a word, no. Or at the very least you can’t prove it from that single post.
While some ebooks do have problems like the ones mentioned here, it’s not a good idea to extrapolate from a single set of examples to all of a given category. (It would be like looking at that one post in the Neilsen Group website and concluding that web formatting was stuck in the 2000s – yes, it is that bad).
I don’t own very many nonfiction ebooks, but I do own enough that I can say that I have very rarely had issues as bad as the ones illustrated above.
For example, I recently bought a bundle of books on writing (the NaNoWriMo HumbleBundle, to be exact). Almost all of the books were well formatted; in fact, the only badly formatted ebooks all came from the same author.
The rest of the books looked just fine on both my ereaders and tablet, and while that doesn’t prove that formatting issues are uncommon it does suggest how one should look at this issue.
Rather than look at these examples as a representative sample of the state of nonfiction formatting, I choose to see them as a list of worst practices. They are to be avoided when formatting ebooks.
What about you? How often do you encounter badly formatted nonfiction ebooks?
Update: A reader has pointed out that a lot of nonfiction is sold in PDF (and to a lesser degree, fixed layout Epub) – something that did not even occur to me. This puts a different spin on my experience, and it explains why I had encountered so few bad ebooks.
Comments
neuse river sailor November 10, 2014 um 9:33 pm
I read a fair amount of digital non-fiction, and if it is at all graphics-intense, the epub versions usually disappoint. Seems that pdf is still the best format for most non-fiction. That’s why I have a ten inch tablet to supplement my e-reader. The tablet works well to display graphical content, while the e-reader is still the best thing around for most fiction.
Nate Hoffelder November 10, 2014 um 9:45 pm
Now that is a very good point. I’m going to have to revise this post.
Rebecca Allen November 10, 2014 um 9:59 pm
I agree that tables and illustrations are often so tiny on the Paperwhite (and I imagine that’ll stay true on the Voyage) and earlier standard kindles that I have to switch to the computer or a tablet to get a good look at it. Often, I just don’t bother, which is unfortunate. The other problem I have with a lot of non-fiction is finding a place to turn the page without triggering footnote links. Some non-fiction is very densely footnoted. Obviously this isn’t a problem when there are physical page turn buttons (vs. touching the screen); I’m hoping that the Voyage is a better experience in this way. But as annoying as that is, it’s a huge improvement over earlier kindle ebooks which didn’t even _link_ the footnotes. My sense is that there has been steady improvement in formatting of non-fiction and I expect it to continue over time.
Ted November 11, 2014 um 2:36 am
Ditto on the footnote links and the purchase of a Voyage to avoid the issue.
Frank Lee November 10, 2014 um 10:02 pm
The Math Ebook Viewer is designed for textbooks. It has been able to deal with these issues.
1. Hide text
In a digital textbook, the solution for a problem may be hidden until you hit a hyperlink. This interactive feature has been implemented in the Math Ebook Viewer.
2. High resolution images
Low-resolution images are often used in an ebook because their high-resolution versions may be too large to interfere with the main layout of the reading app.
This issue can be solved by linking the low-resolution images displayed in the main layout to separate high resolution images.
3. Long tables
Currently, most reading apps do not allow scrolling. A table longer than the screen height will have to be split into several pages. For this reason, the Math Ebook Viewer allows scrolling.
The Math Ebook Viewer is an HTML5-based app. It can only read a new format called BSON. While we were developing the HTML5-based viewer,
we found that the BSON format is much better than the EPUB format. We plan to convert all textbooks in the OpenStax College into the BSON format. They are all free.
William D. O’Neil November 10, 2014 um 11:16 pm
I read a great deal of nonfiction on Kindle devices and apps (and write more of my own) and see a wide variety of formatting. Some books are formatted effectively for good looks and easy reading; others not so hot.
Bad formatting usually seems to result from (a) ignorance, (b) laziness, and/or (c) thoughtlessness about the medium. What’s particularly galling is that big-five publishers who want you to pay high prices for their e-books often do quite a sloppy job of them.
I modestly contend that my books are good examples of sound nonfiction formatting. Anyone who wants to see what I mean is invited the d/l the free sample from http://www.amazon.com/dp/B00IXRCC4Y/.
Thermos November 11, 2014 um 4:11 am
One of the biggest problems I face is with scientific (especially math and physics) textbooks. At the moment, the only practical solution is to view their PDF version in a tablet. In most of the textbooks downloaded from the Kindle store the mathematical formulas are just converted into (low quality) images that do not scale well with the text. Inline math symbols are especially problematic.
There is no technological reason that prevents this situation from changing, as such documents are (typically) written in LaTeX, so it would suffice to develop a decent LaTeX to mobi/epub/whatnot compiler. Unfortunately, I suspect there is not enough demand to make this economically convenient for Amazon and competitors.
Frank Lee November 11, 2014 um 10:54 am
You are right, "There is no technological reason that prevents this situation from changing". In fact, the MathJax has been able to display beautiful mathematical formulas. It can easily be incorporated into the HTML5-based app such as the Math Ebook Viewer.
The MathJax supports three mathematical codes: MathML, LaTeX, and AsciiMath. Among them, MathML is the most complicated. Unfortunately, the EPUB format requires MathML. This is one of many reasons that prevent me from being an EPUB fan.
Bangbango November 11, 2014 um 7:15 am
Read a lot of nonfiction books (90% of the books I read) and when they are EPUB or Kindle AZW, almost all of the books I’ve bought are crippled by design.
Some reasons:
– people who makes them are sticking to print design, sometimes making fixed-layout files for 200+ p. books of which 85% of content is text (this is the worst you can make, it is utter incompetence).
– they also don’t care: no hyperlinks when need be, low quality pictures, InDesign export which is a replica of the pbook.
– apps and devices are not designed for nonfiction… And their UI/UX can be already bad for novels.
– it is all about efforts: costs, design techniques, extra care, etc. those efforts, nobody wants to make some.
So yeah, you are quite always paying for a crippled version of the paper book and the apps are really bad at managing nonfiction. That is why a lot still prefers PDFs, with which it is also simpler to take notes….
Interestingly, Ebook disappointment always comes from nonfiction, blogposts can attest.
DavidW November 11, 2014 um 8:33 am
I’ve encountered more poorly formatted books than well formatted. Poor image resolution, size, layout for both print and tables. It’s at the point where if it is nonfiction I usually just buy the print version.
Mary November 11, 2014 um 9:36 am
Any non-fiction with illustrations or charts have worked fine on the Kindle app on my iPad. I have not had occasion to download anything with complex mathematical symbols, however.
Rob Siders November 11, 2014 um 12:24 pm
I agree with much of what’s above. One of the things my shop sees daily are people with beautifully designed print editions that display little thought to what the ebook might have to be.
mademers November 11, 2014 um 1:31 pm
A great deal of bad non-fiction formatting has to do with the way the ereaders and apps are programmed, not the ebooks themselves. For example, you mention the way captions get pushed to the next screen; the way to avoid this is to code the image at about 85% of the screen height, but many ereaders/apps ignore image attributes and display the image as large as is possible on the screen, pushing the caption to the next page regardless.
Another commenter mentioned mathematics displayed as images. Again, function of the device programming: almost all are restricted to the Windows-1252 character set. So while HTML5 can display pretty much anything, the ereaders cannot.
Tables: tables are problematic. One can code them in and, while most ereaders do not scroll, the tables will continue over several screens. Scrolling is possible on some apps such as Calibre and most browser ebook apps, but not devices and device apps. Also, most device screens are not large enough to display legibly a table with more than three columns. If converted to an image, tables become even more problematic because then you really have to worry about legibility, especially on small screens. When I encounter a client with lengthy tables in their ebooks, I usually advise them to rewrite the text instead.
Image quality: one is expected to programme one’s ebooks to work across devices, yet the vast differences in image size requirements between low-resolution and high-resolution screens makes that nigh impossible. Also, while one can embed large images for the HR devices, and many smaller/older devices will downsize to fit, some older ePub readers based on Adobe Digital Editions software will crash or fail to open an ebook with large images. Also, even where the device or app will downsize, image quality can be so markedly affected by poor device image handling that one can only cringe.
Worse still, many apps do not automatically downsize images to fit the screen; images that do not fit are simply cut off. One then has to code in a percentage to force the image to be fit in, yet again how the different ereaders and apps interpret that information differs. For example, older Kobo devices maintain the image ratio but the new Kobo HR devices do not: code in 85% of the screen height and that will be respected, but if that means the width won’t fit, then the device squeezes the sides in, causing image distortion. The solution to that was the SVG wrapper, but Apple has waged war on the SVG wrapper, likely as a way to force publishers to use Apple’s iBooks Author, which uses different code. Meanwhile, some older ereaders do not read the SVG wrapper properly, causing text to overlap the images. It’s enough to drive an ebook designer crazy.
Finally, almost all ereaders and apps are programmed to default to override publisher formatting because this allegedly creates a better user experience: the user can set the formatting (or font) to whatever they want. But if they do so, the link to the CSS is broken. This makes an absolute mess of the ebook. I now advise authors of non-fiction books to put in a note to readers at front of book suggesting they do NOT override publisher formatting; I follow this practice in my own non-fiction books. That said, the terrible Moon + reading app does not even have the option to display publisher formatting. How’s that for insane?
So when you buy a non-fiction book and feel cheated by its formatting, know that it may not be the publisher’s fault but that of the crappy device or app you’re reading it on.
M. A. Demers,
The Global Indie Author: Your Guide to the World of Self-Publishing
Rob Siders November 11, 2014 um 2:47 pm
It’s true that ereader support for various features is fragmented, but I don’t think this should absolve publishers from the responsibility of producing usable ebook versions. If they cannot—because that material doesn’t lend itself well for ebooks, or they do not want to invest in the necessary work to reimagine the content’s presentation, or because they do not want to maintain forked source, or whatever—then the best decision they can make is to not produce an ebook version.
mademers November 11, 2014 um 3:31 pm
Rob, no one is saying that publishers do not have a responsibility to produce usable ebook versions. I put a great deal of work into doing just that for my own ebooks. I advise my clients to do the same, and it has been a complaint of mine that many publishers do not (ergo, I devote three long chapters to formatting, HTML, and ePub building in my book, The Global Indie Author). But even if one puts in the work, that does not guarantee success. Publishers have no control over device programming, and there is no way to produce vendor-specific files across the whole industry (and if there were, imagine the cost!). Moreover, such vendor-specific files are exactly what readers do not want; they want interoperability.
Consumers also want the ease and lower cost of ebooks. So not producing an ebook is not an option, especially since a lack of consumer choice leads to piracy (when an ebook is not produced, the print book is scanned and sold/distributed as pirated PDFs). Why should the publisher forfeit sales and revenue just because the limitations of the format do not present the content as well as the print book can?
It is the consumer who needs to make the decision about what format is best to buy. If you hate the limitations of the ebook format, then stick to print books. It is unrealistic and unfair to put the onus on the publisher to solve a problem that is not of their making.
And as I said before, the ebook itself may be well-formatted but the device may not be programmed or even able to present the content as formatted. If one were to take your position and not produce an ebook at all just because one does not have absolute control over the presentation, then there should be no ebooks period. The format should be abandoned.
Rob Siders November 11, 2014 um 4:39 pm
It’s not about having absolute control over presentation and I’ve not argued for that. It’s a matter of producing ebooks that display well … and simple testing on devices and apps from multiple vendors will reveal what does and doesn’t work. You don’t even have to produce the entire book to do this. If what publishers are attempting to do fails QA then they have options: 1. try some other technique; 2. reimagine the presentation; 3. not produce an ebook edition. At some point, pursuing choices 1 and 2 may not make sense from a cost standpoint, so choice 3 is the better one to make. But if they say "screw it, we’re shipping this ebook that looks like poo"—and they do—then it’s wrong to blame the ereading systems because they’re not technically advanced enough.
mademers November 11, 2014 um 5:31 pm
It’s not just a matter of "simple testing on devices and apps from multiple vendors." There are literally hundreds of devices on the market globally, and a multitude of apps. Even devices from the same manufacturer are not programmed the same (as my example from Kobo illustrated). If I code for one device, the ebook fails in another. If I code for that other device, the ebook fails in the first one. Often all one can do is aim for the middle.
Moreover, do you have any idea of the cost of purchasing all those devices and apps? Are publishers — particularly self-publishers — expected to buy every device that comes out just so they can test their ebooks on them? I see you are from 52Books, who provide ebook designs. How many devices and apps, and from how many manufacturers, do you test your clients' ebooks on? Do you even consider devices from outside the US, such as the Tolino from Germany? (Tolino has 34% of the German market and is expected to increase in 2015.) Do you buy every new ereading and tablet device released on the market and test your ebooks on them? Do you warn/inform your clients that a single ePub will not display the same across all devices? Do you, for example, offer to provide vendor-specific files for Apple that contain media queries based on the screen size of the Apple device, as has been recommended by Apple?
If you produce ebook files then you know it’s not that simple when the file contains images and other graphics content. Text-only ebooks are a walk in the park, but images, tables, and such increase the complexity exponentially. Suggesting otherwise is misleading.
M. A. Demers
The Global Indie Author: Your Guide to the World of Self-Publishing
Frank Lee November 11, 2014 um 6:19 pm
That’s why I have been developing the HTML5-based Web app, which should work for all devices that support HTML5.
mademers November 11, 2014 um 6:54 pm
Except that not all devices/apps support HTML5, or ePub3. Some apps and early-generation ereaders barely have support for CSS. Which has been my point: you cannot code one way, create one file, that will work in all devices. And you have conveniently not answered any of my questions.
This is the sort of nonsense that I warn my readers about: companies that gloss over problems while purporting to have a one-size-fits-all approach to conversion. Companies that rely on author ignorance, knowing that too often authors just look at the cost of conversion and not know to ask the hard questions about what they are getting for their money. Thus, companies that are trying to corner the low-cost indie market do not want to talk about these issues because authors who write books that require complex formatting and coding, and who educate themselves about the technical challenges such ebooks face, would know that anyone offering to do it cheaply is providing the kind of ebook files that started this conversation.
M. A. Demers
The Global Indie Author: Your Guide to the World of Self-Publishing
Frank Lee November 12, 2014 um 12:37 am
According to the law of "survival of the fittest", the devices that do not support HTML5 will eventually vanish. While the early-generation ereaders barely have support for CSS, the newest tablets and smartphones have implemented most HTML5 features I need. I believe in a few years HTML5-based apps will prevail.
mademers November 12, 2014 um 1:28 am
Unfortunately, publishers have to address the current reality, not the utopian one of the imagined future.
Ellen Bilofsky November 12, 2014 um 3:28 pm
I don’t understand why people complain about tables too small to read on a particular device. If you need to read a book with tables, then why not use a device with a larger screen or read the print, rather than trying to distort the content of the book to make it fit the device?
As a small nonprofit publisher, our books need to be accessible to people who are visually impaired who may be using screen readers to listen to them. So PDF is not an option for us. We work very hard to make our books user friendly for both sighted and non-sighted readers. But often the vendors (we don’t have staff to do it ourselves) don’t seem to know how to fix formatting problems such as keeping a caption with an image or not justifying heads when they run over onto two lines.