For several months, we’ve been distributing books to Stanza through our Atom endpoints. While the idea of using a standard format (Atom) as a catalog format was a good one, Lexcycle quickly had to extend things through new rel values or additional markup to support things such as thumbnails, search or links to similar books. OPDS (Open Publication Distribution System) is an attempt to standardize these extensions and create a solution that any reading system or content provider could use.
But aside from using more standard rel values and mimetypes, we need to think beyond the current implementation in Stanza if we’d like to create a great browsing and shopping experience.
The AppStore on the iPhone is a good example of what we shouldn’t do: it’s almost impossible to discover new applications and strictly limited to search and a few lists with the most popular applications.
At first, the Atom catalogs in Stanza didn’t have a way to list similar books: as soon as this feature was introduced, the way users browsed through Feedbooks rapidly evolved. People don’t go through pages and pages of books: they use a few books as an entry point to a graph and then explore things, jumping from one book to another untile they’ve found what they’re looking for. Best sellers, customized recommendations or search are ways to find these first books, but what the AppStore currently lacks and OPDS should extend is the way we can sort/filter this content, and jump from one book to another.
The current specs define a generic way to access sub-catalogs while viewing a book, through the <link> tag and the application/opds+atom+xml value for type, which works well for things such as “similar books” but is a bit too vague at this point. Is it a requirement for every OPDS-enabled reading system for example ? While browsing books, how do I filter or reorder things ? Constantly going up and down in the hierarchy of the catalog can be very cumbersome, and the ability to go back to the home catalog (rel=”home”) or to filter content without pressing “back” should be available.
The current specs seem to rely too much on a browser too. A dedicated reading system might lack such a browser and we should make sure that most things can be done without one. How do we support comments and reviews ? How can we integrate the act of buying a book into OPDS and OPDS-enabled reading systems ? The current draft doesn’t answer any of these questions. To display a price, you have to include text or images in the description of your entry. To handle a transaction, most catalog providers redirect the user to their mobile website in a browser. To create an optimal experience, OPDS needs to go beyond listing books, and define standard ways to handle all these interactions required with a retailer.
More technical details about the draft after the jump…
Authentication
Basic HTTP authentication is a good requirement but token-based authentication is much better. OAuth support should be available too.
Search
According to the specs: “It is anticipated that additional OpenSearch feature compatibility may be introduced in future revisions to OPDS.”
I really don’t see the point of using an OpenSearch-like syntax (with characters that are not allowed in an Atom document) instead of a real OpenSearch document. Several extensions for OpenSearch already exist, and it makes more sense to stick with them. For example, to support search suggestions in Stanza, you need to add two <link> tags instead of defining everything in your OpenSearch document. If we keep on extending these possibilities, will we end up with 4 or 5 links instead of linking to a single OpenSearch document ?
Auto-discovery
I really like the idea behind auto-discovery tags (like auto-discovery for RSS feeds or OpenSearch documents), but the implementation in the current specs is weird: “If an HTML link’s href attribute utilizes the opds+http:// URL scheme, the remainder of the URL represents an OPDS catalog endpoint.”
What’s the point of using opds+http:// in the href while we can rely on the mimetype ? What’s the rel value for this link ? rel=”alternate” ?
[...] has put up a post about OPDS and what Feedbooks would like to accomplish in the future. I must admit that I never [...]
[...] Feedbooks : Blog » Blog Archive » Thoughts on OPDS (tags: ebook OPDS stanza atom) [...]
Thanks for the level-headed writeup. I think this informal specification got way too much press on what was a single contributor’s first draft. I’d be surprised if most of what you call for above didn’t get included by the time others have contributed.
Atom has a fairly wonderful extension mechanism, so I believe it would be most pragmatic to reuse & refine that, OpenSearch, OAuth and other specs rather than invent new things, especially if a goal of the project is to make catalogs east for novices to *produce*.
Sure, I should have pointed out that in its current form, OPDS is just a first draft.
But aside from purely technical points, we need to get a better idea of what we want to build with OPDS too (just a way to list things and then redirect the user to a mobile website or something capable of handling all the interactions of a retailer ?), and that’s what I tried to explain too.
Re-using and refining rather than reinventing also has the notable advantage of being likely to produce a final product that is more suitable for consumption by “unexpected” clients. Not only does that draft of the OPDS spec make changes to atom that require special handling, it makes assumptions and demands about the way the client’s UI will work. This prevents both eBook readers with novel UIs and completely unexpected types of clients from “complying” with the spec. Atom and OpenSearch don’t attempt to define how programs that consume them should present a UI, and I don’t feel it’s reasonable for OPDS to do so either.
[...] les commentaires d’Hadrien Gardeur (Feedbooks) Partager : [...]
You raise an interesting point Nick and I agree that UI and data should be independent from one another.
But in some situations, you might need some extra information for the UI to handle things. For example, with the current implementation, one of the problem is that things look pretty “flat” to me: there’s no way to group multiple entries together, which could be a very useful visual hint.
While we shouldn’t force any reading system to use specific UI elements, we need to make sure that we provide enough information for those novel UIs.