iPad is the web made physical

What I wanted from the iPad—a very high-pixel-density HD screen in a small device—didn't happen. But in the commentary of my techie colleagues like David, Alex and Tim, I'm seeing another disappointment. They're saying 'this isn't a computer like I grew up with'. It's not the generative machine that can be bent to our will to do anything, it's a display device.

Now this is true, but it reminds me of programmers complaining about the Web, as opposed to native applications. The Web is something that started out as a display medium, but is now the platform we all expect to build our applications on, precisely because it is an abstraction that comes between us and the particular hardware our users are running. The web is an agreement on how to phrase things.

The iPad picks up this agreement and delivers on it in a new form, but exceptionally well. When the iPhone was launched, I said that the web was the one standard even Steve Jobs can't ignore. This is reinforced by the iPad - it opens with web browsing, and the Book format adopted, ePub, is built on HTML.

I would prefer it if anyone could distribute native apps for the iPad, but we all can create websites.

The big difference the iPhone brought, and that the iPad builds on is the pervasive ability to zoom in and out easily. I think that this will lead to a change in how we think about user experience, with the deep zooming experience we are familar with from Google Maps and now Prezi becoming natural in more and more apps.

Audio, Video, HTML5 and standards

The chaps at Mozilla, Christopher Blizzard and Robert O'Callahan reopened the HTML5 <audio> and <video> debate yesterday, with a spirited defence of their decision to support only the patent-unencumbered* Ogg format and Vorbis and Theora codecs in Firefox releases as part of their HTML5 support.

Now, I understand their motives here - back when I was at Apple, I spent a big chunk of time trying get permission to add support for Vorbis to QuickTime, but didn't manage to get it past Apple management's fears. However, all the browsers I use now claim to support HTML5 <audio> and <video>, so I thought I'd try it out. I made some simple test pages using mp3, .au and WAV files, to see how they were supported.

What I found was a bit disappointing - it seems that the way that the spec is written, you can support <audio> but no file formats or codecs at all (my Droid does this), and if you can't play the file you're not supposed to show the fallback HTML contents

This means that Firefox, Droid won't show the link to the audio file below:

though browsers that don't support <audio> at all will. Here's the markup:
<audio src="http://homepage.mac.com/kevinmarks/dystopia.mp3" controls><a href="http://homepage.mac.com/kevinmarks/dystopia.mp3" type="audio/mpeg"> Looking Up From Dystopia </a></audio>

However, if I use a direct link or an embedded <iframe>, Firefox will use available plugins to play the file (both Flash and QuickTime happily play mp3's). Thus using <audio> give me less compatibility with current browsers.

On phone browsers, odder things happen - iPhone gives a clickable button for the <audio>, but auto-loads an <iframe>; Droid ignroes iFrames, Palm Pre doesn't have <audio> but <iframe> behaves like the iPhone.

Smarter behaviour with declarative audio would be nice here.

*Submarine patent trolls keeping periscopes down may exist.