Bookworm survey results
by Liza Daly
I was disappointed to receive only 10 responses to the recent Bookworm poll, but four of those included thoughtful “other” answers and the response I expected to win did not.
The question was:
Which feature would you be most interested in seeing added to Bookworm?
| Edit title, author and other metadata in your ePubs and export that to Stanza or other ePub readers. | 10% |
|---|---|
| Create an ePub from scratch by importing or editing content on the web. | 20% |
| Export ePubs to other formats, such as PDF or the Kindle format. | 0% |
| Support for Adobe DRM (digital rights management). | 10% |
| Integration with other online bookstores, such that buying an ePub elsewhere means that it is automatically added to Bookworm. | 0% |
| Two-way integration with Stanza, such that adding a book to Stanza automatically adds it to Bookworm as well. | 20% |
I really expected the first question about metadata to be the big winner, when 6.5% of the books in Bookworm are named “Unknown” or “Untitled.”
I have no intention of adding DRM support and it’s unlikely that it would get licensed to an open system like Bookworm anyway, but I was curious about the demand. Hopefully the percentage of front-list ebooks with DRM will decline over time.
Here’s a summary of the write-in answers (many paraphrased):
- Provide a lightweight, open-source widget that can render an ebook in a browser, similar to the BookGlutton reader. Authors could use this to distribute long-form works easily.
I think this is a fantastic idea. Before I developed Bookworm I looked around for a JavaScript ZIP library but went the server-side route instead. I suspect such a widget would have to be in Flash or Silverlight, though, unfortunately.
- Import files from other ebook file formats, e.g. PDF, Mobi, etc.
Frankly, I am unimpressed by ebook conversion tools, especially when the input is PDF and not an HTML-derived markup language. It’s a relatively painless procedure when the input file is true XML and a well-designed XSLT (or possibly XQuery) pipeline is used, but none of the existing popular ebook formats are XML.
I think Calibre does the best it can with a difficult technical problem, but I’m more interested in moving to the next level of digital book design rather than producing more poorly-formatted auto-converted books.
- A “click to advance a page” function
I’m not totally sure what’s meant by this but I’m going to assume it’s to change the behavior of the reading engine to advance to the next page just by clicking on the content, rather than on the Next/Previous navigation links.
I feel it’s important for users to have full access to all the normal behaviors of their web browser. Adding support to click in the content area and advance the page would be convenient for reading, but what if you were clicking because you wanted to cut and paste some text, or follow a hyperlink?
I think there’s much that can be improved in the Bookworm reading UI, and I’ll definitely be thinking about ways to make navigation easier. Just not at the expense of other browser features.
- Ability to tag existing content and export references to tagged content.
I’d like to enable all kinds of editing in Bookworm to allow users to make corrections, update metadata, and even make content changes. It’s definitely on my list of big-ticket features for 2009.
Thank you to those who responded. If you have further feature requests, please leave them as comments here or email bookworm@threepress.org.
Comments
I think that relying on Flash or Silverlight would be wrong for such a project. Neither Flash nor Silverlight can render HTML and CSS; but poor rendering of HTML and CSS is one of the main drawbacks of current Epub readers such as FBReader or Stanza.
A reader as an extension for some cross-platform browser seems to be much better solution. There are already two such projects: OpenBerg Reader extension for Firefox and EPub Reader extension for Opera. Unfortunately, the first seems to be dead (no version for Forefox 3 released) and the second immature and not being actively developed.
If someone would revive OpenBerg project or would push Opera’s Ebook Reader project until into maturity – that would be really fantastic!
I agree that Flash and Silverlight are undesirable for many reasons, but they’re portable (like JS) and can read ZIP files (unlike JS).
I’m just as not-fond of browser plugins, though. Inspired by these comments I’ve got something in the pipeline that is pure JavaScript, although it won’t solve every one of these issues and I’m not sure yet when it will be ready for prime time.
Hi Liza,
OpenBerg Reader can read ZIP files. ZIP files can also be read by the new versions of Opera browser (not officially released as yet; should be downloaded from Opera Labs).
Of course, it would be better to have Epub reader not as a browser plugin but as some standalone program. A possible solution here would be release of stripped Firefox browser (renamed, of course) with Epub reader extension preinstalled. Another possible solution would be to develop Epub reader on top of Mozilla’s XULRunner platform. That would solve extension downloading and installation hassles.
Yet another solution would be to develop EPub reader on top of Adobe AIR platform. AIR supports ActionScript 3 which can read ZIP files. Such reader would be not standalone since it would require AIR runtime environment.
Javascript isn’t a kind of self-sufficient platform. Javascript would need some environment to be run and HTML and CSS would need some rendering engine. How would pass together these parts of Epub reader in your solution?
Yet another good idea for developing an EPub reader would be using Titanium platform.
Titanium, although only in preview releases as yet, seems to be more promissing than Adobe’s AIR since it
1) does not demand specific runtime preinstalled,
2) fully open source,
3) supports many languages, e.g Python, Ruby.
Titanium apps can also read ZIP files using modules of third party programming languages be it Ruby, Python or PHP.
That’s what Digital Editions is.
Not correct.
Adobe’s AIR uses Webkit for rendering HTML and CSS. Digital Editions for rendering HTML and CSS uses some browser engine which is neither Webkit nor Gecko, but which supports Adobe’s XML language used for laying out pages. This engine also comes without support for Javascript, so – no prospect for any scripting inside pages.
Though, of course, approach of Digital Editions is quite similar to approach of Adobe’s AIR: both embed HTML and CSS rendering engine into Flash wrapper.
I stand corrected, it is indeed not AIR. It’s patently obvious that DE is not using Webkit, but I don’t know a thing about AIR internals so I didn’t realize that the presence of one implied the other.
Javascript is strongly discouraged in OPS 2.0 (Bookworm disallows it altogether), so I don’t think that’s a great loss. Allowing it at all is just asking for malware.
Personally, I have zero interest in a standalone ePub reader that is disconnected from the net as a whole, so I don’t have a horse in this particular race.