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’)

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.

We’re on track now to resume consulting and custom publishing software development alongside Ibis Reader, so please feel free to contact info@threepress.org for:

• Ebook strategy
• EPUB consulting
• Help getting books onto the iPad
• Challenging ebooks: enhanced books, video, audio, interactivity, custom fonts
• HTML5 and mobile development
• Custom Bookworm development
• White labeling Ibis Reader
• XML workflows
• DocBook and other schema development
• Speaking and training

If you access the site on an iPad today, you get a different block of content on the home page:

The link provided is the same one that we direct all HTML5 devices at. Here are some screenshots from the experience:

List page

Book table of contents

Reading page

Obviously there are some stylistic changes we’ll want to make:

• Making the margins in reading pages wider
• Enlarging the size of cover images
• Making better use of space on list pages

Tech notes

Here are a few things we had to change to get it working:

Event handling

On Android and the iPhone, touchstart and touchend events are fired when the user touches the application, followed by onclick. We preferentially use the touch events when reading a book because of some quirks in Android.

The iPad doesn’t seem to automatically fire the onclick event after a touch, so I had to make it manually trigger that for anchor links.

Orientation changes

The iPad simulator doesn’t fire the orientationchange event when the simulator is rotated. We don’t know yet whether that will be true of the device, so at this time Ibis Reader won’t correctly re-paginate after an orientation change.

Viewport width/height

The iPhone doesn’t report its height/width correctly, and doesn’t report it differently when rotated. We have these values hard-coded in the app.

Happily, the iPad does seem to report the correct value, both when the URL bar is visible and when it’s not (because the app has added to the home screen). We don’t yet know about rotation since we’re unable to detect that.

HTML5 database size

There’s a bug in the current iPhone OS (3.1) in which the user won’t be prompted to increase an HTML5 database after the webapp has been added to the home screen. This means that Ibis Reader users on the iPhone can’t ever add more than the default 50MB worth of books. This bug appears to have been fixed in the iPad OS.

(Android does not prompt the user to increase a DB, but does increase it automatically if there is space available on the device.)

First, here’s how to get the update, since this was already asked:

Getting the latest update on your mobile device

HTML5 devices will get the very latest code on the second time you open the application after an update. So if you haven’t used Ibis recently, you might need to open and close it twice. If you’ve never used it, you’ll already be up to date. That’s it!

We always post the revision date at the bottom of each book information page:

We’re recommending that you also log out and log back in again if you haven’t used Ibis in awhile.

Full position syncing across all clients

While Ibis Reader has always kept track of the books you acquired from any device, it now also tracks your position within each chapter (as requested).

For example, if you read on the web site for awhile, then switch to reading that same book on your iPhone, you should see a message like the following:

Position syncing across multiple devices and font configurations is tricky and we’ve still got a few bugs, but we’ll be improving it along the way and would love feedback.

“No distractions” reading mode

While everybody loves fuschia, we always wanted to include a distraction-free reading screen that fulfills our mission of “getting out of your way.”

From any reading page on the website, click “No distractions”:

You’ll be taken into the new mode:

In both the table-of-contents view and in reading mode you can now make font face and size preferences, and these will persist across sessions.

You can also adjust the width of the text in reading mode by dragging the right margin right and left. This value will also persist:

Currently, automatic position updates are only posted when you’re in no-distractions mode, or when reading on a device. We don’t want to post your position if you’re just jumping around the TOC searching for something, only when you’re engaged in reading. But that might be a bad assumption, let us know!

Other updates

We also fixed a number of bugs and added a few small features here and there, primarily:

Open in Stanza or Aldiko

From any book information page you can choose to export the current book to these popular programs if you’re on an iPhone/iPod Touch or Android, respectively:

Just in the last few days, details emerged of two new JavaScript ePub readers, rePublish from Blaine Cook (@blaine) and JSEpub (screenshot) from August Lilleaas (@augustl). These two new readers join @liza’s epubjs, which will be a year old on Tuesday. An improved version of epubjs powers the ePub Zen Garden, which helps “dispel the myth that digital books can’t also be crafted works of visual design.”

Why are JavaScript ePub readers interesting? They’re interesting to me for three reasons:

• JavaScript is the most popular programming language in the world and it might be the best way to get more developers interested in creating and tweaking ePub readers.
• JavaScript ePub readers start challenging publishers, developers, and book readers to start thinking about what’s most important in delivering a compelling reading experience in a browser. We’ve spent a lot of time thinking about these choices while developing Ibis Reader, which will launch later this month, so I’m eager to see more opinions.
• Building a pure-JavaScript ePub reader requires unzipping in JavaScript, which had no open source implementations until just recently. August has written about and open sourced his critical breakthrough for unzipping files in JavaScript. [Edit: Oops! I was wrong about this one. See the comments for more details.]

Colin Hazlehurst has also published some impressive introductions, tutorials, and code for the .NET/C# crowd at his InsideEpub project and on his blog.

Do you know of other techies making waves with ePub? Please let us know!

(And if you’re one of those publishers who is looking for help, contact us.)

We’re starting to share early betas of the Ibis Reader mobile UI for iPhones, Nexus Ones, and other Android devices with a limited group of testers. If you’re interested in joining the beta program and testing on other phones, tablets, and laptops, please email info@ibisreader.com. You may be asked to sign a non-disclosure agreement.

More info on our upcoming ereader is available in our announcement post.

I wanted to see if could construct a valid ePub file using HTML5 (in this case, employing the HTML5 <video> element). The problem is that ePub only supports one kind of HTML: XHTML 1.1, a flavor of markup which seems to exist only to annoy people trying to create valid ePub files.

There are two methods to include “foreign” media types in ePub. The first is out-of-line items which have separate fallback items, either out-of-line XML in another vocabulary, or a separate type of binary media like a movie falling back to a static image.

The other is Inline XML islands, which uses a unique <ops:switch> element to toggle among two or more different XML vocabularies.

My first instinct, if I were going to include the HTML5 <video> element, was to make an inline XML island and switch between that and the Flash fallback. But <ops:switch> depends on the XML island having a different namespace. HTML5 uses the standard XHTML namespace (http://www.w3.org/1999/xhtml), so there’s no way to indicate that we’re using an XHTML vocabulary that isn’t XHTML 1.1.

Got that?

But there’s another option: treat the whole HTML5 page as an out-of-line island. How? By not using the XHTML vocabulary at all, but instead treating it as media-type text/html:

    <!-- HTML5 -->
    <item id="video"
          href="video.html"
          fallback="video-fallback"
          media-type="text/html"/>

    <!-- XHTML 1.1 fallback -->
    <item id="video-fallback"
          href="fallback.html"
          media-type="application/xhtml+xml" />

Here I defined a document with an unsupported media-type (text/html) and a fallback in a supported type (application/xhtml+xml). Unfortunately there’s no way for me to actually specify that it’s HTML5, since HTML5 doesn’t even have a real DOCTYPE.

I also include the media files in the OPF:

  <item id="video-mp4"
          href="20143.mp4"
          media-type="video/mpeg4"/>
    <item id="video-ogg"
          href="20143.ogv"
          media-type="video/ogg"/>
    <item id="video-png"
          href="video.png"
          media-type="image/png"/>

And here’s the complete HTML5 island:

<!DOCTYPE html>
<html>
  <head>
    <title>Video test</title>
  </head>
  <body>
    <p>
      <video width="320" height="240" controls="true" autoplay="true">
        <source type="video/ogg" src="20143.ogv"  />
        <source type="video/mp4" src="20143.mp4"  />
      </video>
    </p>
  </body>
</html>

Here’s the sample file: HTML5 video in ePub. This will actually work in Bookworm, but nowhere else. It’s also not valid according to epubcheck, but only because epubcheck thinks that the text/html item is an error, and it doesn’t like that the HTML5 island is missing a namespace (because it’s not actually XHTML, but text/html).