I recently gave a presentation to my colleagues at Videojuicer about HTML5 and what it means for our business and our technology roadmap. Being a mindless sheep, I did of course opt to create the presentation itself in HTML5 with the intention of having the audience follow along in their browsers, without the aid of a projector.

Then, a thought occurred.

If I’m putting a slide deck on screens that are owned by the audience, then the audience should get some control of their own.

Using this principle as a guide, I hacked up a quick Node.js and Socket.io demo that would allow audience members to either sit back and follow the presentation as I moved through the slides, or to break off from the flow and browse the deck themselves, rejoining the rest of the audience whenever they choose.

Designed for audiences like this.

The presentation was a success, and I was struck by the creative potential of allowing audience members their own runtime instance of a slide deck. What’s possible with this setup that isn’t possible with a regular Keynote presentation? Including hyperlinks for audiences to follow for further reading is basic. We can do more:

• Include interactive elements in slides. Navigable data visualisations, canvas objects, tech demos, whatever.
• Use selective disclosure to keep slides brief but allow individual audience members to drill down on items they find interesting.
• Allow audiences to simply save your presentation out of their browsers.

Introducing Squeenote

I’ve since cleaned up this presentation engine and released it under the name Squeenote. Authoring presentations for Squeenote is ridiculously simple; a presentation is simply an HTML file containing an ordered list of slides. See the README for more information. Here’s the initial feature list:

• Presenter follow/unfollow for audience members
• Password-protected presenter mode
• Support for HTML5-friendly browsers. Tested in Safari, Chrome, Firefox, Mobile Safari.
• Themeable. Since a presentation is just an HTML file, a theme is just CSS and/or JS.
• Includes a default theme using CSS3 Transitions, with basic iPad and iPhone support for audience members.
• Modular and hackable. All components, including the Squeenote UI, are replaceable and extendable.
• Designed for archival. A Squeenote presentation can be uploaded to a static web server without the Node.js component and it will run in “presenter offline” mode.

So I heard you like Presentations

Squeenote includes a short presentation about Squeenote, authored in Squeenote.

Clone it and use it

Squeenote is available for free at my Github profile. It’s released under a Creative Commons license as it is intended to be altered in a highly-personalised fashion.

Permalink to this article

Okay, so I’m basing my optimism for HTML5 video on a hypothetical future where Internet Explorer vanishes from the earth, and even in the browsers that do support it, codec support is inconsistent, but in my opinion those differences will become meaningless very rapidly because there is only one truly dominant browser engine in the mobile space, and it’s Webkit. And mobile is where HTML5 video will truly shine, because you don’t get Flash video on the iPhone and you do get Webkit. I wish it were more complicated, I really do. If it were more complicated I could make some extra money as a consultant.

I digress. Or rather, because the digression occurs so early, I fail to begin. So let us begin.

Where does the value in viral video come from?

Why are agencies able to charge gigantic sums for the privilege of having their brand associated with a video of fifteen hundred people being a bloody nuisance at King’s Cross station? Firstly, it builds intangible value. Exercising control over any large brand has traditionally been an epic, thankless task, so the concept of simply producing something amusing and using people’s newfound capacity for mass sharing as a delivery and targeting strategy was a bit of a sensation.

Secondly, an embedded flash video naturally must come with a user interface, which means interactivity. And where you have interactivity you can generate clicks that lead directly to your product. The value comes from not just embedding the video, but embedding the video player with all its little hidden engagement-measuring technology and up-front calls to action. In most commercial video environments, the content itself is just a tiny part of what gets delivered to the user’s browser.

HTML5 video is referenced assets, not embedded behavior

Now. HTML5’s new <video /> tag lets us deliver the content - the video file itself - but it does not let us deliver all the other bits and bobs that make web video so valuable. Video rendered with the <video /> tag will have no interactive elements such as advertising or social features, nor will it have the ability to share an embed code for itself. These features must now be delegated to the HTML and Javascript around the video player rather than being encapsulated within it.

This behavior makes sense, given the semantics of HTML - much like the <img /> tag, the <video /> tag is a dumb reference to an external asset, and the browser is free to ignore it, use the alternate text, or render it depending on the situation and its capabilities.

What’s missing from the HTML5 picture?

The point I’m trying to demonstrate here is that the <video /> tag is just a small part of the puzzle for video on a post-flash web. As a video publisher, I want to be able to deliver a player - not just a video file - to users, and make it easy for them to share that experience with others.

“But Dan,” I hear you cry, “you can just build a player out of markup and javascript!” And indeed you can. Youtube already have an excellent duplicate of their flash player built in HTML5, after all. But let’s look at the problems of sharing such a player.

First, you’re going to try having users copy and paste the gigantic wedge of markup and javascript that make up your player. This will fail for a few reasons - most notably, you can’t release patches for the player once it’s been embedded, and you must implement permanent URLs for your video assets.

Then you’re going to refactor the bloody thing to something like this:

<script type="text/javascript" src="http://mysite.com/player.js?replace=thevideotag" />
	<video src="http://assets.mysite.com/some-overdone-meme-lol.mp4" id="thevideotag" />

Which is cool, because if the Javascript fails then you still have the video tag to fall back on. However this will also fail, because you can’t share <script /> tags on forums or social networks for security reasons. And that pesky asset URL problem is still there.

“Eureka!” You will think next, “I will serve the player remotely from my application as an HTML5 document unto itself!” And that is a good suggestion. However, the only way to embed such an application is by using an <iframe />, and that is, to be blunt, fucking disgusting. You can’t use iframes on most forums or social networks, and they have absolutely monstrous security problems. They also have very poor semantic value for the use to which we want them put.

HTML5 is supposed to be an application markup language. It’s not just for documents anymore. The standard is absolutely lousy with interesting interactivity (such as OS-native drag and drop), but it contains no firm way for applications to be nested or otherwise made modular.

For this, I have a suggestion. I would like to see the following work in HTML5:

<embed type="text/html" width="800" height="450" src="http://mysite.com/player.html?video_id=FOO" />

No, you haven’t gone mad. That is an <embed /> tag. Yes, they’re disgusting. But they also match the semantic we want - we want an embedded application which just happens to have been written as an HTML5 document. We want the security domain inherent to embed tags, which allows the host document to remain opaque to the client document at the host browser’s discretion. This is the semantic I would like to see for embedded applications in HTML5.

Update: When publishing this post, and thoroughly buggering up my code sample escapes, I noticed that the above embed code actually renders in webkit! No Firefox support though, alas.

Permalink to this article

The Kübler-Ross model is a classic pattern that defines how people deal with great loss or catastrophe. It’s the five-stage grief model so beloved by TV scriptwriters - an array of shows have made use of the model, most notably this brilliant episode of The Simpsons in which Homer learns of his own impending demise:

Hibbert: There are five stages. First is denial.
Homer: No way, because I'm not dying.
Hibbert: Next comes anger.
Homer: Why you little...
Hibbert: After that comes fear.
Homer: What's after fear? What's after fear?
Hibbert: Bargaining.
Homer: Doc, you've got to get me out of this. I'll make it worth your while.
Hibbert: And finally, comes acceptance.
Homer: Well, we've all got to go sometime.
Hibbert: Mr. Simpson, your progress is remarkable!

It only occurred to me recently that the same model applies to a developer being told that his work has a bug. Not just a simple display bug, but one of those really nasty voodoo buggers that defy all attempts at rational explanation and turn debugging into a two-day stretch of swearing, shouting, and occult sacrifices. Observe:

Denial

Nah, that works just fine. Must be a freak happenstance, or the user’s machine is knackered.

Anger

Why do people bring me all these problems? Give the users better training!

Bargaining

Maybe we can just fix it in the next version, so I can get on with my life?

Depression

This problem will never go away. It’s going to actually haunt me until I die. I am Moby Dick to this bug’s Ahab.

Acceptance

If I fix this, I can have my life back.

Permalink to this article

When apple announced the iPhone OS’ new capability to provide a tethered cellular data connection to your laptop, the masses rejoiced. When some carriers announced hefty additional charges for the privilege of using your ‘unlimited’ data plan on a larger screen that you already own, the masses wept. It was as if a great many voices cried out and then were suddenly compelled to create a new trending topic on Twitter.

The problem, it seems, is that O2 promise to give you unlimited¹ use of your iPhone’s data connection, on condition that you do not take them up on the offer². The deal as they see it is that you can consume a reasonable amount of data on your iPhone itself, but if you want to view that data on a big screen - say, a laptop you already own - it’ll cost you another £13 per month for the privilege. For those playing along at home, that’s the same price as a standard O2 USB modem plan, only they don’t give you the modem.

Therein lies the obvious question. Why does it cost more to download a reasonable amount of data to my laptop than to my telephone, especially when the difference between the two is rapidly thinning?

For those who feel that being charged £13/mo to deliver data over the final inch between your phone and your laptop is an insulting proposition, you know have another option. One brave soul has created a small web application that provides tethering configuration for almost any carrier, enabling iPhone tethering without forcing you to buy a costly data plan in addition to the one already included your standard iPhone contract.

For those who choose this path, there are a few immediately obvious ways to profile a user’s connection to determine whether or not they’re tethering, so be mindful:

1. If your user agent string is anything other than Mobile Safari, then you’re tethering.
2. If you’re loading Flash movies, then you’re tethering.
3. If you’re loading Java applets, then you’re tethering.

Whether or not the operators will act on this finding is unknown.

Disclosure: I already hold a data contract with O2 and don’t plan on getting rid of it, as I find the USB modem very useful.

Footnotes:

1. May in fact be strictly limited
2. The use of terminology like “unlimited within fair use” is a long-standing tradition among mobile operators, who have no problem using double, triple or even quintuple negatives if it’ll shift more phones.

Permalink to this article

Kevin Kelly, of Wired fame, has launched a lovely collaborative project to map the Internet, sensibly named The Internet Mapping Project.

The goal is for individuals to try and map the hairy N-dimensional structure of the Internet into a two-dimensional representation that matches their own interpretation of it, but the interesting twist is that contributors are expected to place their ‘home’ on the map. The split in designs is interesting - some contributors have drawn the internet from a position of consumption, placing their home at the center of a network of services, while others have drawn their maps from a position of oversight, trying to make sense of the many brands and roles that dominate our lives online.

I decided to try my hand at contributing myself, so I spent an hour this morning with a biro trying to make sense of the thing. I wanted to illustrate the difference and interdependence between things online that are predetermined, and things online that just happen. It also amused me to depict ‘the bubble’ as a self-contained structure that is completely insulated from outside realities, and in which you are unable to survive past thirty.

What I ended up with is basically a water cycle diagram from year 10 geography class, except I didn’t colour it in.

which means I would, under the reign of my former teacher, have lost marks for failing to add artistic flair to what is intended to be a scientific topic.

Permalink to this article