iPad commercial

Ebooks Get the Respect They Deserve at 'Download the Universe'

REBECCA J. ROSEN - Rebecca J. Rosen is an associate editor at The Atlantic. She was previously an associate editor at The Wilson Quarterly, where she spearheaded the magazine's In Essence section.

FEB 29 2012, 3:15 PM ET

Ebooks aren't just electronic versions of printed books. They present a different reading experience and, in certain cases, demand their own reviews.

For many books, an ebook edition is not significantly different from a printed copy. It's a straight line through a text-only narrative, the words the same and in the same order, regardless of whether their corpulence is ink on a page, e-ink on a screen, or mere light behind a pane of glass.
But increasingly, publishers and writers are creating content specifically for e-readers ranging in simplicity and cost from your basic black-and-white Kindle to the more versatile and visually lush iPad. There are two major drivers of straight-to-ebook content. One is financial: Books that were either far too long, far too short, or just too darn narrow in scope to make economic sense in print are finding a life in e-form. The other driver -- and this is particularly fueling the growth of iPad books -- is that the tablet medium offers new possibilities for what a book can be, leading some to say that even calling them "books" at all is a bit of a misnomer. These "books" are interactive, awash in multimedia, and may even have a social layer that allows for sharing and discussing.
All this to say, e-readers have opened up a period of great innovation in how we convey and consume "books," but, as of yet, these new products have not met with the sorts of rigorous and routine reviews that new printed books receive. But a new project, Download the Universe, aims to change that. Led by a set of some of the top science writers in the country -- including Carl Zimmer, Steve Silberman, and Atlantic contributor David Dobbs -- the site aims to provide reviews of new straight-to-ebook science books. Carl Zimmer writes, introducing the project,

It is still tough for readers to discover new science ebooks. Traditional book reviews limit themselves to works on paper. Some ebooks may appear in computer magazines, but buried in reviews of laptops and printers. In between, we need a community.
Download the Universe is a step towards that community. It is the work of a group of writers and scientists who are deeply intrigued by the future of science books. (You can find our names and links to our web sites on the right.) Here we review science ebooks--broadly defined, except for ebooks that are just spin-offs of print books. We hope to build up a library of titles that curious readers can browse. Some reviews will be positive, others negative. We welcome your own judgments, and we look forward to vibrant (but civilized) discussions in the comment threads. We will also write essays from time to time about the changes that publishing is undergoing.

Of course, there are plenty of ebooks that aren't science books and therefore won't fall under Download the Universe's scrutiny, but of all the places to begin a project like this, science books seems like a fertile place to start. Science books naturally present a great opportunity for high-quality visual content -- whether virtual dissection, to-scale interactive maps of space or the oceans, or the ability to zoom way in on the tiny structures that make up a cell or a molecule. Arecent review by Deborah Blum of Theodore Gray's The Elements demonstrates this perfectly. Blum writes:

I hate to admit this but for some time - okay, almost the two years since it was published - I cherished an attitude about Theodore Gray's dazzling e-tribute to the Periodic Table, The Elements. It was too jazzy, I told myself, too flashy. Of course, what I meant was that it was so successful.
It's easy to maintain that envy about The Elements even today. As The Wall Street Journal noted in a recent story on e-publishing, this virtuoso exploration of our chemical world remains "a runaway best-seller", selling more than 250,000 electronic copies and generating more than $2.5 million in income for Touch Press publishing.
But I'd like to here to get past author envy and take a serious look at what makes this publication so exceptionally successful - and, in fact, so exceptional. ...
Obviously, in its app-like format, Gray's publication emphasizes the visuals over text. It's enticely easy to play with the virtual iodine-laced chewing gum package and skim over the accompanying paragraphs. And that's too bad because if you take the time, the writing is terrific - funny, smart, knowledgeable, friendly. In his introduction, Gray writes: "The earth, this iPad, your foot - everything tangible - is made of the elements. Your foot is made mostly of oxygen, with quite a bit of carbon joining it, giving structure to the organic molecules that define you as an example of a carbon-based life form. (And if you're not a carbon based life form: Welcome to Earth....)." There were times when I found the text even more fun than the virtual elements.

This sort of review, and many of the others on Download the Universe, is an indication that ebooks are maturing as a genre. The conversation about what they are and whether they will destroy reading is subsiding (even the old guard at The New York Review of Books has jumped on the ebook bandwagon, as Alexis Madrigal pointed out recently), and now top reviewers are taking a look at them for their content, not their form. It's fitting too that this early effort at ebook criticism finds its home in the pages of the web, not the pages of a magazine or newspaper. The web takes its digital brethren seriously.
One website that has been surprisingly slow to the ebook-reviewing party is Amazon, perhaps the ebook industry's ringleader. On the Amazon website, reviews of Kindle and paper editions are lumped together under one title. This has unfortunate consequences. Take, for example, the wonderful book A Visit From the Goon Squad, by Jennifer Egan, which features one chapter told in the form of a PowerPoint presentation. This chapter rendered poorly on Kindle, resulting in a handful of one- and two-star reviews from people who liked the book but hated the Kindle edition. I've seen this same problem for Kindle books with non-functioning table of contents. Besides the problem that this drags down the rating of great books, for consumers, it makes it hard to compare Kindle editions or choose whether to buy a print or electronic version.
To fix this problem, Amazon should allow for edition-specific reviews -- not just of Kindle editions, but different print runs as well -- which would have the added advantage of giving consumers better information regardless of the medium of their purchase. Doing so would be a recognition of what the Download the Universe project acknowledges at its core: Print and electronic versions offer different reading experiences and require independent review spaces. Reading is about more than just words on a page -- or screen.

Image: Reuters.

Introducing the book (repost)

Javascript in ebooks

There is a way to solve this problem and keeping almost everybody happy.

But first the case against and for javascript in ebooks.

AGAINST

The reasons not to support javascript are quite numerous. When you list them all I’m almost embarrassed about how much of an ebook javascript supporter I’ve been in the past. (I still am, in a way. But more on that later.)

Problems for ereader vendors:

• Support. Your ereader becomes an app platform with all of the responsibilities and problems that follow. The documentation and support requirements of a non-JS ereader are extensive enough, now they are expected to add javascript.
• Security. Being an app platform and because ebooks are persistent downloads, ebooks potentially face more serious security problems than a website would. Ebooks are more extensive than the persistent widgets we’ve used in the past and many ereader devices don’t have as neat an update story as you’d need to deliver security updates.
• Consistency. Nobody has delivered solid javascript support in a reflowable, paginated, ereader app yet. (iBooks is too buggy to count as solid.) We have no idea whether the various ereader vendors are even capable of delivering javascript support in a consistent manner. (Readium might solve this problem.)
• Context mismatch. The javascript DOM and APIs all assume that they are run in specific context. When you implement a browser-based ereader app you create a context mismatch where the book’s javascript is executed in the app’s context. This creates bugs both in the book’s JS and in the app and opens the app up to a host of security problems. (It’s a bit as if every web page were allowed to execute arbitrary Objective C code in Mac OS X’s Safari browser, rewriting the UI, preferences, rendering, etc. at will.)

Javascript in ebooks also has problems for authors/devs. Where many ereaders have no update story, ebooks are worse. One of the core concepts in web development is iterative development. Every website is a living thing that is regularly updated and tweaked to match the changing browser landscape. Javascript-heavy websites that aren’t updated often end up being unusable when the market takes an unusual turn. There are many pages, for example, that still don’t work on the iPad, despite it having a screen resolution and CPU speed that was considered desktop mainstream only a few years ago.

Ebooks that rely on javascript are, quite simply, going to stop working some day. Any ereader vendor who wants to support JS in ebooks has to support automatic, silent, background ebook updates so that ebook authors can push out fixes when (not if) the books break.

Apple’s current tactic with iBooks is worse than useless:

• Different APIs enabled depending on whether you are in an ePub or in the iBooks 2.0 format. No documentation to help you out with the differences.
• No auto-update story for the ebooks. When an update breaks a book (which happens almost with every iBooks release) it remains broken until the reader re-downloads it. That is, if the author has sent Apple an update and if Apple has approved it.
• If iBooks were a browser it would be the buggiest browser maintained. The latest releases of all browsers are by far more stable, more documented, more programmer-friendly than iBooks. Even the worst mainstream browser I can think of (which would be Android’s default browser) isn’t as bad as iBooks.
• All documentation is secret. You only have access to it if you are publishing through iTunes Connect. Anybody going through an aggregator, or freelance ebook developers who aren’t publishing themselves, aren’t supposed to have access to the documentation or the testing tools Apple provides.
• No console. No debugging tool. No DOM inspector. No breakpoints. No nothing. iBooks is a dark, secretive, hellhole that doesn’t tell you anything about anything. It’s next to impossible to know what’s going on if something isn’t working.

In short, iBooks is a nightmare to develop for. It is the platform from hell. It offers more design features than other platforms, and is the only one that supports javascript, but, frankly, those features aren’t worth the pain involved.

So, if iBooks is any indicator of what the authoring experience for ebook javascript will be like, then you can count me out.

Thanks, but no thanks. I put a higher value on my sanity than that.

There’s one additional hurdle. One that most people keep misunderstanding when I state it: Apple won’t let third party ereader apps ship with javascript support.

They think I’m saying that Apple won’t let ereader apps ship with more or better javascript support than iBooks, or that Apple will be heavy-handed in protecting iBooks from competitors.

They may well, but that’s not the reason. Apple wouldn’t let ereader apps ship with comprehensive javascript support even if they didn’t make iBooks and weren’t in the ebookstore business.

Why?

Because an ereader app that supports javascript in ebooks is, as I said above, an app platform and Apple doesn’t allow competing app platforms ship through the iOS app store. They just don’t. They even sometimes block apps that vaguely smell like app platforms, like customisable dashboards and the like.

Allowing an app platform to ship via the iOS app store would be a major policy change at Apple.

The only exception I can think of is if an ereader app adds javascript support that is horrible, buggy, and unusable, Apple might let that slide, but that won’t help authors, for obvious reasons.

Third party ereader apps just aren’t going to ship with javascript support on iOS and iOS is too big a chunk of the tablet market to be ignored. Nobody is going to author javascript-enabled ebooks when they’d only work in less than 10% of the market. It doesn’t matter what the ereader vendors keep saying, or what IDPF says, it just isn’t worth it for authors or publishers. A delusion repeated like a chant still remains a delusion.

FOR

With all those problems, why have I always been in favour of javascript in ebooks, even to the point of tweet-flooding the patient folks at IDPF about the issue?

Simple: We don’t know what an interactive ebook looks like, yet.

We have plenty of ideas. Quite a few antecedents from the days of pre-web hypertext. Then a few more from the era of CD-ROMs. These interactive works vary enormously and require different capabilities. Then we have the web.

All of these platforms have allowed some sort of programming and many of the common features require it.

We are only now, after two decades, reaching a point where we have a bit of an idea of what common features the web requires and have started to implement them declaratively (like some of HTML5’s form features). Even so, we still rely on javascript because it’s just simpler than going through the process of inventing and then standardising declarative methods of authoring the same features.

We aren’t even close to this for ebooks. We don’t know what we want. We don’t know what we need. We don’t know what will be popular or enjoyable. What we don’t know can’t be implemented as native widgets and can’t be integrated into the ereader’s UI and chrome.

THE PROBLEM SPACE

There are several contexts were javascript might be useful in an ebook.

Main body. Running a script in the primary text of the ebook gives you access to several things. You can:

• Modify the text depending on actions (like StretchText) and outside factors (like the weather).
• Monitor the readers using software similar to our current web analytics (if network access is allowed).
• Alter the book’s content and structure based on the reader’s progress and demonstrated intent.
• Dynamically add links to the text based on arbitrary factors.

Most of these options don’t seem particularly appealing. StretchText never grew beyond a niche and I’m not sure readers are comfortable with the idea of having their book reading tracked like their web reading. Some of these options might be useful but are next to impossible to do well. (Intelligently coming up with useful/interesting changes to main content is harder than it sounds.)

Dynamically adding links might be useful, but since most uses I can think of (and most precedents) are sleazy marketdroid tactics, that’s also of doubtful value.

Still, hard to know the value when nobody’s trying.

Embedded widgets. The web equivalent would be iframes executing javascript code.

The iBooks 2.0 textbook format implements this, at least for native widgets. (I don’t know if they do so for HTML/JS widgets).

The web has plenty of examples, most of them ads. Google, I think, uses this for their native HTML5 video embed codes.

Popups and appendices. This is how a large majority of non-app interactivity works on the web. You take an action (click on an image, link, graphic) and something interactive pops up in an overlay or separate window. Then you use the slideshow, flash infographic, or whatever in that separate window or context and when you’re done you close it to return. The state of the original reading context is preserved.

Spine. A javascript that runes in the context of the entire book – not just a chapter – with access to the entire book’s structure.

Not many antecedents because it hasn’t really been done before. But I can think of several hypertext structures and tactics that would probably require this. Many of the hypertexts that have been authored with Storyspace, for example, might need this. The most complex ones are usually distributed as applications.

THE SOLUTION

One solution has already been implemented by, at least, a couple of apps:

• In-app browser windows.

Kindle and Kobo for iOS (I haven’t tested the Android versions) both do this when you click on a link in an ebook. An embedded webview window pops up fullscreen over the main content. You aren’t thrown out of the app into Safari. You aren’t asked what you want to do before throwing you out of the app into Safari (iBooks really is one on the most half-baked apps I’ve ever encountered). You just get a fully-fledged, fully-enabled, browser view in an overlay over the book.

The best part is that this is standard practice across the iOS platform – most apps pop up a web page in an overlay – so the readers will know exactly what to do and how it works.

It’s easy to see the use cases:

• You have a thumbnail image of a graph floated to the right in your book. The reader clicks/presses it and the web page pops up with a fully interactive graph they can play with.
• Every chapter in a textbook might offer links to exercises as either lists of links or sets of thumbnails that the student can press and complete online, allowing the textbook author to optionally maintain some sort of state using bog-standard web tech.
• A photo thumbnail links to a slideshow web page.
• A map image links to a Google maps page.

When an OS or browser engine update breaks the web pages, the author just updates them on the server like any other web page. No need to involve the ereader vendor.

Of course, websites don’t live as long as books might, many of them go offline after a few years, but I doubt that would be as big a problem as people expect.

This also is completely useless when the reader is offline, but that’s a small price to pay, IMO.

This solution, obviously, only addresses overlay widgets, but that’s a very big and rich territory for us to mine in authoring ebooks.

Officially supporting this as a way to extend ebooks also gets ereader vendors out of implementing and supporting javascript.

IMPROVING THE SOLUTION

Ereader vendors can improve on this in several ways.

They can offer integrated mirroring for webpages that are supposed to be linked to from their ebooks. That way they can make sure the pages are live (if the official page is down, load it from a mirror) and don’t go offline for the lifetime of their platform.

They can implement prerendering in their ereaders. The ebook author would include this:

<link rel="prerender" href="http://example.org/index.html">

in a tag in the head of the current ebook chapter and the ereader would prefetch and prerender that page, off-screen, so that it displays instantaneously when the reader presses the link or thumbnail.

They might even extend the ePub’s metadata with a scheme that lets authors list prerendering hints; a list of webpages they intend to link to from the book. The ereader could cache the files and when a chapter is loaded that links to one of these files it could prerender the page while the user is reading the main text. They could even use this metadata list to implement backup mirrors for the web pages.

IF YOU CAN’T TELL, I LIKE THIS SOLUTION

I think this is a classic 80/20 compromise. It gets us 80% of what we want from both widgets and javascript with 20% of the effort.

With prerendering and official mirroring we get what we want, both as readers and authors. We get stability. We get rich interactivity. We get javascript.

All with much less hassle for the ereader vendor than full javascript or widget support would entail.

Best of all, we already have a basic implementation of this solution on two major platforms, Kindle iOS and Kobo iOS.

Analyst: Publishers Seeing Steady Print Declines Should Ready for Steep Drop

February 29, 2012 | Jeremy Greenfield Jeremy Greenfield, Editorial Director, Digital Book World, @JDGsaid

Publishers are more optimistic that they won’t see “significant” drops in print revenue in 2012, according to a recent survey. That optimism may be misplaced.

While print publishing revenues showed a steady decline across the industry in 2011, publishers should ready themselves for a steep drop in 2012 or 2013, according to a Forrester analyst.

In a Digital Book World survey conducted by Forrester Research, 5% of publishers believe their print sales will “decrease significantly” in 2012 versus 12% who thought the same about 2011 when asked in 2010. The percentage of publishers who predicted any print declines in 2012 was virtually unchanged versus the previous year.

“There’s an optimism about the pessimism,” said James L. McQuivey, Ph.D., vice president and principal analyst at Forrester, who conducted the survey. “But in reality the decline hasn’t hit yet. And when it does, it comes in big drops, not gradual tapers – that’s what we learned from music and DVD, both of which tapered down until they hit big drops and shelf-space disappeared rapidly. The same will happen in books, probably by late this year and certainly in 2013.”

In late 2011, book publishers representing 74% of U.S. publishing revenues were surveyed on a wide range of topics concerning digital books. The same survey was conducted in 2010.

According to the Association of American Publishers, print revenue in the two largest publishing segments for which it tracks monthly book sales numbers was down 17.5% and 15.6%, respectively.

(E-book revenue overall was up 117%. E-book revenue’s increase of about half-a-billion dollars just about matched decreases in the adult hardcover and adult paperback segments, the two largest at $1.3 billion and $1.2 billion, respectively.)

At several major book publishing companies, including Penguin and Simon & Schuster, increases in digital revenues accounted for declines in print revenues. But, because of higher profit margins on e-book revenues versus print-book revenues, profits were up even though sales were flat.

For some, less-diversified publishers, a precipitous decline in print due to rapid drops in shelf space could be disastrous.

“For those people – illustrated books, cookbooks – if print goes down, they go out,” said Thad McIlroy, a Vancouver-based digital publishing consultant.

On the even more “pessimistic” side of pessimism, fewer publishers believe they will see “significant” gains in print in 2012 than did in last year’s version of the survey: 2% versus 9%.

“There is always a segment that can expect to grow,” said McQuivey. “But these successes will be modest and may not represent an opportunity worth investing in because they won’t last.”