I'm getting software - Filed under 'standards'

IT history is repeating itself - but it is not a shame

Following a twitter discussion with Tom Wentworth , Kevin Cochrane and Stephane Croisier on the impact of Facebook Connect on Web Content Management, Stephane made following comment, which needs an answer in more than 140 characters.

Facebook Connect is a technology that allows third party web applications to connect and share data with the Facebook social network. It supports authentication, access to user properties like name and birthday, and it allows sharing of application data on Facebook, for example a website could post custom status notices that would appear in my Facebook activity stream as "Lars did xyz on site abc". Jeremiah Owyang called Facebook Connect an example of Social Colonization earlier this year. And while in Jeremiah's description the colonization turns out to the mutual benefit of Facebook and the connecting site, there is still a negative connotation with the term "Colonization", which is shared by many people in the industry, most of them outside Facebook.

The cornerstone of our discussion is that while Facebook Connect is the most popular example for social network interoperability technology, there are numerous other emerging standards and technologies that can be used to create a distributed social network. The most important examples are:

RSS /ATOM - a way to exchange data in feeds between applications on the web
OpenID - a way to identify yourself to a website using the credentials of another website
OAuth - a way to grant an application access to a certain part of your data on a website
OpenSocial - a way to exchange data about users between social networks
OpenSocial Gadgets - a way to embed small web applications, gadgets into other websites
ActivityStreams - a way to share the activity of an user on a social network with other websites
DISO - a collection of technologies to create a distributed social network

This open ecosystem allows developers to create distributed social networks without relying on a single centralized "Conquistador" like Facebook who controls data and access to the system. Yet, for now I would recommend website owners to invest resources first into implementing Facebook Connect. The main reasons are: you get access to the largest possible user base, the integration model is well tested and needs no fiddling with multiple, developing technologies and users already know what to expect from a Facebook Connect integration. Once the limitations of the centralized model become obvious, for example because the central hub is unable to scale, loses the trust of users, or benevolence turns into malevolence - then it is time to federate and to invest into open standards and open source.

This pattern can be observed numerous times in technology: a proprietary leader defines the market, fails in an attempt to fully dominate the market and is attacked by other players in the industry striving for standardization and openness. "If you have a problem for a long time, maybe it's not a problem, but a fact". It think this pattern is not a sign of our industries inability to learn, but a result of the basic economies of innovation.

Innovation is hard and costly, so you try to keep it for yourself (proprietary)
In technology, network effects make successful innovations wildly successful
In order to fully monetize the hit innovation you had, you have to keep a close grip to it

This explains why hit innovators are favoring closed solutions: it is the easiest way of getting their investment back. What worked for IBM, worked for Microsoft, worked for Oracle, worked for Apple, worked for Facebook, so why shouldn't it work for your next innovation? In fact, it will work for the innovator, it just won't work for users. Companies do not do the right things all the time, but if you are locked in into a technology, you are betting on your vendor hitting one home run after the other. And this is why users and visionary followers are pushing for openness, standardization and decentralization - another significant effort, but one that requires an existing, proven market to justify the investment in standardization.

The reason why history is repeating itself is simple: we cannot start out with a standardized solution, because we neither know what to standardize nor if it is worth the effort. Once we know, there is an established, proprietary player that is holding to his closed technology.

Filed under // apple diso facebook microsoft oauth openid standards

html5flash: Using HTML5 video and audio right now (with a Flash video fallback)

(download)

There has been some discussion lately on the best way of implementing HTML5 video. Laura Thomson started the discussion by describing for using HTML5 video with fallbacks to other formats. Laura's solution consists of detecting the availability of HTML5 video using Javascript. If this tag exists, it will be inserted dynamically into the page, if not, a Flash-based fallback will be added.

This caused a prompt response by Kroc Camen and others in an open letter , no less. The points of criticism are lack of accessibility, lack of security, and most important by treating video as a Javascript feature, the document nature of an HTML page is ignored, making it hard for alternative user agents (something that browser vendors sometimes forget) to deal with the multimedia content correctly, which disables mashups and aggregations. Kroc proposes an alternative solution, called Video for Everybody , which uses the HTML5 video element, with a contained object element that embeds a Flash-based video player as a fallback. This flash player has another fallback, namely Quicktime. If this fails, download links to the video are offered.

While this solution offers the broadest compatibility, does not require Javascript and deals with all the issues mentioned in the original open letter, it does not fulfill the sense and promise of the HTML5 working draft. This working draft specifies more than just a simple video (and an audio) tag, that works like the img tag. HTML5 acknowledges that audio and video are multimedia content that provokes a user interaction and offers the ability to control video playback, implement own controls and register event listeners. It even provides a sophisticated model for source selection that deals with the fact that there is not a single cross-platform, cross-vendor video format for the web.

Neither the Video for Everybody approach nor the original Mozilla proposal seem to recognize this fact, but it is critical for every web developer who wants to embed video into a web application and control the playback. In the Mozilla example this means dealing with two separate APIs, in the Video for Everybody case, it would be 3 or more APIs, with the limitation that the current state provides for only the HTML5 API. Not only will this lead to additional effort for the developers, it will also limit the adoption of HTML5, because it is just another API for video.

For the last week I have been working on a third solution, which is called html5flash , a small Apache-licensed Javascript library that will wrap a Flash video or audio player and expose the HTML5 mediaobject API. This means nearly all attributes, properties, event listeners and Javascript functions of the current working draft are supported, which allows developers to create HTML5 video and audio applications right now, without the need to rely on a proprietary API. Of course, there are still a number of limitations, but the source code is available from github , so that any interested developer can fork the project and contribute.

The technical solution is based on the work and ideas of many people. It works by a technique called gradual enhancement that was introduced to a wider group of web developers by Dean Edward's IE7 script, which fixed many of IE6's glitches, so they could use advanced CSS at a time when only Firefox and Opera would have proper support out of the box. html5flash will detect all video and audio tags in the HTML document and find out wether the browser supports HTML5 already, in which case nothing is done. For browsers that do not support HTML5 already, a wrapper object will be created that implements the HTML5 video and audio spec, making all methods, properties and event handlers available to the developer. Then, the script uses Scott Schiller's soundmanager2 library to create a Flash-based audio or video player. Again, this is not a new idea, actually Mike Chambers, product manager at Adobe has shown how to do it before.

What does this mean for developers? They have now three ways of using HTML5 right now, with the ability to provide workable fallbacks for the 98% of web surfers that do not have an HTML5-capable browser yet, but Adobe Flash installed. The simplest html5flash solution would look like this:

<!DOCTYPE html >

<html>

<head>

<title>Video Example</title>

</head>

<body>

<video

src="media/video.flv"

controls="true"

width="416"

height="336"

poster="media/video.jpg"></video>

</body>

</html>

You still have to provide multiple video formats, namely FLV or M4V for Flash, MOV or M4V for Safari 4 and OGG for Firefox 3.5, but with html5flash you have one simple way of embedding video and audio together will full control using the HTML5 mediaelement API.

Filed under // adobe flash html5 javascript mozilla standards web

Posted by Lars Trieloff

Comments [7]

I’m getting software

Tags

standards

IT history is repeating itself - but it is not a shame

html5flash: Using HTML5 video and audio right now (with a Flash video fallback)