At Tools of Change – Frankfurt last week, I and Dan Rhatigan did a talk on design and typography in e-reading.
As the title indicates, we covered a little bit more than just ebooks and we ended with a slide showing a big Ebook Design Features Grid.
The point of the grid isn’t to comprehensively explain or outline the features of the various platforms but to help people decide what paths to take and what to emphasise. It’s more of a decision-making checklist than a reference.
The features that run down the lefthand side of the table are mostly self-explanatory. Moderate typography is mostly defined as the stuff you can’t do in an old-fashioned KF7 mobi file. Complex typography isn’t meant to encompass the features Indesign offers print designers but the stuff that’s cutting edge and badly supported across modern web browsers.
Colour is mostly a question of whether the format allows for intelligent fallbacks or adaptation for greyscale screens. KF8 should have scored well there, but most greyscale Kindles claim to be colour devices when it comes to media queries.
Design with layouts are design features you can count on existing in web browsers. Complex design are design features that are cutting edge and badly supported in browsers.
(Yeah, I know. This is very web-centric. You can blame that on me, not Dan.)
Hyperlinks were an excuse for me to go on about how fantastic links are as an invention and then lament how varied and unreliable link treatment is across apps and devices. It’s getting better, but I can guarantee you that hyperlinks aren’t a part of any platform vendor’s basic test suite. (That’s assuming they have one.)
Text selection is not the ability to select text (although some platforms fail at that) but what you can do with the text once selected. That varies wildly.
Multimedia is one of those things EPUB3 thoroughly fixes.
Text rendering is a catchall for how text layout, typography, and rendering is handled in each format/platform.
In many ways EPUB2 is let down by a large number of crap reading devices and apps. There are quite a few excellent EPUB2 apps but since they are outnumbered by the crap ones you have to make decisions based on aggregate behaviour.
I don’t expect the features column to be controversial. Sure, you can quibble about this or that, but on the whole, once you accept that the web is the reference format and each format is considered in aggregate, good and bad clients, most will agree that it paints a generally accurate picture.
The easiest formats (or, the controversial bit)
A lot of people are going to disagree with me on which formats are easier than others.
If we ignore app development for a moment, iBooks Author is clearly the easiest to use and the most powerful. It is also the format that is the most limited: only one class of devices, only one ebook store, limited integration with a publisher’s workflow, and more.
Which demonstrates that this grid really needs a third dimension: business flexibility and features. iBooks Author would score as badly there as it scored well on design features.
The controversial bit is the fact that I label EPUB2 and KF7 mobi as easy.
If you define them as formats that only support basic formatting (italic, bold, headers, maybe a list or two if you’re feeling adventurous) then they are incredibly easy to work with. There is a multitude of apps and systems that generate EPUB2 files: Pages, Scrivener, Pandoc, Aascidoc, Atlantis, Writer2EPUB, Pressbooks, and more. All of these tools output valid EPUB files.
Even the EPUB output of Indesign’s latest version is much improved.
Given how few design features most books require and how many tools output valid EPUB files (which can then be converted to mobi with relative ease) there really is no excuse for releasing broken ebooks.
However, as I’ve written about before, a large proportion of ebooks published are rubbish. Not in terms of the content (although that’s probably also the case) but in terms of the quality of the file. Ereader platform vendors cannot support the full range of CSS that EPUB2 and EPUB3 require because a substantial number of their catalogue would become unreadable.
Platform vendors are in a position where they couldn’t support standards completely even if they wanted to.
It seems that all too many publishers are incapable of even the simple task of releasing readable EPUB files. Which means that vendors will never be able to fully support the various versions of EPUB.
Which is the reason why we can’t have nice things.
The web is harder to develop for than EPUB2, Mobi, or iBooks Author simply because it is much more complicated and because you’re expected to reliably support more devices and device classes. The web platform makes up for this complexity by having awesome tools and documentation.
EPUB3 and to a lesser degree KF8 integrate many of the features and complexity of the modern web platform but offer no tools and useless documentation. And to that they add more complexity (the XML requirement, insanely complex metadata schemes, and more).
So, same features, more complexity, no tools, less documentation all adds up to being much harder to develop for than the web platform.
If all else fails, if you really need complex capabilities and intricate designs, if your interactivity needs go beyond what any of the other platforms offer, your only remaining choice is to do an app and basically write everything from scratch.
You can do amazing things, but the effort and cost involved is generally much greater than that of the other platforms.
There is none. The Design Features Grid isn’t there to lead you directly to a single unavoidable conclusion but to describe the territory. It’s purpose is to show you areas to avoid and which areas are easier to traverse than others. It’s there to help you make decisions, not make your decisions for you.
Recent blog posts
- BISG study: A buffet of digital book subscriptions
- The debutant's dilemma
- BitLit announces HarperCollins ebook bundling pilot programme
- #FutureChat recap: How can we ease the summer's debate?
- 10 questions about subscriptions with Andrew Savikas from Safari
- #FutureChat: How can we ease the summer's debate?
- 10 things publishers have been doing (that we should celebrate)
- #FutureChat recap: How can we pay authors what they deserve?
- #FutureChat: How can we pay authors what they deserve?
- Author Emma Chapman on the road: Indie Book Crawl
- Genre and the Howey AuthorEarnings reports
2 weeks 19 hours ago
- A couple of quick notes
2 weeks 1 day ago
- Incomes for self-pubs vs. trad pubs aren't equal
2 weeks 1 day ago
2 weeks 3 days ago
- I said
2 weeks 3 days ago
- A little odd?
2 weeks 4 days ago
2 weeks 5 days ago
2 weeks 6 days ago
- Thanks for the note
2 weeks 6 days ago
- Readers ARE being asked to boycott Amazon
2 weeks 6 days ago
Tweets from @thefuturebook
TheFutureBook Early bird rates: @TheBookseller's Children's Confab (what works? what doesn't?) 25 Sept @SouthbankCentre | t.co/A96FUsmP6c
TheFutureBook RT @melvillehouse: Amazon wants Hachette to stop “using its authors as human shields” t.co/XNM39qXj2e
TheFutureBook "Our collaborators...[are] paid to write, but save their names to build their own careers." Kevin Conroy Scott t.co/8Jy4rSpyIi