Archive for May, 2009

The Big Web Video Battle that Was

A small point here on the title of this article “Adobe & Microsoft: The Big Web Video Battle to Come”, which has been hanging in the aggregators over the weekend, and which doesn’t offer open comments.

Back in September 2007, the New York Times reported that “Microsoft’s share of total streaming video use is 85 percent… In the United States, video sent using Adobe’s Flash format accounted for 22 percent of all streaming video traffic in 2006.” I’m sure there are other stats to quote, but Windows Media workflow, from encoders to servers to CDNs to runtimes, was clearly the big dog.

And in September 2007 Microsoft released a new browser plugin for Windows Media video, named “Silverlight”, which brought back support for the most modern Apple computers, and which promised to increase video share even further.

Today, the New York Times and others generally agree that about 80% of web video comes from Flash. We’ve seen significant realtime video providers retool their entire backend to use Flash video workflows. And we’re on the brink of new innovations with interactivity, metadata support, cross-device support, and captured/generated integration (“Augmented Reality”, eg).

Just a few years ago, 80% of web video was in WMV. Today, 80% of web video is in SWF. Looks like something happened in the meantime…. 😉

It’s always possible for changes to be reversed. But to really make a pitch on “The Big Web Video Battle to Come”, it seems like you’d first need to understand “The Big Web Video Battle that Was”. No blood, no gore… just a lot of consumers and publishers shifting their support to something which works better, for them.

The Browsers of Tomorrow

The browsers of tomorrow will likely include some type of editorial guidance, as this example of a child-oriented browser at TechCrunch today shows.

During The First Browser Wars, Netscape and Microsoft competed on adding similar new features in incompatible implementations, and in the rush did not think through the security implications. This pattern is recurring in The Second Browser Wars today, with the current “HTML5” committee focusing on RIA specs, and it’s likely that many of the brandname browsers of tomorrow will be much larger codebases, with more functionality which will inevitably interact in unexpected ways.

But a different approach is to tailor the browser to the needs of the audience, rather than to the needs of the browser vendors. Here a group optimizes a user-experience for children using AIR. As TechCrunch describes:

KIDO’Z is a pretty nifty Adobe AIR-powered desktop browser app that gives kids a safe and fun environment to play games, watch videos and/or visit pre-approved websites. When you first install the AIR app as a parent, you can configure the age and gender of your offspring as well as your location and preferred language… All content only shows up when a KIDO’Z team member approved the content beforehand, and to add more layers of security all scripts, file downloads, pop-ups and any other attempts that could lead to content which has not been approved, are thoroughly blocked. To use the app, kids won’t need to know how to read or write since obviously the whole UI is quite visual of nature, and very colorful to boot.”

The application is tailored to the needs of the audience. HTML should serve children well… children should not be forced to have adult sensibilities before using a browser. One editorial approach will not suffice for all, obviously, and there are many possible “trusted voices” which can help guide the web-browsing experience.

I think the hypertext specification should be clear and easy to implement. But that now conflicts with corporate desires to control each layer of the consumer experience, and to lock-in use of their own runtime engines. AIR provides a way to fight back, by using HTML or SWF to customize a particular user experience atop a standard Webkit implementation.

AIR includes a browser, but is not itself a browser… you can think of it as a web browser toolkit. Anyone can now make tools for surfing the web more efficiently, more appropriately. No need to all wear the same uniform… browsers can now be customized for the audiences they serve.

Linux Journal “Readers Choice”: AIR

Lots of folks have already noticed this, but I liked the news for a particular reason… Adobe AIR won the Linux Journal’s Readers’ Choice award for “Favorite Platform for Developing Rich Internet Apps” this year.

AIR makes it easy for native desktop applications to work on various flavors of Windows, Macintosh, and Linux. It reduces discrimination based on OS choice, imposes no requirements on browser choice.

But AIR doesn’t just enfranchise consumers on Linux — it also enables creators on Linux. It’s pretty cool that a developer who personally prefers Linux can deliver to Apple systems or to Microsoft systems too.

It shouldn’t matter what operating system you choose, what browser you choose, what ad-network or remote services you choose, or (in the pipeline) what device form-factor you choose. Those walls need to keep tumbling down.

Thanks to the readers of Linux Journal for understanding this, and acknowledging the new AIR initiative with this award!

Native file formats vs data exchange formats

Last week there was some attention paid to a years-old code fragment on Google Code, where someone got cranky when trying to write a .PSD importer. Since then it has moved up the blogosphere feeding chain, and today it broke into The Register.

The Photoshop native file format was not created as a data exchange format. It was a way for Photoshop itself to store its authoring metadata.

That’s why you don’t see the PSD spec among Photoshop Developer Resources, and why the original writer had to formally apply for a copy. It’s a format that was designed to do a particular job, not one that was intended as a general import format that anyone could use with relative ease.

If you’re trying to use a native file format as a data exchange format, you’re swimming upstream. It’s possible, but the format was not designed for that purpose.

Now, the larger issues:

The Web earns advertising dollars from the titillation of crankiness. It’s difficult to otherwise rationalize why this old code fragment would be newsworthy. I can accept this, but think it’s sort of a shame that this day each of us were given was not used for better purposes. What’s really important?

Secondly, the use of classic four-letter words is lame. (I’m looking at you, Twitter. 😉 People use such words to shock, but George Carlin’s “Seven Forbidden Words” have merely shifted membership over the past two decades… if you want to really be a rebel, then challenge your own in-group’s stereotypes and forbidden thoughts, instead of cementing your little in-group in opposition to “those other” in-groups. Think of what you may not say without serious repercussion before reveling in their sanctioned rebellion. Read Martin Fowler’s wrapup of how the greater sin may be in assuming “that won’t offend anyone”. Open up.

Anyway, yes, .PSD is harder to read than TIFF or XMP or PDF or the rest. If someone rants about not understanding this, then how much of your day’s attention do they deserve?