Prairielight — next-gen platforms for e-readersOver the last two years, I’ve thought a lot about what I want in an e-reader.

As someone who’s made my living as a freelance writer and written a couple books, I’ve thought about copyright and the rights of a creator. These concerns are pretty low in my current thinking.

As a technologist, I’ve thought about including motion, sound, color and interactivity to take advantage of the content being delivered by a computer. Following the development of Sophie, I’ve come to accept the need for creators to make rich-media texts, no longer thinking of this as an after-creation/publisher activity.

As a reader, I’ve thought about getting ahold of what I want to read and removing the barriers to what Bill Hill calls ludic reading. What kind of device do I want to hold in my hand and what do I want to see on it? In this time, I’ve mostly been using FBReader on the Nokia 770, N800 and N810 internet tablets, and I am consequently dependent upon a flexible and color-capable device, unlike the majority of what the market seems to be offering up right now.

As someone who has worked in book publishing for the last fifteen years, I’ve thought about how to forego copyright as a mechanism for economic protection and still provide incentives for publishers and writers (and jobs for editors). A viable business model — gosh, it sounds more and more like the search for the holy grail.

I’m no true prognosticator, but I think we can see the outline of the next generation of e-readers now.

Bowing to Sophie’s makers, I believe the new e-books will contain far richer media than at present. And by this I don’t mean “including video and audio” but just what Sophie‘s makers do: including anything an author might devise when provided with full programming capability.

Like FBReader and Openberg Lector, the next-gen e-reader will accept a whole slew of formats. And as the OpenReader and OEBF formats champion, the most useful formats will deliver a single file that itself contains one or more maps to multiple files inside it. And we’ll be able to escape the “html with a slight makeover” straitjacket we’ve lived with since day one of e-reading.

And as FBReader and Lector insist, the next-gen e-reader will be multi-platform.

All of which lead me to expect that the triumvirate of AJAXed development platforms — Mozilla’s Prism, Adobe’s AIR and Microsoft’s Silverlight (I call them “Prairielight”) — will provide us with many new e-readers.

For one thing, with any of these platforms, a small team will be able to create a formidable, flexible, cross-platform e-reader. Heck, I’m no programmer and I have conjured up a respectable application based on XUL and Javascript. They build on the internet technologies already widespread — I mean the browsers’ rendering engines and Flash, HTML, Javascript, XML and CSS — and will benefit directly by new innovations the web brings.

I guess I’m counting on people expecting their e-reader to have the same capabilities as their web browser. In that case, why not just build on top of the browser/rendering engine?

Besides, prairielight apps should make it easy to allow authors to program their own interactive aspects.

For that matter, we might see halfway-authoring tools that basically allow authors to build one-off e-readers, designed solely for their e-books and requiring a prairielight installation to read and not some specific next-gen e-reader.

So some textbooks could build in interactive questioning that would send the results to a local network server in the school. And language textbooks would build in timed review, evaluating your responses and flashing recent vocabulary you’ve had problems with more often than older, easier terms.

That’s already something you can do with AJAX and prairielight now and wouldn’t require programmers to learn new skills to make their e-books really electronic.

5 COMMENTS

  1. Would authors be able to afford the toolsuite to create these kinds of ebooks? I’m not a cheapskate, but I’ve never been able to afford Macromedia’s creation suite of tools. I fear that these rich media platforms (interesting though they are) simply impose additional costs on self-publishers. Or is the author simply to use xml-rpc to upload content to a server (presumably owned by a media company)? Basically the future you envision looks expensive for individuals and profitable for major media companies. (I suppose it could be argued that typewriters were luxury items a century ago).

  2. The point for authors shouldn’t be “here’s another expense” but “here’s more you can do/create while retaining control over your creation.”

    Because to my thinking, AJAX provides a low-investment high-impact path that doesn’t require expensive tools to write. The ‘prairielight’ frameworks are intended to give online AJAX-y capabilities to offline, desktop apps.

    Adobe certainly has a history of charging for its creation tools, so AIR might follow the Acrobat or Flash model (pay for creation tools, get reading/viewing apps for free). I don’t know where Silverlight is expected to land.

    But Prism and Sophie won’t carry any charges. (Sophie of course isn’t AJAX but is an easily mastered rich-media authoring tool.)

    There are lots of editors for working with HTML and Javascript and CSS, some free or low-cost, some not.

    As for imposing costs on self-publishers — professional tools for publishing have always cost money, whether it’s QuarkXPress and Photoshop in a current generation or “typesetting services and a designer” 25 years ago.

    (Or maybe you use Scribus and Gimp for a no-cost approach. They’re certainly good enough. As an old-time equivalent. I guess that would be using one of those 1970’s IBM proportional typewriters for your typesetting.)

    So this is just my long-winded way of saying I don’t expect it to be a problem, or any more of a problem than it has always been.

    Roger

  3. There is a tangential argument about the point at which adding non p-book features — animation, interactivity, audio, video and such — moves the creation out of the “book” world.

    Wherever that point is, I’m talking about something that is more like a book than it is like a CD-ROM or a game or a movie.

    As you move farther into those other creation forms, it’s quite possible the tools will be ever more expensive. Just as making films or plays has always cost more than painting and sculpture and those more than writing.

    Roger

  4. This is an interesting topic–thanks for contributing it, Roger.

    I’ve spent some time playing with video, making machina movies, and doing a little programming. While I do share Robert’s concern that the cost of tools will move book creation out of the realm of the individual author (just as expensive tools and graphic requirements have moved computer gaming out of the realm of the individual programmer), I have a couple of additional concerns. First, I’ve never been blown away by any of the attempts to create program-intense reading experiences. From the early days of comic books on floppies to manga-versions of SF classics, to choose your own adventure style stories, all the cleverness seems to create a barrier between me and the story.

    I’m not a luddite and I’m certainly willing to be proven wrong. Because I love the novel form, I like to think it will survive into the future rather than be replaced by something that involves large and expensive teams of developers (as happened with video games).

    On the other hand, I once firmly believed that since eBooks don’t have covers, they shouldn’t need cover art. It turns out that at least some multimedia does help with books–at least in terms of encouraging sales.

    Rob Preece
    Publisher, http://www.BooksForABuck.com

  5. Sophie is some slick software. But embedding external links? When I did my blog, links died before I knew it. Readers will scream bloody murder when they buy an ebook and find not all the links work. And what can a publisher (or writer-publisher) do then? This is a whole other can of worms.

The TeleRead community values your civil and thoughtful comments. We use a cache, so expect a delay. Problems? E-mail newteleread@gmail.com.