e-Paper and e-Ink
Image by Terretta via Flickr

Kent’s recent posts discussing new e-reader devices and the possibilities of new textbook approaches for things like the iPhone got me thinking about the effect of this tidal wave of new technology hitting the market. Each device seems to have its own file format, each its own interface. While I’m usually a huge proponent of a varied ecosystem–monopoly bottlenecks are bad for both consumers and content providers–this flood of new devices is problematic for publishers.

Kent wrote about efforts to port textbooks to the iPhone/iPod Touch platform, which is a good example here. From the numbers I’ve found, there are about 45-50 million iPhones/iTouches out there in use. That may seem like a big number, but most scholarly publishers create products for niche markets, often small niche markets. So realistically, if you’re a textbook or journal publisher, only a tiny fraction of those 50 million users has any interest whatsoever in your products. The converse is true as well–only a small percentage of your customers owns an iPhone. For the journals we publish, we see between 0.4% and 1% of traffic coming from iPhones/iTouches. Is it worth investing in developing new tools for less than 1% of your customers? What happens to your investment if you choose a device/format that doesn’t catch on and dies off?

In order to reach all of your potential customers, to maximize the return for your investments and efforts, you need to create products that are available to your entire potential market. To do this, you either need to focus strictly on interfaces that most everyone can access (print on paper, the computer screen), or create new products that function across a variety of devices.

This is where it gets tricky. The same ePub file displays very differently in Stanza, Adobe Digital Editions, and web browsers. Most iPhone functionality doesn’t exist on a Kindle. The iPhone has a color touchscreen, can play video, has access to the entire internet, a built-in GPS and compass, a video and still camera, and many other features the Kindle lacks. As such, the cool new interactive-video-geographically-aware-augmented-reality features you’re building into your new textbook are going to be a wash for Kindle owners.

So you either need to create a version of your textbook/journal and its enhancements for every single device out there, or you end up with one kludgy version that sort of, kind of works sometimes depending on what the reader is using. If the expensive new tool you developed can only be used by 0.4% of your buyers, the extra sales it generates may not be enough to pay for all the work you put into it.

This is where having a monopoly in a market (or at least having market dominance by one device) is actually beneficial. Developers love the iPhone because they know that every iPhone/iPod works the same way, with the same interface. They don’t have to account for a near infinite amount of possible hardware combinations. It’s the same reason that Macs traditionally “just work”–the hardware is strictly defined to a limited set of components. In the Windows/Linux world, no two computers are the same. This creates competition in the market and lower prices (good), but software ends up being cobbled together because it has to address so many component possibilities (bad).

I’ve argued that one essential way to move the e-book market forward is to settle on a standard file format, the most likely being ePub, despite its many obvious deficiencies. The idea is that this would help level the playing field–all devices would work with ePub files so you could buy your e-books from any source and move them from one device to another, much like mp3 and AAC work in the music world. While that would be an improvement, it still doesn’t solve the problem here, as seen in the article linked above, the way different devices display ePub files varies wildly.

“The biggest complaint about the content of e-books today is that the quality is so low. This is not just an aesthete’s whinge. Beautiful text is readable text. It is our duty to our readers to do the best we can in e-books, just as we do in print. But despite all the promise shown by ePub, it fails, in practice, to provide the consistency that we need.”

What’s needed here goes beyond common file formats. What we need is a common set of standards, a blueprint for how devices handle those file formats. The development of web standards is probably the model to follow. Think about the many devices you can use to access the web, and how they mostly handle code to present things consistently to the reader. This is greatly due to the work of the World Wide Web Consortium (W3C), an international group dedicated to developing web standards. The W3C has had some failures, and particular companies have deliberately created their own proprietary standards to try to dominate the market (I’m sure e-reader companies won’t be above this as well, given Amazon’s current behavior). Nevertheless, having standards has greatly improved web readability over time. Viewing web pages in different browsers is no longer as wildly variant as it once was.

The good news is that such a group is already in place, the International Digital Publishing Forum (IPDF). Membership in the group is available, if you want your voice heard and your company’s needs addressed (and one should note, they’re not without their critics). The bad news is that we’re still in very early days with e-readers. If the web is any comparison, it’s taken a decade and a half to get browsers that are even close to standards-compliant. I’d like to see publishers put pressure on e-reader companies and refuse to do business with those who don’t comply with standards. That would allow us to move forward much faster than the web, where software companies had financial motives to avoid compliance. Let’s instead make their financial survival dependent on achieving compliance with standards.

The market will eventually decide on dominant devices, or at least dominant features that will become common across devices, and I’m not sure there’s anything we can do to speed that process.  A set of e-reader standards however, will go a long way toward moving things forward.  With standards established, publishers will be able to focus on our core strengths, developing great content and information resources. That certainly beats spending all our time balancing cost versus marketshare numbers for specific devices, endlessly tweaking code and wasting our efforts creating and re-creating the same resources for each new device. Until then, it pays to keep a close eye on your usage statistics to see if any trends emerge that are worth exploiting, but with the understanding that you’re dealing with a volatile and highly fragmented market. You’ll need to choose between addressing lots of small niches individually or trying to cover them all at once awkwardly.

(Editor’s Note (11 Sept 2009): Confusion over Bookworm rendering of ePub files was clarified in the comment thread, and the post has been updated to reflect this correction. Thank you.)

Reblog this post [with Zemanta]
David Crotty

David Crotty

David Crotty is a Senior Consultant at Clarke & Esposito, a boutique management consulting firm focused on strategic issues related to professional and academic publishing and information services. Previously, David was the Editorial Director, Journals Policy for Oxford University Press. He oversaw journal policy across OUP’s journals program, drove technological innovation, and served as an information officer. David acquired and managed a suite of research society-owned journals with OUP, and before that was the Executive Editor for Cold Spring Harbor Laboratory Press, where he created and edited new science books and journals, along with serving as a journal Editor-in-Chief. He has served on the Board of Directors for the STM Association, the Society for Scholarly Publishing and CHOR, Inc., as well as The AAP-PSP Executive Council. David received his PhD in Genetics from Columbia University and did developmental neuroscience research at Caltech before moving from the bench to publishing.

Discussion

11 Thoughts on "New Technologies and the Need for Standards"

The way forward is to separate content and form, precisely what a good XML format does, and we have an excellent XML format in ePub.

The publisher should create ePub once and once only. The eBook reader would render this ePub into whatever the end user likes, PDF-like pages, colored text, audio for blind, etc. Problem solved.

The fact that ePub looks different on different devices has nothing to do with ePub, but the devices or the people writing the device drivers.

That’s the idea behind standards. If I create a document, it should look the same on all devices, if those devices are compliant with the standards I used to create the document. On the web, if I use a particular html tag, it should do the same thing in Firefox, in Safari, in Internet Explorer. My CSS should look the same on a laptop, a desktop, an iPhone, a Blackberry.

We need the same thing for e-books and the devices used to read them. Create once using standard tags and each device presents them the same way. The key here, as you note, is that we need device manufacturers to support these standards.

I think this points to a core competency publishers need to develop (or look for vendors to have), and that is “transformation capabilities.” With a strong substrate of XML and a practice of XHTML transformations or other techniques, a broad array (not all, but a broad array) of devices and formats can be supported — ePub, .mobi, rtf, PDF, HTML, LRF, txt, and others. I think it’s unrealistic to think that everything will behave the same on each device — my Kindle doesn’t have a color screen and has a different UI, so no amount of standardization at the data level will make the Kindle have a color screen. And I think this is a crucial distinction — user interfaces are much more complex and variable than underlying data structures. I can’t think of a user interface that isn’t variable — from telephones to keyboards to drinking fountains to shoe-securing systems, they’re all a little different and require some adjustment, even though the plugs and pipes and streets are pretty standardized.

The user interface seems to be what we’re really discussing here. Its effect on even standardized data can be significant, and hide/challenge/break even the most standardized data feed.

Compliance only means that it works with the standard. The UI can be very differently realized beyond the standard.

Kent, I think there are two related, but different issues in play here.

The first is the question of file formats and standards. There’s absolutely no reason why the same ePub file should look different in Stanza from how it looks in Bookworm or the Kindle or any other e-reader. It’s text on a screen, beyond that, the interface doesn’t enter into it. Why does Bookworm ignore CSS? Why does Stanza do odd things with margins? Design strikes me as something that most programmers don’t understand or are suspicious of, and it’s both presumptuous and counter-productive to have programmers dictating design. We need a set of standards so e-readers treat these files in the same way so designers can do actual design and layout on e-books and journals. If we want the public to adopt these new technologies, we need the products to be of high quality, and without design, layout and typography, that’s impossible. If the e-reader companies want publishers to jump on the bandwagon to make products to help sell their devices, then they need to make things as easy as possible for us. I don’t want our production department to have to make 50 different versions of each e-book. Right now that’s necessary if you want something crazy in your book, like a table or an equation or a poem or a decent layout. The marketshare for each individual device is too low to make this cost-effective. We need one common file format, and we need device manufacturers to agree to treat the attributes in that file format in a common manner.

The second issue is the interface differences and the different capabilities of different devices. That’s going to take longer to solve, and will rely on the market. Eventually, buyers will choose the devices they most want, and the most-wanted features will become common across successful devices. Right now, (as above) each device has too small a marketshare to make developing specifically for it affordable. Once the market consolidates more, you’ll be able to see which devices your audience has chosen and cater your products to those devices. It should also grow easier to make products that can be used across devices, if they start sharing common features/interfaces.

As a contributor on this site, I don’t have the right permissions here to edit already published material. Kent?

I think we all agree that there should be a common standard, and the output should look good too on the end device, with all typographic details like hyphenation, kerning, etc.

Where I would take issue with you, David, is that ePub should look the same on each device. ePub is only coding content, with no regard to how it looks, so an emphasized word might be coded as shout. That is all the information that is needed in the XML. On a color machine, this might show up as red. On a black and white device, it might be italic, and in a Daisy book for the blind, it might be read out louder. So emphasis is conveyed according to the output device.

I do agree that the output of things like Stanza are bad, especially with large font sizes. But that is where the ‘rendering engine’ should be improved. The ePub has done its job of conveying content.

I am working on an eBook reader using TeX, which has very good line breaking, hyphenation, etc. We have put TeX on the iPhone and it is certainly better than Stanza. So a lot of work is left to be done there.

I think it’s something we’re just going to disagree on. Layout and design are such important parts of putting a book together. A skilled designer can vastly improve the reading experience. I’d rather have those decisions being made by a trained designer than by a programmer, particularly since that wouldn’t allow for variability from book to book where it was needed.

I’ll have to check out TeX, thanks for the tip.

Comments are closed.