Home : Why Ebooks Belong in the Web Browser

naked king with bookWith the arrival of the Internet, the common man got the power to publish—anything—for free—for the first time in history. Then PDF brought replicas of printed documents to the screen with clarity, accuracy and security. Flash brought the power of animated vector graphics and a powerful programming tool to the web browser. Then the eBook brought reflowable, resizable text and inspired new reading devices—perfect for displaying long, paginated documents. But somewhere along the way, an important promise was broken. All of these technologies empowered the Internet’s unprecedented freedom to publish—except for the eBook.

Ebooks and the Promise of the Internet

EBooks violate the fundamental promise of the Internet. Anyone can publish a website. Anyone can offer content for free or sell whatever they want from a  website. Small commissions to payment processors and web hosting costs notwithstanding, the Internet empowers a seller to engage directly with a buyer. Ebooks break this promise; the writer should be able to engage directly with the reader. The writer should be able to sell directly to the reader. Imagine if you had to pay your web hosting company 30% of your gross every time you sold an item on your website—that’s exactly what eBookstores do. By separating the eBook from its proper home—the web browser—big media companies grow fat. This article explores the relationships between the web browser, PDF, Flash and eBooks—and how those relationships affect you.

A Book by Any Other Name Would Smell as Sweet

The business premise of the eBook perpetuates the illusion that an eBook is a book—and not a piece of software. It may walk like a book and it may quack like a book, but it’s a digital file made from zeroes and ones; eBooks are software—software that can and should be sold or licensed like any other piece of software. The fact that paper books have traditionally been sold in bookstores does not mean that an “online bookstore” is the only legitimate place to sell eBooks. In fact, an online bookstore is no different than any other e-commerce company that displays and sells the products in its database. Downloading and installing book software should be no different than downloading and installing any other software. To be accurate, publishers can produce and distribute their own ePub eBook files but these still rely on dedicated eReader software or hardware. But you’re reading this article in a web browser. Why should reading a book require a special device, application, or intermediary service?

Ebooks and the Software Land Grab

Apple’s iPhone OS became hugely popular—popular enough to rock the web when Flash was officially excluded from that platform. Flash was important because it was the first technology to bring full software functionality to the web browser. Annoying animated banner ads only scratch the surface of what’s possible with Flash. Adobe’s technology allows developers to deliver any experience short of scratch-and-sniff directly to the web browser. Critics of the “no flash” policy claim that by blocking Flash, Apple ensures that “rich” web experiences and sophisticated functionality can only be acquired by purchasing them in a proprietary app store. They argue that Apple wants to prevent developers from creating an in-browser equivalent of their iTunes software—or an engaging web-based eReader that could be superior to their own iBooks application. Apps are powerful and alluring—but their glitter obscures the fact that their glow was once viewable on the free Internet via Flash.

So the web browser became a second-rate viewing platform. Rich media content became available only to those willing to buy proprietary hardware and shop in proprietary app stores.

As mobile computing exploded in popularity, the eBook industry developed its own eReader devices and (in the case of Amazon) eBook formats. With Flash out of the picture and the web browser not up to the task, the business opportunity was clear. The irony is that file formats like Amazon’s .mobi and KF8 formats, and the ePub eBook standard are simple wrappers for bundles of HTML files (the same files your browser reads to display web content) with a few additions to manage the table of contents and book metadata. EBooks are actually simplified websites—and an ePub file is a simple zip archive.

The Rise of Ebooks

EBooks had two requirements that neither PDF nor HTML could meet—reflowable, resizable text, and portability. PDF was perfect for fixed layouts (a capability which is ironically bragged about as one of the great new features of ePub3) but PDF does not support reflowable text. Nobody wants to read long, scrolling pages in the web browser, and though Flash has powerful text parsing and formatting capabilities that would have made it a great candidate for eReader development, it was knocked out of the running. Amazon, Barnes & Noble, Apple, and other media companies naturally saw a window of opportunity to sell eBooks through proprietary bookstores—and readers lined up to buy their viewing devices. It’s true that eBooks can be viewed on desktop computers, but readers of eBooks also demand portability. This second requirement makes tablets, phones, and eReaders ideal platforms for consuming books—and this is precisely where the exclusion of Flash and the limitations of the web browser made eBooks a popular, separate medium.

The Web Browser Comes of Age

The alternative to Flash suggested by Apple for rich media web development is HTML5, a collection of developing standards that includes CSS3, jQuery, HTML, Javascript and other technologies. (If this is all technobabble to you, don’t worry; you can leave the coding to the web developers.) By setting the capabilities of the web browser back five years, Apple may have created a lucrative business opportunity—but in doing so, they catalyzed a huge effort on the part of Adobe and the Open Source development community to enhance web standards.

Though HTML5 still can’t do a tenth of what Flash can do, the humble web browser has made tremendous strides. Adobe introduced new tools that export rich media content to HTML5. Services like Google Swiffy convert Flash Files to HTML5. HTML5 will likely never be as fast as Flash (Flash files are precompiled into low-level code whereas the various high-level scripting and markup languages used in HTML5 must be downloaded and compiled by the web browser) but the capabilities of the web browser have grown by leaps and bounds. Animation, enhanced image rendering, SVG vector graphics and a host of other visual improvements complement new CSS3 text handling capabilities that include support for multiple columns and automatic hyphenation. Though HTML5 is not ready to replace Flash, it is ready to offer a better reading experience and to empower writers and publishers to produce and distribute their work without middlemen and without the limitations and inconsistencies of today’s ePub-based eBooks. The capability to render paginated, reflowable, resizable text in a desktop or mobile web browser is available today. HTML5 flipbook engines like Turn.js and browser-based eBook rendering platforms like Monocle and TreeSaver are only the beginning of the restoration of the promise of the Internet as it pertains to eBooks. It’s time for the eBook to return home.

A book by Booki.sh based on the Monocle.js eBook Framework

Traditional EBook Development has Stalled

Meanwhile, eReader devices have lagged behind. Traditional book typographers cringe when they see their work rendered on an eReader device; a book is so much more than a container for text data. For all the promises offered by the new ePub3 standard, the only one kept with any consistency is fixed layout—the cornerstone of the PDF format long before eBooks ever hit the scene. And this is not a fault of the ePub3 standard; the lag is caused by unwillingness or inability on the part of eReader manufacturers to support the standard. Some devices allow web fonts; others strip them out. None of them do anything sophisticated with typography; only Apple iBooks even approaches offering an aesthetically pleasing reading experience. Also missing or inconsistently supported are rich media additions like video, audio, photo galleries, embedded content (like Google maps), and interactive components (either Flash or HTML5). Of course, if you want “enhanced” iBooks, you can use Apple’s iBooks Author software to export to Apple’s proprietary iBooks format (so much for the insistence on standards-based technologies that Apple used to justify the exclusion of Flash).

The ePub3 format promises to deliver a “website in a book” experience, but booksellers and eReader device makers have stalled. With millions of eReaders sold, sellers may be hesitant to offer new products that make their old ones obsolete. Also, the publishing industry is hugely invested in converting millions of titles to ePub2. The creation of an aesthetically pleasing ePub3 eBook requires much more conscious design effort; the costs to convert a large publisher’s book catalog to ePub3 (or a pure web format) could be staggering—and the anticipated returns might not add up on a spreadsheet—especially while eBooks are selling in their current form.

EBooks: The “Book in a Website” Concept

Browser technology—including mobile browser technology—has advanced; it now makes more sense to reverse the “website in a book” philosophy of ePub3 to focus on making a “book in a website.” The original requirements of portability and reflowable text are no longer obstacles for browser-based content. Tablets and phones and even eReaders are equipped with web browsers and wireless Internet capability. And tablets have already overtaken dedicated eReaders as the most popular devices for reading books. Let the fun begin. A book made available as a website has numerous advantages over traditional eBooks:

  • Aesthetics: web typography is unconstrained in comparison with eReader typography. Web fonts, hyphenation, properly executed drop-caps (rather than the automatically generated kind that sits in a rectangular box inserted into the text), fancy paragraph formatting, and other typographic features are only limited by what CSS and javascript can do. While big publishers are banking on their investment in ePub2’s limited display capabilities, your book can look much better.
  • Searchabilty: a web book can expose every page in a book for indexing by search engines. That beats a bookstore title/author search by a light year.
  • Rich Media: videos, photo galleries and other elements can be integrated directly into book pages or evoked by links in the text that reveal them on-demand without cluttering the reading experience. Though Flash content will not be viewable on Apple iOS devices, the publisher can choose any media formats that suit the viewing capabilities of their book’s audience. Aesthetic freedom and technological power translate into unbridled creativity for writers and publishers.
  • Updatability: If you find an error in your book or wish to add a photograph, make your changes as you would on any other website. All your readers will be instantly updated. Also, as technology grows, you can enhance your book to leverage new capabilities.
  • Offline Reading: A web book is a simple collection of HTML files. Offer a zipped archive for users to download and read locally. Web-based components (YouTube videos, for example) will not load when a user is offline, but the text and page formatting can be viewed and enjoyed regardless.
  • Co-hosted Media: Traditional eBooks are closed packages that are (and should be) limited in size. By adding in media co-hosted on services like YouTube, Picasa, Flickr, Google Maps, etc., an eBook can reference gigabytes of added content without bloating the book’s file size. (ePub3 does support web-based content but this capability is inconsistently supported by eReader devices).
  • Integration into a traditional website: Once your book is online, why not add an “about the author” page, a blog, a discussion forum, a mailing list, or any other content that helps promote, explain, or build community around your work? A “book reviews” page seems like a natural choice. An eBook can be a site unto itself or a section of a larger presentation.
  • Bookmarking: The web browser already has a wonderful bookmarking feature. Book chapters are web pages; bookmark as often as you wish.
  • Commerce: Sell your work by offering file downloads, putting the book (or most of it) behind a pay wall, or by allowing readers to read freely and pay if they like it (as they would in a physical bookstore). Pay small commissions only to your payment processor and keep the rest as profit.

ePub3 eBooks are a fundamentally good idea as, in keeping with the premise of this article, they attempt to offer all the capabilities offered by the web browser, but the Promise of the Internet is not going to be restored by media conglomerates who have a vested interest in proprietary formats and viewing devices. EBooks and publishers will only benefit from using the free Internet as an alternative distribution channel. Small, quality-minded publishers will lead the charge by producing excellent eBooks that leverage all the remarkable features of the web. Your eBook can benefit from simple typographic enhancements that create a more comfortable reading experience, or perhaps it will expand the boundaries of what defines a book? Given the technological limitations of adapting a manuscript to traditional eBook formats, publishers who care about excellence and innovation will soon find only one viable delivery channel—the web.


Comments

Why Ebooks Belong in the Web Browser — 26 Comments

  1. I just published my first eBook on Amazon and even include a chapter on innovation where I suggest that eBooks should support some means of public annotations (and ideally, a methodology to “negotiate” annotations) so that the end work product can grow over time. This allows community support and often can lead to an even better work product than originally authored. Now I realize that Wikis and Blogs have been around for ever (and I do in fact have a wordpress blog). And yes, Facebook and Twitter could also be used, but I like the notion of an eBook being the “consolidator” (where the author “owns” the scope of expression on the given title – after all, the author owns the original book). So I like the notion of supporting full web browser mechanisms but would like it to join a methodology which allows some level of control by the author. And I certainly would want this to be browser independent. Now I am certainly curious why the underlying content is html and CSS, yet the eReaders have such a limited and dissatisfying user experience). And as you point out, companies trying to preserve their “empires” is the answer. If I had a vote, I would say that all eReaders should support full browser features where the user could toggle settings and either have a limited eReader view (i.e., simple page up/page down), or have the full web at their finger tips.

    So I definitely like the discussion. BTW, I stumbled upon this page because I was trying to figure out why Chrome Readium plugin wasn’t working when trying to display my mobi file.

    • You’re correct that e-ink is easier on the eyes but those devices are being surpassed in popularity by color displays. More people now read books on tablets than eReaders.

  2. “EPUBs Belong in HTML5” would be a better title. Who cares whether they are consumed in a browser or not? I agree HTML5 is the universal platform, but whether content is delivered as websites vs. as mobile apps (built on frameworks like PhoneGap) vs. as eBooks (built on EPUB) is to me a detail not something fundamental that we should be arguing about. And so far very few people have successfully monetized premium content delivered as websites: adverts don’t work unless you have huge traffic and consumers resist paywalls. Whereas billions of dollars were made last year distributing HTML content as eBooks and on mobile apps, many built on Web technogies One reason eBooks via the browser hasn’t taken off is that consumers who pay $10 for an eBook want to get the file and have offline access. I’m pro-browser but it’s a fact that consumer time spent in browsers has been decreasing in recent years, while time spent in native apps (inc. eBook readers) has been increasing.

    Authors & publishers can start distributing HTML5-based EPUB 3 eBooks now to channels that already support EPUB 3 (Apple iBooks, Kobo, Google Play Books, VitalSource, etc.), content that also works on existing EPUB 2 reading systems. O’Reilly has “flipped the switch” to EPUB 3 using this technique.

    Finally, the Readium.org open source effort will accelerate getting EPUB 3 to everyone, for cloud readers (Readium Web) and for native apps (Readium SDK), without any dependencies on a single vendor. Many of the key players in the industry are collaborating in this effort which could have similar impact to Apache for web servers and Mozilla & WebKit for web browsers.

    • Bill, I’m honored to have you weigh in on this. I have no problem with ePub3 or eReaders; they’re here to stay. However, the business politics underlying vendor decisions to support or not support certain features remind me of the “this site optimized for Netscape/Explorer” browser wars of the 1990s. ePub may be an open standard but eReaders are proprietary devices controlled by proprietary interests.

      Web-based content can be downloaded as a web archive and viewed offline. Moreover, if ePub3 books are not to become bloated with media files, added content will likely have to be stored on services like Flickr, YouTube, Vimeo, Picasa, Google Maps, etc. and made available to online viewers only. Rich media is simply too large to bundle effectively with “core” content whether that’s an ePub3 file or a zipped archive full of HTML5 files. In this regard, the advantage/disadvantage of web vs. ePub is a wash. They face the same challenges and are basically the same thing.

      You will find nothing but support on my part for the goals of ePub3, but when it came time to start working on a very innovative eBook design, I found too many incompatibilities—not so much with the ePub3 format—but with the devices that claim to support it. I’m not ready to release my eBook yet, but when I do, I hope it can serve as a wakeup call for those whose financial interests are standing in the way of progress. eReaders won’t support those experiments yet but the browser will, and though that’s disappointing, my disappointment is with eReader manufacturers who think that the current state of eBook typography and rich media display is “good enough.”

      While “key industry players” collaborate toward developing tools like Readium, the web browser is ready, today, to display eBooks that are constrained only by the developer’s imagination and technical abilities. Ultimately, we’re both talking about deploying a package of HTML5 files. As you say, “who cares whether they’re consumed in a browser or not?” I don’t care where they’re consumed but I care that they can be consumed. Right now, for my purposes, eReaders are too limited and therefore, an ePub3 file will produce inconsistent results that reflect negatively on me, the publisher. Readers won’t conclude that their device doesn’t support feature X; they’ll conclude that my eBook is junk—and that’s not acceptable. Web browsers aren’t perfect either—they’re fraught with their own inconsistencies and incompatibilities—but they’re ubiquitous and not controlled by corporate interests.

      Bill, please don’t interpret my preference for the browser as a disparagement of your important and visionary work with IDPF and ePub3. As soon as eReaders support my content, you’ll see an ePub3 version of my book. Thanks again for your comments here.

  3. I found this interesting. I have one novel published by a small press in the USA, essentially a one-woman band. She has not provided a royalty statement after two years. I live in New Zealand, left wondering how to extricate myself and my book. I got into this deal about the time Amazon began their self-pub service, so I missed that boat. But maybe that was no bad thing. I know my book hasn’t earned much, so the money owed to me is not a big issue. My book is essentially ‘buried’ deep in the Kindle and Nook stores. Getting people to buy it from those sites at $6.99 is just not easy.

  4. Great article Dave! Thank you. I would just say that html5 and css3 at least aren’t “owned” by a corporation, such as Adobe or Apple. Hopefully more vendors of ebooks will be pushed in the direction of complying with an industry standard, when there is one. The tools and means to create content-rich ebooks will develop and become easier to use as well. I remember the browser wars, growing pains of the WWW in the 1990s and the push for standards to be followed, which is evolving pretty well, if not perfect. Flash was destined to fall by the wayside in favor of open source non-proprietary approaches to disseminating information. I am glad to see it go.

    • The important word being “compliance.” I’m tired of corporations stalling progress and limiting creativity. The web is the only unregulated and open platform. For what it’s worth, my flash flipbook page still accounts for a good chunk of my web traffic. People are still using flash and they want to put their books on the web. Thanks for your comments.

      P.S. The .swf file format was made open a long time ago. Flash has its disadvantages but it will be a long time before anything else shows up that can match its capabilities. Five years from now, we’ll see a precompiled file format developed that gets executed by the browser natively in the same way that the flash plugin executes flash files now. Flash will get reinvented and the new format will be billed as “innovative.”

  5. I neglected to mention that, if your goal with that image was to seriously disturb your readers, score at least one point. It’s like something my little brother would have thunk up on his worst day.

  6. Very interesting and persuasive, Dave, and way over my head technologically. I’m a pilgrim with a dumbphone, for cryin’ out loud. And I’ve got a book I’m on the threshhold of epublishing in the here and now — and leaning to Smashwords.

    Am I correct in assuming you’re “blue-skying it” with this manifesto, and that for the short-term I’m just gonna have to work with what’s available in the here and now?

    • For the short term yes, more or less. http://www.booki.sh has pretty nice looking HTML5 books up and running, and http://www.turnjs.com offers a workingHTML5 flipbook. I don’t think that web-based books are going to knock Amazon/Kindle off the map, but they’re a viable alternative channel that we’ll see more of. As publishers create content that eReaders simply can’t display, the web browser will become more a more compelling choice. The technology is here today but we haven’t seen much content yet that justifies the alternative format. Innovation in book design and capability will be the best catalyst for getting web books noticed.

  7. I’m reminded of Alton Brown’s rule for his kitchen tools: no mono-taskers.

    A tool that only does one thing is either for specialists, or it’s a waste. (That, from my father the auto mechanic when I was a kid.)

    An ereader does one thing. A computer does anything. A web browser comes pretty close to “anything” as well. Books in browsers just makes sense.

    I haven’t kept my web skills current, now that I’m specializing in WordPress. I wonder how we offer our readers the ability to highlight, add annotations, etc. ? Any ideas?

    • I’ve been doing lots of WordPress work now that my Flash skills are no longer in demand, but I use the Weaver theme quite a bit and spend time hacking custom CSS to produce some of the design characteristics. HTML5 is a poor substitute for Flash but that’s reality; I’m polishing up my coding skills and moving forward.

      Highlighting, annotations, etc. should all be possible but getting a good HTML5 eReader working is the first step. From there, the possibilities are endless. Why not add social features that allow readers to view/exchange notes and criticism? Virtual book clubs could share comments within their specific groups. To your point, the one-function tool is limiting. Freedom will be found in the open web with enhancements driven by developers who are trying to fill in the gaps left by the exclusion of Flash.

      • There’s really no technical reason we can’t bring every aspect of the web to online books, as you suggest.

        In fact, even media we usually consider online-only, like video, can be made available offline with the right synchronization tools. Requires the bandwidth when the use *is* connected, but tools to download a browse entire websites offline have been around for a decade or more.

        The trick for the coder is not to be able to create the be-all-end-all today, it’s to make a good guess about which skills will be on the path to that b-a-e-a result. Ten years ago, the scramble was to find ways to compress video so it could be streamed over a 56K modem.

        The folks who simply plowed ahead creating the best quality video won, because broadband became ubiquitous.

        HTML5 may be behind the curve today, but I think we can assume that in 5 or 10 years, we’ll have the tools to do whatever we want.

        • You’re right, Joel, but I like to look at this as a musician. Let’s say we’re going to improvise—to compose spontaneously—over blues changes. An argument can be put forth that the chords are limiting; they prevent us from exploring certain keys and scales. But those restrictions give rise to creativity as well. We have a century of masterful music to consider that engages and leverages that musical schema. And we have new instruments and sound processors that can contribute new voices to that old conversation. I do agree about trying to guess where the ball will bounce. I bet on Flash back in 1999 and it carried me a long way. I bet on WordPress and it’s grown and become an income stream. Now we’ve entered a sort of “dark ages” where some of the major trains of innovation got derailed and we have to backtrack and figure out what’s coming next with new technologies that are more difficult and complex than some of the old ones. I’m watching carefully to see what media and tools are going to turn into, but I’m also trying to innovate within the limitations of the “changes.” The goal is still to communicate a certain message by changing the colors of a matrix of pixels on a screen. I can still do that today, albeit with clumsier technologies, but I’m not waiting 10–15 years for Adobe to sell me new design tools. At least a few hours of every day go toward innovating with HTML and javascript and CSS. It’s slow work and it’s expensive as I’ve had to hire some tech help to do things I used to do myself with ActionScript, but every frontier is both a wasteland and an opportunity. I listen to Flash developers gripe on the forums every day about how Apple and Adobe fumbled Flash. I don’t disagree with them but my motivations are fundamentally creative; if I’m not making something inspirational happen on the screen, I’m not happy. I figure it’s a matter of either adapting or dying off, and as I approach 50, I’m going to adapt as much as I can while I still can.

          Check out some of the technologies linked to in the article. EBooks in the browser are possible right now, today. What’s needed is for readers to wake up and question why it should be any other way.

          Thanks as always for your comments here, Joel.

          • D’oh. Forgot the links. Monocle looks smashing, though I don’t see info on highlighting or annotations.

            Markup (http://markup.io/) has potential as well.

            Better to be moving forward on SOME path than to be sitting and waiting. I need to accept that I’m a writer these days, not a web guy, and leave the innovation to those who are more focused on it.

            And then use their stuff.

Leave a Reply