Over 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.
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.