The PDFs we ultimately produced don't follow the vision outlined below, but I think the ideas are still interesting, so, for the record, here they are.
As a reader, I want access to my ebook at all times. This means an internet-only approach (such as Safari or Amazon Upgrade) is unacceptable. I want access to the latest version of the ebook, including all changes made since I bought the book. I want access to a complete changelog of everything that has been modified in the book since it was published, ideally along with a rationale for each change. (This should sound like an errata list, which many authors already maintain.) I want to be able to make bookmarks and add comments to the book. I want to be able to see comments others have made about the book, and I want to be able to see others' comments on my comments. I want to be able to comment on their comments. (If this sounds like reader comments on blog entries or like newsgroup discussions, that's not an accident.) I want to be able to view ebook content in a way that suits me on a device that suits me, which means I want control over text and image size, etc., and I want line breaks to be determined dynamically. I want to be able to print chunks of the ebook. I want to be able to perform full-text searches with at least the power of Google. I want all cross-references to be links or similar (e.g., words in the glossary might have their definition pop up if I hold the mouse over them). I want to be able to use the ebook as effortlessly as a real book or web page (unlike my current CD, which has a LONG introduction explaining how the darn thing works). I want to be able to buy access to the ebook for a modest additional fee if I've already shelled out for the hardcopy book. I want to be able to easily take an example or code fragment and get access to it in such a way that I can play around with it, e.g., copy a fully compilable version into my development environment.
That's not all I want as a reader, but it's enough to get us started.
The current CD has two books and some magazine articles. In terms of content, one of the things the CD offers that the paper books do not is links among the books and the articles. That's because the paper books are standalone, but on the CD, I know that readers have both books and a bunch of articles, so it's safe to add references among them. Adding such references is not a lot of work for me, and I think it makes the CD more attractive.
Eclipse is a framework that does nothing but allow functional components to be plugged in. By itself, it does nothing, but it facilitates the cooperation of other independently-developed components. I think the same architecture is a good way to approach ebook publication. Create a framework into which ebooks can be plugged in. Use a web browser as the UI, because everybody already has one and knows how to use it. Also make it possible for comments to be plugged into the framework, i.e., a way to specify "put this comment at this location in this book." A "comment" is a general notion, one that can be simple text, but can also contain a link ("link to this URL or this location in this other book (or the same book) using this text") and could even invoke a program ("run this flash animation explaining how this code works when this text is clicked on"). The framework takes the ebooks and the comments and produces the HTML that the user views, typically omitting comments that refer to books they don't own. So if the user owns EC++/3E (Effective C++, 3rd Edition) and MEC++ (More Effective C++) but not ESTL (Effective STL), they see electronic versions of those two books, any comments within or between those two books, comments from those books to the internet in general, but no comments leading to or from ESTL. If they then buy ESTL, shazaam!, comments involving ESTL suddenly appear in their UI. (They were probably always there -- they shipped with the books they owned -- but they were not shown, at least not by default.)
As an author, the only additional work I have to do to prepare a book for such a framework is to create a file of comments, and if I don't want to do that for some reason, that's okay, the book will still show up in the framework. But if somebody else wants to create comments to or from my book, users can install those comments, and shazaam!, they'll see them. The framework will probably have to offer a way to filter comments, e.g., "I only want to see comments approved by AW" or "I don't want to see any comments by that Meyers guy".
One of the nice things about this approach is that any document can be plugged in, so the framework can support free books, online articles, etc., and they can coexist with ebooks that have been sold.
Another nice thing about this framework is the more content it has, the more useful it is (like a Wiki), so readers are implicitly encouraged to buy more books to fill out the framework. This can be especially the case if links to uninstalled content are shown (which should be optionally possible), because then readers will be constantly reminded of all the good stuff they'd have access to if they'd just plunk down a bit more cash.
The ebook content would normally be stored at an online server (as with Safari and Amazon Upgrade), but local copies could also be cached, so if internet access was unavailable, the cached copies would be used. This solves the "access anywhere" problem and reinforces that when readers buy an ebook, they own an actual copy, not just access to a copy stored elsewhere. In fact, you can separate payment for the two: for, say, $n you can buy an ebook (assuming you've already purchased the paper version), and for an additional $m/year or $n for your lifetime you can have online access to the very latest version, comments from the author, etc.
No comments:
Post a Comment