The story is revealed online with new content each day, and will later be published as a standalone ebook and print book.

For the online reader, they’re using a customized version of Monocle, which looks lovely:

Web-based publishing was a must for Enthrill due to the real-time nature of the book. Unlike with a custom iPhone/iPad app, they get cross-platform support for free. And by using a web-friendly ereader like Monocle, they’ll be able to repurpose the content into a later EPUB version.

Best of luck!

With the work on those challenges just starting, I was pleased to see that Joseph Pearson, the creator of the Monocle EPUB reader, had taken the time to start writing his thoughts about the challenges of solving the interactivity Problem. Joseph raises three concerns surrounding the work on interactivity: a need for scripting security, the lack of a defined interaction model, and the danger of document modification by reading systems. While I think that he raises two real problems that will need pragmatic solutions (the first two), we can acknowledge either problem and still get started on defining & supporting more interactive content in EPUB.

In particular, it’s seems unnecessarily pessimistic to point to the current limitations of JavaScript’s security model as an insurmountable issue. Reading systems like iBooks, which hosts its own customized setup of the WebKit rendering engine, already enable a secure, sandboxed JavaScript execution environment. If the IDPF and the Working Group comes up with concrete use cases and requirements around scripting and security, those concrete needs may be the motivation that browser-makers require to get started on aligning broader emerging web standards with the needs of ereaders, especially browser-based readers like Ibis Reader and Monocle. Existing work like Eli Grey’s JSandbox is promising in this regard.

As for the issue of defining the interface & events that an interactive EPUB can hook into: yes, we’ll need that. It’s clear that a basic interaction model should be included in the new specification, but that doesn’t seem like an unrealistic goal at this time.

I don’t understand Joseph’s concern with document modification (as a major problem). EPUB Reading Systems that enable interactivity will need to be careful about keeping the EPUB internals consistent-enough to be usable. It will also be challenging to ensure that content is structured and provided inside interactive content to ensure accessibility for all readers. With luck, work from the WAI-ARIA folks will help guide us.

I’d like to explicitly encourage Joseph and anyone interested in contributing to the future of EPUB (and digital reading in general) to join the IDPF and contribute to the Working Group. In particular, I’d love to hear more voices from people creating digital content, especially outside of North America.

Explicitly: This is purely my own opinion. Liza has her own more informed and interesting thoughts on the topic and she’ll be actively participating in the Interactivity Subgroup and the Working Group in general.

We’re making the geo demo featured in the Interactivity in EPUB talk available for download under the MIT License.

About the demo

In the demo, the geolocation capability of the web browser transmits your latitude/longitude. The code then queries the Geonames database to get an English placename.

After that, the code will continually poll for your current location. If you remain still, text will be displayed to indicate that the main character is bored and waiting to set off on her adventure. When your lat/long changes, it displays new text.

What’s in the demo

This is a ZIP file bundle of the following resources:

• The geo code itself, in JavaScript, CSS and XHTML
• A copy of the Monocle ereader by Inventive Labs
• A copy of geo-location-javascript, which provides a simplified API to the HTML5 geolocation feature
• The embedded font IM Fell English Pro, converted to SVG format for use on iPads/iPhones.

The book content is in the form expected by Monocle, not EPUB, though if someone wanted to produce an EPUB version I would be happy to link to it. It should be possible to produce a valid EPUB file though very few ereaders would be able to run it.

Download the source code.

Try it now

You can also try it out in a geo-aware browser. This should work in Chrome, Firefox and Safari 5, as well as on iPads and iPhones (and probably Android), though the user interface will need to be changed to support smaller devices.

Keep in mind that if you’re on a real computer, you’ll never see the “you’ve moved” state change since your location is based on your internet service provider. Even on a mobile device, it can take quite some distance to update your position as GPS does not discriminate very finely.

Here’s the executive summary of the talk:

• You can add interactivity to an EPUB book using either the <object> or <script> elements.
• Currently object has the best support, especially using Flash in Adobe Digital Editions.
• The script element is specifically discouraged (though not disallowed) in EPUB 2.0.1, and no major reading system supports it. However, all browsers do!
• The primary advantage of interactivity using script is that the content creator has the ability to manipulate every part of the ebook: all of the text, its layout, even potentially the user interface of the reading system itself. With object you can apply interactivity to just an arbitrary rectangle.
• There is a great deal of interesting animation and even interactivity possible using CSS3, which is allowed in EPUB 2.0.1 and is supported by iBooks and other WebKit-based ereaders.
• Interactivity is also possible using JavaScript combined with the HTML5 canvas element, though canvas is not part of EPUB 2.0.1.
• With access to JavaScript on mobile devices, ebooks can potentially gain access to information about the reading device itself, such as the location of the reader in the physical world, or the device’s orientation, or even add photos and video from the device’s camera.
• Any ereader that allows JavaScript provides the ability for ebooks to access live data on the web.
• The primary blocker for extremely rich interactive ebooks is ereader support, but by embedding browser-based reading systems like Monocle, content creators can distribute such ebooks today.
• It remains to be worked out how to handle JavaScript in larger ereading systems both safely and with proper fallbacks to non-interactive content.

I’ll also be posting some of the example files used in the tutorial in a forthcoming post.

In the video you can enjoy the dramatic moment when the lights inexplicably dim and I think I’m being thrown off stage.

(Slides for ‘Designing ebooks for ePub reading engines’)

Update April 19, 2010: Like many others, I was unable to fly to London and will not be attending LBF.

Just click Add your own catalog at the bottom of the Get Books page and we’ll show you some catalogs we recommend that are just one click away. If you know of another catalog of ePubs in OPDS format, just use the form at the bottom to add it by file upload or point it at a URL (your Calibre library in the cloud, perhaps):

The particulars of this OPDS Catalog format are still fairly new, but under the hood it’s just a list of available publications. It seems like a perfect fit for digital magazines like PragPub:

As always, any books you’ve added to Ibis Reader will be available anywhere, anytime. If you’re using the mobile app version, you can browse your whole Ibis Reader library using the My Online Bookshelf link and choose whichever titles you want to download to your phone/pad/thing.

Know of a great OPDS Catalog of DRM-free ePubs we should add? Please leave a comment with the URL of the catalog.

If you’d like to learn more about creating an OPDS Catalog for your own books, please introduce yourself on the openpub mailing list or contact Threepress.

You can encourage visitors to your site to add your Catalog to Ibis Reader using the same type of widget we introduced for reading ePubs:

http://ibisreader.com/catalogs/add/?url=URL-of-the-Catalog&name=Best+Catalog+Ever

To try to shed some light on some complicated work, I’ve pieced together a very incomplete introduction to some of the new things that HTML5 and related specifications might bring (remember: they aren’t finished or implemented everywhere).

Seven concrete areas of opportunity:

New semantics

HTML5 adds a bunch of new elements that might help publishers represent their content more clearly.

• section, article, header, and aside should be very useful wrappers for real-world content.
• Older web browsers will safely ignore unknown tags, but some ereaders that aren’t based on browsers may exhibit unexpected behavior. Also, typically, semantic tagging alone won’t drive a lot of sales.

Drawing

HTML5 adds a canvas element, which allows for (really snazzy) complex drawing and animation. Mark Pilgrim’s chapter in Dive into HTML5 offers not only the hairy details but also an example of how embedded HTML5 can change instructional materials (view it in Safari).

• This might replace some of what we think about when we say ‘Flash’ casually. It might allow for more interactive elements to be included in content.
• There are no easy-to-use tools that generate canvases — they must be coded by hand (Although it sounds like some basic tools are close).

Video

HTML5 adds a video element, which offers the first standards-based way to embed video in a web page. Similarly, an audio element has been added.

• Seamlessly embedable video may offer new ways of assembling and delivering multimedia content.
• Licensing for the actual encodings of the video content (the way that they’re compressed and stored) is unbelievably messed up and getting worse.

CSS3

A related set of updates to the Cascading Stylesheets specifications, CSS3, is often discussed alongside HTML5.

• CSS3 may bring a range of delightful updates for content creators, from better support for font-faces on the web to animations and transitions that may (along with canvas) allow alternatives to Flash for flashy stuff.
• Licensing solutions for fonts on the web are still in-progress. Authoring tools non-existent; support not complete across browsers.

Geolocation

Updates to a JavaScript API alongside HTML5 allow for users to reveal their physical location.

• There are probably a lot of opportunities to connect reading, readers, booksellers, and where people actually are.
• Very little support on desktops or more basic phones.

Offline Applications

A set of specifications related to HTML5 make it possible to create web applications that run without an active internet connection.

• Offline web applications can offer many of the features that standalone iPhone and Android Apps have and do not have to go through any App Store. They may also be more portable, as they don’t
  have to have a separate set of software for each platform. [Explicitly: This is the part of HTML5 that allows Ibis Reader to behave just like a normal App on iPhones, iPads, and Android phones.]
• Offline web applications are typically slower than standalone apps, although this will become less important as faster devices like the iPad become more common. Support on platforms is not uniform. Firefox doesn’t seem interested in supporting the current database specification.

Microdata

Another related specification that provides way of adding machine-readable annotations to content.

• One use of microdata might be to embed content licensing and other details inside pages.
• Yawn. Some of these features have been around in microformats for years and haven’t really taken off, although this could be very important for specialized content with regularly-structured content (cookbooks would be an easy example).

Sadly, HTML5 support (on any of the above) in Internet Explorer (even the unreleased IE9) is woefully incomplete and IE is still the most ubiquitous browser. Look at the number of red Xs in the right-hand columns of this support chart: http://www.findmebyip.com/litmus/

Does the above inspire you to try out some of these new opportunities now that you can pierce some of the HTML5 hype? Please let us know, as we’re actively seeking publishers and authors interested in innovating and experimenting with actual content to develop short- or long-form examples that take avantage of these new possibilities for enthralling, educating, and entertaining readers.

Want to explore in more detail? Both http://html5doctor.com & http://diveintohtml5.org have great details on the state of the above technologies.

As folks who need to listen to the desires of ebook readers, help publishers understand how to get the best from ePub, and implement increasingly sophisticated ePub readers, we’ve gotten used to riding a fine line between enabling thoughtful design and ensuring a pleasant reading experience on a wide range of devices. Here are some pragmatic perspectives from our experience building reading systems that can help those coming from a web CSS background understand some of the tradeoffs in the ebook design world.

I’ll start with a simple example of the impact of CSS margin and width on an iPhone-sized screen:

This may look like a minor change, but the line lengths were reduced from 34 characters down to 27. Either one of those line lengths is already less than the typical “sweet-spot” from printed book design, so losing nearly 20% is actually quite significant. The real surprise from the margin example above is that it comes from Feedbook’s tremendously reasonable CSS.

The problem (from the perspective of a reading system) is this: readers need top-level margins to make the text digestible, but we can never unambiguously tell if the ebook designer has already included top-level margins in the design. Basic, top-level margins should be established by every reading system based on the device being used and designers should include margins in their CSS only when they are focused on a specific type of content like a blockquote or poem. Unfortunately, some early ePub reading systems failed to establish even basic margins for readability, so many ePubs are designed to compensate for that flaw. [If you'd like a future post explaining the history of how we got to this position, please let us know in the comments.]

Now we’re in a chicken-and-egg fight: if ebook designers would include more complex design elements (and eliminate unnecessary margins), the makers of ebook reading system would be more motivated to fix their margin bugs and add more CSS support. Today, the maker’s of ebook reading systems might honestly believe that these features aren’t requested because the designers are being understandably pragmatic about current capabilities in the wild. We’d like to encourage more deliberate ebook design, but also inform designers about some of the basic design elements that might be dropped on the floor by the reading system.

What do we do in Ibis Reader? Because of limitations in screen size, Ibis Reader tries to override the following CSS properties when used on an iPhone, iPod Touch, Droid, or Nexus One (as an installed app) at the chapter level:

Left and right padding and margin

We need to be able to limit the length of lines.

width

We need to be able to ensure that the user interface isn’t ever wider than the screen, so that scrolling isn’t required (except for code or other verbatim blocks).

font-size

Readers have a wide range of ability and sightedness, so we give them control of the base font size (but relative sizing still works as expected).

font-family

This one is a bummer. The current set of mobile devices don’t all support some of the newest techniques for including other fonts, so we’re limited to a tiny number of font families at this time.

Happily, the web version of Ibis Reader does not have these restrictions, especially when used on a big screen, so the design from the ePub is usually more faithfully preserved. However, we do still discourage ebook designers from using the following CSS properties:

• Left/right padding and margins (only when applied too broadly)
• width, mid-width, and max-width (percentage-based more permissible)
• background-image (and friends), which happen to be excluded from the OPS CSS subset
• Inline with the OPS spec, the use of the CSS position property values to achieve absolute positioning (i.e. absolute and fixed) is strongly discouraged.

That said, none of the above are hard and fast rules, and there may be occasions where any one of the above is entirely justified by the confident.

PS: A secret for ebook designers: While there are a lot of techniques the creator of a reading system can use to alter the CSS from an ePub, the most standards-compliant way you can make your voice heard is to use the !important declaration. Like any tool with great power, !important should be used sparingly and only in situations where you are confident that the clarity of the text will be compromised if a property is not honored.

The following information is derived from the dc:language field in the OPF file.

Here’s the chart:

Missing from the chart, of course, is English. It’s so overrepresented it skews the chart to the point of being unreadable.

Of the 62,000 epubs on Bookworm right now:

• 29,642 have no language value
• A little over 20,000 are English (combining various values like “en”, “en-GB”, or — embarrassingly — “American”)
• The remainder, 5,874, are distributed among all other languages
• Almost half of the values are represented just one time (likely bad data)

I found it very interesting that the most represented non-English language code is cs — Czech — by a huge margin. Any ideas why?

Wondering which values are correct? The OPF 2.0 spec is unambiguous:

The content of this element [dc:language] must comply with RFC 3066

(Also, does anyone speak “Robert”?)