The ebook Design Checklist

Semantics

Don’t use fixed-layout if you can’t justify its use Please think about User eXperience for a minute, not pixel-perfection. Sure, children books, art books or comics may benefit from fixed-layout but… Various ebook apps and devices don’t really know how to manage fixed-layout: they either don’t support it at all or don’t provide users with important features like annotations, smart zoom, etc. And please be informed that a lot of ebook resellers (iBooks, Kindle, etc.) have been officially discouraging fixed-layout for text-heavy books in their guidelines. As soon as fixed-layout became available. By the way, the web came to the conclusion fixed-dimensions wasn’t probably the best idea when it comes to screen display, then promoted and invested in responsive design. Finally, mobile OSes introduced the concept of Auto Layout to bring responsiveness to apps. This is something you should take into account. ASAP. Enforce structure It starts with the way contents are laid out, in a logical order – which, for the record, is insanely easy to screw up in authoring apps like InDesign when exporting to fixed-layout so please make sure to double-check that. Then it’s all about proper use of HTML5 tags, which will improve over any divitis, i.e. the process of using too many nested/unnecessary divs to mark up a page. Finally, ARIA roles help assistive technology empower users. Don’t ever use tags because of their default style Tags are meaningful: they mark contents up. This is why you shouldn’t use <h3> because you want your headings smaller, <hr/> because you want an horizontal rule (it now represents a thematic break), or <em> as a synonym of ”italic” (it’s first and foremost an emphasis). Refine structural semantics using the EPUB and DPUB-ARIA vocabularies While we borrowed HTML from the web, it was firstly meant for webpages. As a consequence, it might not cover all the needs of book designers. Fortunately, we’ve got a vocabulary to improve structural semantics; it just takes epub:type attributes to indicate chapters, introductions, bibliographies, table of contents, etc. And while you’re at it, you can also add ARIA’s digital publishing roles, since they are already implemented in some browsers, and apps automatically benefit from it if they’re using a web view. Take extra care of navigation Of course you must provide users with a table of contents. But you could do so much more! Do not hesitate to leverage landmarks, build a list of illustrations, videos, tables, etc. And don’t forget to include a pagelist, especially if the ebook will be used in education, because digital readers search for page numbers too. Let text be text Because there is nothing worse than providing text as images – extra penalties if text was exported as images because of fonts’ licenses. Should you need to go freestyle with text (text on path, complex layouts), then SVG will be your best option. And this applies to tables as well. Sure, they’ve always been problematic in web design and ebooks are no exception, but tables as images should be a last resort, if anything else is impossible (laying out data in another manner for instance). Declare language on the html and body tags If it is not declared, that will impact hyphenation and text-to-speech (source). You’d better declare it on body too so that the proper language is used—it depends on how RS inject contents in their UI.

Typography

Ensure Reading Systems can manage your glyphs Got greek, CJK or special characters? Embed fonts which support those characters because it’s not a given with default fonts. Kobo even advises to insert a note into the front matter in that particular case. Choose your type scale wisely Users pick their own settings. Period. Don’t let your headings become a giant mess. And this is all about inclusiveness: some users may have to pick a huge font size in order to read. Don’t force justification User settings again. By now you should be convinced ebook Design is not about laying out contents but building an outstanding User eXperience. Besides, some apps or devices might not support hyphens, which means your justified text will look like shit. Take advantage of Open Type features Sure, rendering engines might not be as powerful as DTP software but Open Type features are becoming mainstream. Here come fractions, real small capitals, old style or tabular numerals, etc. All those features can improve legibility in a dramatic manner. And here’s a utility to kickstart the process. Ensure reflow will not bite you in the ass Did you know the new Kindle format, KFX, adapts drop caps and floating elements based on the font size chosen by users? Now you do. And if Amazon thinks it’s an issue, you should too. Don’t overdo drop caps, floats, etc. if you can’t make sure they won’t disrupt the reading experience on narrow screens or when a big font size is set.

Colors

Don’t forget grayscale Dedicated eReaders are using eInk, which means colors will be converted to 16 shades of gray. It’s not a bad idea to check if your ebook, especially images, render well in grayscale. Hopefully, your desktop OS can help you do that. If you’re using a Mac, for instance, go to the Display Pane of the Accessibility Preferences. Try to avoid background colors User settings once again. Reading Systems will usually remove your background color in night mode so maybe you should not rely on it… Black is white, leverage inheritance In night mode, dark becomes light, which is why you should never ever specify colors from #000 to #666 – it’s even written in Kindle Publishing Guidelines. FYI, InDesign exports those values. So if you need black/white, use color:inherit, border-color:currentColor, fill:currentColor, etc. All of those will map to the current text color Reading Systems set. Pick your colors with color-blindness in mind Disabled readers love ebooks, don’t let them down. Avoid red/green and red/black combinations, use patterns in addition to colors in charts, beware of text on noisy backgrounds, ensure contrast levels are sufficient, etc. The Daisy’s Knowledge Base is an invaluable resource when it comes to accessibility.

Images

Use figure and figcaption Those two tags are meant for each other and this is why some Reading Systems will treat them in a very special way. While you’re at it, do not hesitate to add page-break-inside:avoid in your CSS. Sure, it won’t work in Kindle but we all know Kindle is a freaking jerk. And maybe you could try resizing portrait images depending on the font size the user has set? Ensure images have alternative text when needed Decorative images and images whose captions tell it all don’t need alternative text, others images must. Please read this accessibility tutorial if you’re not sure how to manage that. Use relative units to lay out images A lot of Reading Systems don’t ship with default styles for images, which means overflow is very likely to happen. You should at least use max-width:100% And since you can’t trust pixels – yep, InDesign is exporting this plain wrong by default – you should use % for landscape images and vh, with a % fallback for portrait images. Ensure images’ ratio is kept with one line of CSS Just use object-fit:contain from now on. Thanks! Consider the rendering of your images in night mode Transparent PNG + night mode. Nuff Said.

CSS Design

Try to avoid styling based on id Since user settings basically are a stylesheet, ID selectors may screw user settings up in a spectacular way. Of course, if something critical should not abide by user settings, id can be a solution. Try to avoid using !important See previous point. Also, it may bite you in the ass at some point because you must manage the cascade in a constantly growing CSS. Ensure relative units are used in reflow Don’t use px or pt because they will break the font size user setting in an awful lot of apps and devices. Unitless line-heights are also a good idea. Ensure what shouldn’t reflow with font size doesn’t Page and horizontal margins shouldn’t increase with font size since the bigger the font size, the smaller the container. Prefer %. Ensure fonts of the same family are the same font-family Regular, italic, bold and bold italic fonts should be the same exact font-family. If each is a specific font-family, then the dedicated user setting will be screwed up, italics and bold won’t be replaced in some Reading Systems and users will hate you. Try to avoid inline-block Contents will be cut off because of pagination. With inline-block comes great responsibility – that’s yet another thing InDesign does badly since it’s used for images’ styling. Beware of absolute positioning in reflow It’s stated in the specifications, which tends to prove this may be a critical issue we should fix first. Avoid -webkit-text-size-adjust and text-rendering like the plague The former breaks the font size setting in iBooks iOS. The latter breaks font rendering in some Kindle devices (all text is rendered as “question marks in a box”).

Interactivity

Ensure links are perceived as links Styling links is complex. It’s all the more complex that it can bloat your ebook’s “pages” (visual weight, incorrect manipulation when trying to navigate, etc.). Maybe you could tone them down so that they don’t disrupt the reading process, maybe you could treat them as footnotes if there are too many in your ebook, etc. In any case, make sure users can perceive links as links when scanning the page. Don’t hide pop-up footnotes A long long time ago, in an iBooks.app far far away, the pattern of pop-up footnotes was introduced to ebook Designers. And then we discovered we could use <aside> to hide or <div> to show the footnote in the normal reading view. Turns out the footnote is not accessible to assistive technology when hidden… so you’d better keep it in the normal reading view using <div> or <p>. ¯\_(ツ)_/¯ Don’t use the hide/show pattern (collapse/expand contents) It’s currently incompatible with pagination, and this impacts the <details> tag as well. Unfortunately, Reading Systems won’t automatically update pagination when collapsing/expanding contents, which means they will overflow at the end of the XHTML file. And there’s not bulletproof way to force a recalc at the moment. Ensure your interactions don’t override defaults Got two words for you: User eXperience. (Do not hesitate to preventDefault() so that Reading Systems’ UI don’t flash at every interaction though because this is freaking irritating.) Ensure your interactions are not bloat An interaction can turn into a useless gimmick. And that can become frustrating because it doesn’t add value to the ebook but disrupts the reading experience. Ensure your scripts support all inputs We’re living in an input-agnostic world, devices can have a touchscreen, a mouse and a keyboard at the same time. You’d better design your scripts for touchend, click and keyup (and you may soon have to implement speech recognition as well). By the way, iBooks on MacOS is already private-shaming you with a big fat notification if your ebook only supports touch events. Make your scripts accessible It’s all about how you design scripts. Check ARIA Authoring practices for details. Please make sure you’re using the correct element for the job. If you need a button, create a button element, not a span. A button ships with accessibility: it is focusable, actionable, etc. Then implement ARIA attributes: aria-label, aria-hidden, aria-live, role & al. can dramatically enhance the usability of your widgets. Prefix your storage items, and do not ever clear Web storage In theory, if you take a look at the EPUB specifications, “Reading Systems that do allow data to be stored have to ensure that it is not made available to other unrelated documents.” In practice, it is not the case in a lot of apps, which means you will share storage with all other publications. In other words, should you use localStorage.clear() to remove all the items you’ve set, it will just clear the storage for all EPUB files, and other developers won’t be able to retrieve theirs. It’s also important you prefix the items you set – ideally use one prefix per publication –, in order to avoid concurrent access to same-name items. By doing this, you’ll also be able to get and remove those items, since localStorage.clear() is a no-go.

Progressive Enhancement

Enhance, don’t degrade Building on a solid bedrock is a lot easier than removing parts of a space rocket in-flight. You should design for the lowest common denominator then enhance progressively. We can actually do quite a lot since Reading Systems are build on top of browsers’ rendering engines. But it’s up to you to improve the User eXperience depending on the features those engines support. Adopt a small-first strategy Readers are less likely to read on a 24-inch display than a smartphone, eReader or tablet. Heck, we should probably adopt an eInk-first approach to designing ebooks. And don’t forget some users may boost the font size to no less than 36 pt. In other words, by designing for the really small screens first, you’re likely to avoid quite a lot of issues. Leverage feature queries (@supports) @supports is a powerful tool which allows you to test for CSS support. If the property and value you test is supported then styles in the feature query will be applied. Else, they will be ignored – and it doesn’t crash the old RMSDK. By leveraging feature queries, you can use all the modern CSS specs and be sure they won’t impact Reading Systems which dont support them. This is the super easy way to do progressive enhancement. Beware of Media Queries Empty @amzn-* media queries crash the old RMSDK. Some Reading Systems report corrupted viewports (either because of pagination implementation or use of CSS columns to fake a spread). There is no love for media queries in ebooks right now and their use should probably be discouraged. Don’t use Media Queries to target devices If you really can’t do without Media Queries then don’t use them to target devices. Devices constantly ship in different form factors, display resolutions, viewport dimensions, etc. It’s just impossible to keep up in the long term. Besides, what might work for iBooks iOS in landscape already backfires in a lot of other iOS apps. Same for iPhone, etc.

Quality Assurance

Test on the crappiest app you can find It’s the easiest way to make sure your ebook’s structure is bulletproof. And quite sadly, millions of digital readers are using them…. Change user settings to make sure everything is OK Should be obvious by now. Eliminate friction Have you ever wondered why some vendors open the ebook to the first chapter? Because readers gonna read. Move front matter to back matter whenever possible. And in any case, don’t force the ebook to open before ten pages of front matter readers don’t want to read. Consider the size of your EPUB file Sure, ebookStores set an upper limit but does it mean you should publish a 650 MB or 2 GB file? It’s a User eXperience issue: a huge file will probably take forever to download then bloat the user’s device, etc. Don’t forget a lot of Android devices out there currently ship with just 8–16 GB of storage. Try Text to Speech It’s the easiest way to make sure you’re using ARIA properly. Moreover, you could learn a lot, especially about how software understands your markup, styles and interactions. Now, don’t forget software can be the only link between the ebook’s contents and disabled users. Organize user testing for experimental interactions Ideas sometimes turn pretty badly into reality. If you don’t do user testing, you will discover that once it’s too late. If you’re trying to improve User eXperience with functional interactions or extra features, you should get feedback as soon as the prototype is built. This is how design works, ebooks are not snowflakes.