The Ebook Design Features Grid

Introduction

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.

Since image embedding is kind of iffy here on futurebook, you can find an image of the table here and the HTML version is here.

The features

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.

Harder

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.

Hardest

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.

Conclusion

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.

Comments

Baldur, I'd be grateful if

Baldur,

I'd be grateful if you could point me at the detailed documentation of the specific features of each of the specs comprising the Open Web Platform that are implemented by, for example, iOS 6 Safari.

Re: the criterion for something being in the platform being that it's achieved W3C Recommendation status - that's clearly incorrect. By that token we shouldn't use HTML5, or most CSS3 modules. Clearly the Open Web Platform comprises specs that are in various states of maturity in W3C process. Just as clearly there's no real documentation of what that collectively is. I'm not suggesting holistic documentation wouldn't have the complexity problems you allude to, only that you are setting up an artificial straw man by claiming that the browser-based instantiatoin of the web platform is somehow amazingly well documented.

Re; XHTML vs. HTML: it's not just for reading system implementors that EPUB content being guaranteed to be XHTML can make life easier. A lot of publishers already have XML-based content and tools. Dealing in XHTML makes use of those tools convenient. And most HTML/browser tools accept both XHTML and "tag soup" serializations. Fundamentally, "tag soup" content is much harder to manipulate downstream and is overall a less valuable asset. The decision for EPUB to stick with XML is debatable but in any case the cool kids would argue for JSON not "tag soup". But if you are a publisher creating say 5,000 eBooks - why in the world would you want to invest the resources only to get "tag soup" HTML rather than XHTML?

If all someone wants to do it get content to render online in (today's) browsers, doesn't care about delivering through channels, doesn't care about maximizing accessibility, doesn't care about subsequent reuse of generated content - basically either doesn't need a workflow that scales or has a very narrow workflow by virtue of how their content assets are structured - sure then going straight to the browser may be the right choice in that narrow situation. There's always a consituency for expediency, and "badges? we don't need no stinking badges!" isn't always the wrong attitude. But if you want content that's usable offline, accessible, interoperable across distribution channels and reading systems, and reusable into the future, you want something more structured. Of course anyone could roll their own solution - which would then look a lot like EPUB - and some have. But the leverage from a homegrown solution is infinitely less than from adopting broader standards. If you're Facebook you don't need that leverage, but few people in publishing have an ecosystem that is sufficient unto itself.

It's true that IDPF is investigating the possibility of standardizing a DRM that would make protected EPUB files more interoperable for consumers than they presently are with silos of proprietary DRM. That doesn't imply that IDPF as an organization or I personally are pro-DRM. My POV is: if some publishers are going to continue to require DRM in some circumstances (which seems self-evident), then consumers and the industry may be better off with a simple interoperable DRM, if such could be established. If the very fact that IDPF is investigating this proposition is sufficient reason for folks to abandon EPUB that would seem a bit perverse to me. Especially because browser-based solutions often enforce more draconian control over and monitoring of content access than offline reading systems even when the latter utilize DRM.

Baldur, I'm truly sorry that you're still standing on the sidelines. I hope at some point that, one way or another, you'll decide to actually get in the game.

EPUB 3 tools and documentation

About EPUB 3 adding "more complexity" than the web platform and offering "no tools and useless documentation":

Re: "useless documentation", folks can read the specs at http://idpf.org/epub/30 and decide for themselves if they are "useless". I'm biased but think they stack up rather well in readability and usefulness vs. many other formal specifications. And then look at the introduction and accessibility best practices from O'Reilly (free chapters of forthcoming book). More is needed, for sure.

Re:  "more complexity", I think to the contrary EPUB 3 simplifies and clarifies how to use the Web platform for reliable, interoperable, offline-usable digital publications. There is no spec from W3C stating what CSS ought to be supported by a modern web browser. There's no spec saying which if any embedded font formats should be there. There's no spec that even says what image formats should be supported. The "Open Web Platform" per W3C comprises over 100 specs, and there is no umbrella spec tying it all together in general. Supporting both "tag soup" HTML and XHTML means that you need more complex tools and have to handle malformed content. EPUB only supports XHTML which reduces rather than adds complexity, other than for hand-written content which is no longer the design center of the modern web platform and doesn't scale. There's 100 ways one might implement synchronization of prerecorded audio and text display. Sure you can bang out a web app that does it somehow, test it in a couple three browers, and Bob's your uncle. But that doesn't mean that content will work beyond the particular browser versions you happened to test against, much less have longevity. And your home-grown way to implement the feature will definitely not be interchangeable anywhere else. Whereas EPUB 3 defines a particular way to do it, declaratively - Media Overlays - that is already supported in multiple reading systems including iBooks.

Tools for sure are still a gap. There's a bit of a chicken-and-egg situation as reading systems are still in the process of the (major) upgrade to EPUB 3. But EPUB 3 authoring support is available from InDesign CS6, Oxygen XML editor, Aerbooks, and many many more to come. We may not have great tools for generating media overlays yet, but we will have. With home-grown web apps that level of tooling just isn't going to happen. 

So I predict within the next year the opposite trend. Publishers will be using EPUB 3 as a way to get to the web more simply and to leverage off-the-shelf tools and libraries for rendering.

We have a long way to go to get there but there's 400 IDPF member organizations and a growing ecosystem of open source contributors and commercial solution providers working constructively to get us to an interoperable global open standard - the Open Web Platform for digital publications. Please help us make it happen!

We've been through this before

Baldur Bjarnason's picture

This is a reply to Bill McCoy’s comment. His notes are in italics.

Re: “useless documentation”, folks can read the specs at http://idpf.org/epub/30 and decide for themselves if they are “useless”. I’m biased but think they stack up rather well in readability and usefulness vs. many other formal specifications. And then look at the introduction and accessibility best practices from O’Reilly (free chapters of forthcoming book). More is needed, for sure.

We’ve been through this before, months ago when I wrote “It’s time to treat ebook developers as developers”. Specifically this part: http://www.baldurbjarnason.com/notes/treat-ebook-developers-as-developer...

The points I make there, to summarise:

The spec doesn’t cover the behaviour of individual clients in enough detail. You can have two fully-conforming implementations that still vary in behaviour. A specification can never work adequately as documentation for individual client behaviour, which is what we need. It documents the ideal not the details of actual implementation.

And best practice guides, even how-tos, useful as they are, aren’t documentation. They don’t tell us how EPUB3 clients behave nor the exact details of what each client supports.

I’m surprised that you raise this point because I know for a fact you’ve read my “It’s time to treat ebook developers as developers” post. We’ve spoken about it in person.

There is no spec from W3C stating what CSS ought to be supported by a modern web browser.

Yes there is. That’s what a W3C Recommendation is. Any CSS spec that is a W3C Recommendation is something the W3C recommends browsers implement. Couldn’t be clearer. Moreover, most of what has become a CSS WG W3C Recommendation is supported by modern browsers.

There’s no spec saying which if any embedded font formats should be there.

Yes there is. The WOFF format is what the W3C recommends browsers and the rest support. (Or it will be once it becomes a proper Recommendation.)

Also, this isn’t as essential in the web world as it is in the ebook world because we have documentation. The browser vendors document what font formats their browsers support and what features. Most of them focus only on WOFF because they too consider WOFF to be the future standard font format for the web.

And, actually, it’s a bit annoying that IDPF hasn’t gone down the WOFF path as well.

There’s no spec that even says what image formats should be supported.

Again, this is covered by documentation. JPEG and PNG are the baseline. All browsers are working towards supporting SVG as images. Hardly a trade secret.

Also, the web way has the benefit of telling us what we can use. Putting it in the spec like EPUB3 does only tells us that all clients should support it. It doesn’t tell us which of them do and to what degree, which makes it useless in practice.

The “Open Web Platform” per W3C comprises over 100 specs, and there is no umbrella spec tying it all together in general.

That would be an insane, over-complicated, document. They tried that approach, both in CSS and in HTML and it doesn’t scale. You end up with a too complex spec that nobody can support and takes forever to get fully implemented. Modularisation ftw.

Supporting both “tag soup” HTML and XHTML means that you need more complex tools and have to handle malformed content. EPUB only supports XHTML which reduces rather than adds complexity, other than for hand-written content which is no longer the design center of the modern web platform and doesn’t scale.

You’re thinking about this from the perspective of someone implementing an EPUB3 reading app. Requiring XML compliance does not simplify the life of developers. It cuts us off from a huge ecosystem of HTML5 tools, because most of those tools are built with the assumption that the default parsing model will be the HTML5 parsing model, which is a far cry from the tag soup of old.

Now that the HTML5 parsing model has been outlined in detail, most of the stigma associated with using HTML (as opposed to XHTML) has disappeared. The XML requirement prevents us from leveraging most CMSes for ebook work, not without extensive modification in any case. It also makes it difficult to convert a website into an EPUB3, which cuts us off from a vast library of existing content.

(Converting existing HTML content to EPUB3 is a non-trivial exercise.)

There’s 100 ways one might implement synchronization of prerecorded audio and text display. Sure you can bang out a web app that does it somehow, test it in a couple three browers, and Bob’s your uncle. But that doesn’t mean that content will work beyond the particular browser versions you happened to test against, much less have longevity. And your home-grown way to implement the feature will definitely not be interchangeable anywhere else. Whereas EPUB 3 defines a particular way to do it, declaratively - Media Overlays - that is already supported in multiple reading systems including iBooks.

Media Overlays would be neat if it were a single spec separate from EPUB3 so that other systems could use it as well. But, yeah, as I outlined in the grid and in the post above, EPUB3 does address multimedia. I even said that it addresses the problem ‘thoroughly’. Strange how you missed that point.

Tools for sure are still a gap. There’s a bit of a chicken-and-egg situation as reading systems are still in the process of the (major) upgrade to EPUB 3. But EPUB 3 authoring support is available from InDesign CS6, Oxygen XML editor, Aerbooks, and many many more to come. We may not have great tools for generating media overlays yet, but we will have. With home-grown web apps that level of tooling just isn’t going to happen.

Tools aren’t just a question of authoring tools but of testing, development, and deployment tools. And yeah, web apps have an awesome level of tooling for those three pain points. Authoring tools do little more than make up for the fact that we’re cut off from building on most web-based CMSes by virtue of the XML requirement (and the CSS limitations, most apps continue to view positioning in reflowable paginated chapters as an optional extra we don’t need).

And using ‘home-grown’ to describe a platform that is the foundation of apps ranging from Twitter, to Facebook, to Gmail? Disingenuous.

We’re working blind with ebooks, with one leg strapped to a trashcan. We can’t tell why things go wrong, when they go wrong, and deploying a book to devices for testing involves an intricate plan involving half a dozen USB cables and hub hacks. It’s insane.

So I predict within the next year the opposite trend. Publishers will be using EPUB 3 as a way to get to the web more simply and to leverage off-the-shelf tools and libraries for rendering.

I doubt it. Not unless platform vendors sort out their act.

We have a long way to go to get there but there’s 400 IDPF member organizations and a growing ecosystem of open source contributors and commercial solution providers working constructively to get us to an interoperable global open standard - the Open Web Platform for digital publications. Please help us make it happen!

I don’t see why I should help make the IDPF’s plans happen when I don’t agree with those plans (DRM and spiralling complexity). The IDPF’s DRM effort is reason enough on its own for me to stand on the sidelines and just do my own thing.

(And, yes, I’m not the only person who feels that way. DRM is more divisive than you seem to realise.)

I also think there’s a slightly saner way of getting the “Open Web Platform for digital publications” done and that’s by skipping EPUB3 altogether and focusing on the web first. Which happens to be a tactic many I’ve spoken to are pursuing.

Superbly valuable

Another winner in the "picture worth a thousand words" sweepstakes! Thanks for all the effort.

Post new comment

You will need to register to comment on Futurebook.net. Register here This will take less than a minute.
By posting on this website you agree to the Bookseller Comments Policy. comments go live immediately, please be relevant, brief and definitely not abusive.
Enter your FutureBook username.
Enter the password that accompanies your username.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <b> <i> <strong> <br>
  • Lines and paragraphs break automatically.

More information about formatting options

Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.