Vive la difference: Why all digital books should look the same

I started my publishing career at Taylor & Francis when they were much smaller than they are today. Back then they used to have a system for books, particularly conference proceedings, that they didn't expect to sell very well. The book editors would supply the books as CRC (camera-ready copy) and try as well as they could to have contributors print (type?) the chapters in fonts and type sizes that most closely matched one another.

All we did with the text, in the production department, was send the contributors glossy paper and then briefly check before passing on to print. As you can imagine these things were a hotchpotch of referencing, formatting and so on. They went against the grain, because our work was all about consistency, and it broke our hearts to seem them go out.

What has that got to do with now?

The type of inconsistency we see today inside ereaders capable of displaying rich content mirrors these CRC books. I'm not talking about the internals of individual books, but the ereader when viewed as a package. When I open an ebook reader I am typically faced will all manner of shapes and sizes of cover across my faux bookshelf, and then when I enter a book I'm faced with varying ways of presenting headings, images, and so on, and I can't help thinking that it would be more attractive to be faced with something that was more consistent across the whole app.

Note: I'm suggesting here we view the app as the book and the ebooks as the chapters, this is the best analogy I can arrive at.

There have been some moves in this direction by Readmill, for example, the UI of which I like in places but not wholly in others. However, to talk about the specifics of style actually goes beyond the remit of what I'm discussing here. The point I wish to make is that a reader doesn't need variety of style, they need a consistency of style and variety of content.

So you're saying, 'get rid of covers'?

I'm not suggesting we do away with the covers, on the contrary but we present them in a way that is consistent, intuitive and favoured by the reader, and when they arrive at their content it also looks the way they generally like to see it without fiddling around with fonts and type sizes for each book.

Not only will the app remember their settings across all books, but most of the presentational choices will already have been made by clever designers who understand UIs and UXs, so there is less work for readers to do before they can get reading.

We don't want to lose control, surely?

Publishers have already lost much of the control they had in print to control fonts and layout. Currently ereaders strip out a good deal of formatting and then readers choose from a limited selection of fonts the one they find most comfortable to read. Arguably, there isn't really much control left to lose.

So how does all this help us regain control?

It leads us in a direction where an app developer might design an app that is brilliant for displaying technical content, for example, or one that is super for children's books. An app doesn't need to be a swiss-army knife as long as for one type of content it is ideal. So when the reader wants to read that type of content they go to that app and thanks to the fact they bought the book from the source (i.e. the publisher) they can open it in this app like any other.

And so we've returned once again to the discussion of the book as API, something that would supply an opportunity of greater freedom to developers and app designers, and provide readers with internally consistent apps that are intuitive to use and give them the books they want the way they want them.

Where does this leave the publisher?

The publisher can if they choose develop apps as well, but they are not required to do so. And once the API is in place, they can focus entirely on creation of the assets, around which apps will be created, rather than presentation and distribution of content.

No longer will publications be hobbled by the restrictions of the ereaders content must be shaped for, and, as the apps improve, the same content, stored in an intuitive way, can be presented in fresh and innovative ways without the publisher having to make alterations to each and every book at an (X)HTML and CSS level.

In fact, publishers should be able to forget about HTML and CSS entirely because content should be platform and language agnostic as far as possible (hence the recommendation elsewhere of JSON).

And for the developer?

Once the developer has created the app around a consistent API, then they can sit back and let new content feed into it automatically.

Follow @sketchytech