I follow the trends in ebooks fairly closely. Although I'm no longer affiliated with the IDPF, I'm still interested in where the technology is going.
Of late, I've been hearing a lot of chatter about fixed width layouts. A brief explanation: most ebooks use a variable width layout, meaning they resize to your screen, whatever size that screen is. This is very useful -- it means the same EPUB file can be read on my phone, my netbook, my tablet, and my massive desktop screen. When you think variable width layout, you should be thinking along the lines of most webpages.
A fixed width layout is one where it does not resize to the screen in a graceful manner. The document is designed to look a certain way, and it should always look that way and have the same proportions. When you think of fixed width layout, think along the lines of a PDF document.
Fixed width layouts are important to people who are trying to recreate what we see in magazines, comic books, newspapers, etc. And the supposed need for fixed width layout is a topic of considerable interest among the ebook production crowd. I've heard rumours that the IDPF will be standardizing it after EPUB3 is complete.
I have several arguments against this focus on fixed width layouts, and they come down to these: the IDPF should be focusing on more important issues; the community should be solving more relevant problems; and we've already solved the fixed width issue.
I'll address these point-by-point.
The IDPF's Focus
The IDPF is a great organization, and they do important, meaningful work. However, they have bigger fish they could be frying -- namely, public relations, developer outreach, and EPUB3.
Public Relations - I am on two dozen or more ebook-related forums. I regularly see smart people say things like, "Well, there are several ebook formats. Kindle, iBooks, EPUB..." No one seems to realize that in most cases, the formats they're reading came from EPUB. EPUB can transform into anything; not everything can transform into EPUB. Smashwords, for example, is making a mint off this lack of awareness -- people think that they need a service to make their books available in all these different bookseller formats, not realizing that all of them accept EPUB.
Why are people so ignorant? Because the IDPF is not engaging their constituency. I spent years explaining to people the difference between an ebook and an ebook reader, for example. The IDPF should own the hearts and minds of the ebook community -- but precious few people even know who they are.
There is a massive self-publishing movement out there. Why isn't the IDPF providing authors with tutorials on how to make an EPUB? Why aren't they hiring third party developers to make EPUB output plugins for Word? Why doesn't the typical author, editor, or small publisher have any idea who the IDPF is?
Developer Outreach - The IDPF has almost zero presence in the developer community. Oh, they're well-represented by the big companies, but there are a host of people developing ebook apps in their basements. Why isn't there a developer tutorial for EPUB? Why isn't an EPUB validation service hosted from their site? Why isn't there sample code posted? Why isn't there a service to confirm applications as being EPUB-compliant? Right now, when you develop for EPUB, there's no way to know if third party software is compliant to the specs.
EPUB3 - I've watched EPUB3 getting savaged by developers on Twitter and elsewhere. The specs themselves are already far later than the IDPF would've hoped, and significantly under-specified in a number of areas. The IDPF has traditionally punted compliance wording -- it's time for that to end, especially since EPUB3 supports scripting, a morass that they've barely touched on.
With all these issues, the IDPF wants to waste their time on fixed width layouts? I sincerely hope that isn't the case.
More Relevant Problems
There are two notable camps in the ebook development world -- software engineers and designers. Of late, the designers have been ascendant. This has been a very good thing -- the quality of ebooks produced has dramatically risen in the last few years. But I think its day is done. Designers focus on the beauty of the ebook -- the art of it. But art isn't what we need, at the moment, and especially because a lot of their sensibilities have been formed by the print world. And the print world is, frankly, becoming increasingly irrelevant. We're in the midst of a paradigm shift, and designers are still going on about the beauty of typesetting.
When I get on a bus and see people happily reading on the tiny screens of their smartphones, reading things that have had zero thought put into their typesetting, that tells me that the war for "good enough" typography has been won. We get "good enough" typography free with technologies that originated with the web. A designer will say "but it's not good enough," to which I say, "people are using it."
We have more important things to do than to try to recreate the beauty of print in an electronic medium. As I will point out below -- it's already been done. Why not focus on bigger issues that will enable ebooks to be more than just "novels on your screen?"
Here's a few items: common DRM, interdocument linking; social discovery of books; ebook lending; and shareable annotations.
Common DRM - Right now, EPUBs get transformed into a host of formats, each one only usable on its parent platform. You buy a book on the Kindle, and you can't read it with your Kobo or your Sony Reader. Things are getting better in this regard, but that's only a sign of Amazon's dominance -- I can read the same ebook on my phone, my desktop, or my Kindle. But that's not enough -- I want to be able to read it on the device of my choice, even if that's provided by another bookseller.
Moreover, as I'll discuss in a moment, I want to be able to lend my ebook to someone using another bookseller's device.
We need a common DRM for ebooks. Yes, some will argue, what we need is no DRM, but since authors will never go for that, a light, non-intrusive DRM would be extremely useful.
The battle for a common DRM is less a technical one and more a social one. Why would Amazon give up its dominance? The big boys don't play well together, but there are various business models where a common DRM could be most useful to even them.
Interdocument Linking - Imagine you're reading a textbook, and there's a footnote. You click on the footnote, and a screen opens, inviting you to purchase the book that's footnoted. Maybe it even provides you with a sample of the book. You buy it. The next time you click on the footnote, it jumps to exactly that page in the textbook you've just bought.
This is not possible with today's technology.
Social Discovery of Ebooks - One of the biggest questions plaguing the ebook world today is, "How do we get consumers to notice our books?" There's just too many, and the downside of the self-publishing revolution is that a lot of crap is getting published, which drowns out the good stuff. For example, my friend Michael Shean's ebook, Shadow of a Dead Star has gotten rave reviews, but is still not selling anywhere near what it deserves, and Michael spends significant chunks of time to market it.
Instead of wasting time with fixed width layout, why aren't the ebook developers of the world building apps that let me "Like" a book in Facebook style and have all my friends notice? Why can't I simply click "Share" on an ebook, and have it go out to my friends? Or even better -- why isn't there an app on Facebook and Google+ and Twitter and on its own site that lets me search for books that are like books I've already given a good rating?
The ebook development community is focused on metadata for ebook discovery. This is foolish. The battle for metadata has been won -- it just needs to be used appropriately. But metadata won't tell me if a book is to my taste -- my friends will.
Ebook discovery will be social. And the company that builds a social discovery tool, and gets traction, will be very wealthy.
Ebook Lending - I should be able to buy an ebook and lend it to a friend. I can do this, to a limited extent, on single platforms -- i.e. I can lend my Kindle ebook to another Kindle user. I should be able to lend it to anyone. There is no reason why I can't do everything with an ebook that I do with a paper book, and more. Right now, that isn't the case.
Shareable Annotations - Imagine -- you're a teacher. You get the textbook, and you make notes on it. Then, you click a button, and every student in your class has your notes on the textbook. Those students make their own notes -- and sometimes, notes on your notes. They click, and those notes are shared with anyone they choose.
Now, that's powerful. And not possible today. Why?
These are just a few of the interesting problems the ebook community could be tackling. But they want to focus on fixed width layout...and really?
The Problem Has Been Solved
We have PDF, which duplicates print more-or-less exactly. It can be hyperlinked, it can be interactive, etc. etc. What more could a fixed width layout fan want?
Perhaps they don't like PDF. Maybe they're not Adobe fans. Maybe they find the files bloated. They want something like EPUB, but for fixed width layout. Take a bunch of static content, wrap it up in a zip file, and distribute it.
No, no, no, they say. We don't want to be shunting binary files around. We want static content in XML!
Wait...isn't that SVG? Which is already a blessed specification by the IDPF, and totally usable in EPUB3?
This problem has been solved...and solved...and solved.
I understand how seductive it is to want beautiful ebooks. I understand how much it seems to make sense to take the detritus of the paper book world and convert it into electronic format, so we can say, "Here, see! You can have your glossy magazine/manga/newspaper in ebook format!"
But those battles are won. The designers, the ebook software developers, and the IDPF have much bigger problems to solve that their audience (authors and readers) would love to see solved.
Stop wasting your time.
The Fixed Width Layout – A Waste of Time. by Ben Trafford, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.