Archive for April, 2009

Antidisintermediationism (or Creators’ Rights)

Was reading the TechCrunch story on Disney distributing its high-budget linear-video productions through Hulu rather than YouTube. Makes sense — Google’s model is to commoditize all content and then sell audiences to advertisers. Creative work is usually compensated best when there’s a direct link between creators and audiences, not when there’s a monolithic gatekeeper in the middle. Makes sense that Disney would bond with other creators, rather than insert Google between Disney and their audiences.

The way Google republished books under copyright without the creators’ consent probably hurt them greater than they could have anticipated. I lost faith in “Don’t Be Evil” back when they stonewalled on perpetual cookies, and got radicalized when Google hired MoveOn to lobby for commoditizing connectivity. Treating Silicon Valley personalities as deities is much weirder than realizing they’re fallible humans, just like the rest of us.

Creators of digital communications which others wish to view are not serfs on some advertising farm. Each creator should be free to choose their distribution strategy to their own audiences. I don’t watch Hulu’s content myself, but I’m glad they’re developing alternative distribution strategies. Monoculture often becomes surprisingly expensive.

The needs of the haters

Last week at NAB there was big news about Flash being increasingly adopted at the hardware level by television manufacturers (see press release, Techmeme).

There wasn’t much new information beyond what most of us knew back in January, but it got a lot of fresh exposure in the mainstream techblogs. This produced a noticeable trend-change in comments at venues like CNET and Ars Technica.

Let me synopsize, rephrase some of them here, to give a flavor: “Oh great, now we’ll see all those annoying Flash banner ads over television shows just like we get to see on so many websites?”… “Well, the VIDEO tag in HTML 5 is on the way, and then there will be no difficulties with plugins as an excuse for using Adobe’s semi-proprietary crap-ware”… “GREAT! Now in addition to our PC’s, Adobe can crash our televisions”… “I can understand why some companies battle to keep Adobe off their devices – it is a trojan horse of functionality that can dominate/trump the device OS”… “Oh, great! Now they’ll be tracking our viewing habits with Flash cookies and sending targeted ads to our TVs”… “If I owned a T.V. I would not want to have Flash’s annoying ads on it”… “I’d be ok with 100% cpu if they could guarantee that it wouldn’t crash the TV like it does my browsers”… “Why not make the UI AJAX rather than flash? It’ll take 10% of the cpu”… “Why would any electronics manufacturer want to inflict Flash on their (soon-to-be-former) customers?”… “Oh good. I’ve always wanted my TV to drop frames and be bad at scaling video”… “How did Internet video streaming go so wrong?”… “I despise Flash. My first thought reading this was that its an attempt to control what we watch and how we watch it”… “Open standards is about letting technology progress for the benefit of the whole society, at minimal cost, instead of being hijacked and bottlenecked by a few capitalists so they can collect rent-seeking profits”… “I wonder what the environmental impact/energy cost of flash has been”… … “Can we please get SVG, SMIL, JavaScript, HTML5 VIDEO, etc. working together so that we can kill stupid crap like Flash already?”

There was similar reflexive pushback in comments to a blogpost of mine last week. This is what really started me wondering about the phenomenon.

The particulars of the attacks aren’t new… what struck me in the pseudonymous comments was the sudden strength in volume and emotional tone. In these forums there was little discussion of the news and its implications, but a significant amount of reflexive pushback against Flash itself.

The nature of the complaints shows no nexus — the most common point seemed to be “I don’t like ads”, which was quite peripheral to the discussion. People seemed to be grabbing whatever argument was handy, tossing it at the wall, seeing if it would stick.

The core driver seemed to be diverse sentiment against Flash’s increasing usefulness, rather than any particular addressable issue. My takeaway is that they’re seeking rationalizations for a pre-existing prejudice, and are increasingly concerned that those prejudices are becoming irrelevant in the world at large.

It is a stressful time for many “Flash haters”. The VIDEO tag has sparked interest, yet no one is realistically addressing the obvious questions about cross-browser deployment. Meanwhile Flash is increasingly acknowledged as the way to unite diverse browser brands, and is making significant progress on cross-device deployment across laptops, mobile, television, and embedded displays. Reality is crashing in on the rhetoric. Past challenges were not addressed, while future challenges are increasing. When reasonable questions cannot be answered, or even safely acknowledged, then ridicule is one of the few tactics left.

What to do? Well, some of the later comments at Ars Technica were more reality-based, although some of them verged into vulgar abuse. We can try reason; we can try fighting fire with fire.

But when the complaints are based less on reason than on prejudice, reasonable replies usually don’t take root, instead just spurring another collection of rationalizations. And calling the namecallers names — responding to intolerance with intolerance — is usually not a very enjoyable way to live.

My suggestion? For each of us individually to investigate the facts, evaluate the trends, and (most likely) see the haters as merely acting like frustrated deadenders. Emotional, but without hope. History and future-history both seem to be against them. They lash out.

If such commenters present a legit new point we still need to recognize it and respond to it… if there’s a newbie who heard “Flash isn’t searchable and isn’t accessible” we can still try in good faith to help them out… but I think we need to accept that there’s a minority who will complain in dysfunctional ways no matter what.

A guiding light, a silver lining: Anyone who fights for a technology position, cares about technology. They may currently have incorrect info or not clearly disclose their personal proprietary concerns, but they care. That’s something we have in common.

The long goal is in increasing the range of personal expression for all humans — to remove the barriers to people communicating their own ideas. Web-publishing is a part of that, and the greater engagement provided by rich-media and interactivity is a part of that goal too. If someone else is on that path, they are a potential ally — even if they’re currently throwing rocks from behind an online moniker.

Can I follow my own advice? Probably not, I still get frustrated with the tactics of prejudice! But there’s always the possibility of hope, potential futures in which they open up… that’s one thing I try to keep remembering when reading such people.

Flash Haters seem to be in a rather desperate position right now. They might try to hurt you, but if you can afford them some compassion and understanding (while not letting them eat your time ;-) , then that might be the best response in the long term, thanks.

Anticipating standardization, and deprecating standardization

Two different stories here, of the difficulties of banking on either presumptive or actual standards.

Dave Shea had an essay this week on how he is no longer using XHTML conventions in his paying work: “Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now. But in the intervening time it’s become fairly apparent to myself and others that XHTML2 really isn’t going anywhere, at least not in the realm that we care about. For me, a guy who builds web sites and applications for clients that have to work in today’s browsers, XHTML2 is a non-issue. No browser support, no use to today’s web authors. End of story.”

Advocates for a proposal often speak of it as an accomplished reality, before it actually achieves agreement from others, much less is available from browser vendors, then adopted by significant audiences, then proven cost-effective by content developers. There was enough talk about XHTML that it was easy to assume it was real. Dave bet on XHTML, and is now walking away from that bet.

Jason Grant mentions that the same dynamic is occuring today: “I find this very strange. Somehow you feel like HTML5 ‘is here’ while I would argue that XHTML2.0 nor HTML5 are here either. The ‘improvements’ offered by HTML5 are few and browser vendors have jumped into implementing it without really considering the future properly… Most people I speak to are not happy with HTML5 to great extent and that specification does not seem to be heading forward that rapidly either — in other words one could argue both XHTML2.0 and HTML5 are pretty dead.”

Dave demurs that he’s merely expecting HTML5 to be ratified and then implemented in its current form, and later adds: “I don’t feel like it’s remotely close to the right time to start delivering client sites in HTML5. Experimental and personal sites, maybe.”

Late in the thread Duane Storey had this interesting tidbit on a different subject, the academic rationale for XHTML and what happened when it met the real world: “The only real benefit to having a XHTML/XML document is that it can be properly parsed by a XML parser. In theory, that should make manipulating the document easier and rendering the document less error-prone. The reality is though, as a third party developer, since most sites don’t actually properly validate as XML, you can’t make the assumption that they are parsable, which basically means you have to treat most things as HTML anyways and allow for some slop.”

Most of the rest of the lengthy comments section is about arguing over rules, and what the rules mean, and what the rules should mean… not much about results.

What I got from Dave’s piece: Anticipating that a proposal will become a de jure standard, and then a meaningful de facto standard, is a gambling game.

Jonathan Snook brought up different-yet-similar problem… when should content developers consider fighting against what audiences actually use? IE6 has dropped from universal consumer support down to Firefox range, but it costs more for content developers to do new tricks in it. He doesn’t come down on either side of “the IE6 question”, but provides some new ways of looking at the problem.

Here’s how he opens: “If you haven’t done so, I highly recommend cracking out a copy of Firefox 1. Start bouncing around to a few sites and check out what’s broken. Sure, most stuff is fine but you’d probably be surprised at what’s broken. What about Firefox 2…?”

And here’s how he closes: “You may say that Opera is too small to really care about. It’s only 2%. You don’t care about Firefox 2 users. It’s only 2%. You may not care about accessibility issues. It’s only 2%. Soon enough, you’ve whittled down your potential market to 90% of what it could have been… I’ll keep thinking about all those people I could be getting. Did they walk away with the best experience? Sometimes it hurts my head just to think about it. So now it’s your turn: Should we care about old browsers or fringe browsers? Or are we safe in our little bubble?”

Internet Explorer 6 was the exclusive browser choice of over 80% of all surfers as recently as December 2005 — no other browser version has ever been used by so much of the audience! It’s the closest thing to a standard release (in terms of realworld audience support) that the browser world has ever seen. Even today it still has marketshare about equal to all versions of Firefox combined.

IE6 was the standard, and now we’re thinking of changing the definition of “HTML” out from under it to include things it won’t understand.

Another way to look at it: Should content developers effectively outlaw ex-standard user agents from their new-standard designs? Tricky question.

Comments at Jonathan’s were mostly “here’s what I test against”. Scott Jehl brought up the key point of mobile HTML, and I followed up on that, although I didn’t bring up the other key issue of archival formats versus the ephemeral web. Comments didn’t surface a solid answer to Jonathan’s question.

Dave was dealing with anticipating that something may become a realworld standard. Jonathan wrote about deprecating something that was already an overwhelming realworld standard.

Don’t know what it all means, and I don’t have answers to their questions, but thes are striking questions to think about.

Flash is in here, too, but the versioning issues are much less severe, and there’s already progress being made on addressing cross-device issues.

I don’t know what percentage of IE6 users are using the current Flash Player, but imagine it’s pretty high — people are hesitant to make big visible software updates because it risks changing things, and “if it ain’t broke don’t fix it”. But browser plugins don’t change UI or habits, don’t risk losing data. If you want to do new stuff faster, then it makes sense to have the runtime work across browser brands, across browser versions, and not to make a big splash of itself when it arrives.

There’s more resistance to updating a browser, much less changing a browser brand, and any browser choice tends to be an exclusive one.

Flash works with almost any browser, and doesn’t make you choose among them.

Different dynamics. The technologies complement each other.

Thoughts on Ruby’s “HTML Reunification”

I was off-the-grid when Sam Ruby of IBM, co-chair of W3C HTML Working Group wrote an essay on HTML 5 which sparked many comments, followups. Some of it went off into details, but here are some of the higher-level ideas I pulled out of it.

Sam starts by describing how the current HTML5 proposals fall into two camps: new features for browsers, and then how existing features should actually behave. The difficulties lie in that latter half — even small details like whether quoteblocks should assume quotemarks aren’t yet standardized in the spec, or in the world.

But it was a rephrasing a little later which really resonated with me:

TV Raman made a comment a number of times that we need to partition the idea of extensibility into two parts: extending the platform vs. extending the language. Those two words didn’t make much sense to me, but his examples did. Video and 2D graphics are things that need to be implemented by the browser vendors. And care needs to be taken that such features are defined in a way that they interact consistently with how other parts of the platform interact with other components such as CSS. Raman refers to these as platform features.

The second type of feature is one that does not need any support by browser vendors other than to simply to parse the unknown elements and attributes into a DOM, and to provide access to the DOM via JavaScript. RDFa comes to mind as such a feature, as does ubiquity-xforms. TV Raman refers to these as language features.

I like and endorse TV Raman’s split. Different burdens of proof and policies need to be applied to each type of feature.

He goes on to say that for new types of features to actually be usable by developers, “consensus by browser vendors is essential” — minority browser-vendors risk forking the Web; realworld adoption and practical deployment must be addressed. For language improvements, I think he wants to see better error-reporting to the user if some markup isn’t recognized.

But the part that struck me was how much of the current HTML5 discussion falls into two distinct sets: new “platform” features, and better handling of existing language features. For too long, runtime makers have added non-standard features, pushing the testing costs back onto content developers — the DHTML Feature Wars gave us a decade of web developers sweating out the differences. There’s a similar dynamic emerging today. But what serves the needs of vendors does not necessarily serve the needs of developers.

In reading some of the spin-off essays, I was particularly struck by this passage, from Rob Sayre of Mozilla:

“I don’t see a problem with HTML5 and XHTML2 continuing their separate ways. I do see a problem with some features being made part of HTML. Examples include a laughably underspecified SQL syntax, a video element that isn’t interoperable, and an RDF syntax that uses namespaces in text/html and QNames in content. Maybe we can all agree that those examples don’t belong in the HTML specification at this point. But then the problem shifts to one of endorsement. People want the HTML specification to tell them what they’re doing is OK. I don’t think the HTML document should do that either.”

That last point is key — if the VIDEO tag doesn’t actually serve content developers, then who does it serve, to warrant such attention? The most reasonable hypothesis is that the standards process is being used to “bless” the multimedia runtimes browser vendors want to create and control. We’ve seen it happen with the OOXML controversy, where standards bodies were used to bless a technology in the marketplace.

Endorsement of a browser vendor’s needs. That could explain why much of this is being pushed through, despite the apparent costs to content developers and their audiences.

I went through all the comments — painful reading, but I’m glad I did, because it revealed this little section of different perspectives from those seeking HTML runtime adoption, and those with a more pragmatic perspective:

Brad Neuberg of Dojo expresses the “HTML5 must have shiny features” position:

“If we follow Rob’s disassembly of HTML 5, there won’t be anything there to actually drive adoption. Sam, you suggest that his version has well-defined error semantics…. that didn’t work too well for XHTML though to drive adoption. We need a real-world standard with compelling features to keep up with Silverlight, AIR, etc., not an academic document that simply cleans things up. Unfortunately that’s not enough.”

Karl Dubost of W3C, in reply:

“This is a noble goal, but it really looks like a Geek Wet Dream. There are awesome things done with Canvas, but the thing that the hardcore geeks of html5 tend to forget that it is still far beyond what the Flash or Adobe Air platform propose. I’m not advocating for them. I really wish it was different. You can definitely say that canvas is a baby step for making an application platform to compete with adobe air in 15 years indeed. (Though don’t forget the competition will advance.) But selling canvas and some of the features of html 5 as a competitive technology with regards to the others make us (people in the HTML 5 WG) ridiculous.”

Brad seems to like Flash and AIR, but it’s not clear why he wants to force all browsers to try to duplicate such functionality. If vendors are still arguing over how simpler text features “should” work, then that seems a more pressing problem to solve.

Put down the Flavorade and slowly back away….

Tristan Nitot, the speaker from Mozilla/Europe who had last year’s “Beware Flash’s hidden agenda” bit of never-corrected scare-mongering, praises a new example of simple graphic writing into a video buffer via CANVAS tag in unreleased Firefox.

If you’re happy with that example, then I’m happy. New technical options are always good.

But some of the text in that essay is weird. And while there are comments published there, I’m not seeing a comment-box in my version of Firefox 3.08, and Mozilla evangelists have a history of not recognizing inconvenient questions. So I’ll copy his lede here and then list through some of the problems it exhibits.

Making video a first class citizen of the Web

For years, digital video has been soaring, just like still digital images 15 years earlier. It’s now easy to capture video, editing it is now possible thanks to user-friendly applications and with broadband becoming more common, the pipes are now big enough to download video. The only caveat is that Web browsers have not evolved over time to include video, because the dominant browser vendor had little reason to invest in it. Proprietary plug-ins such as Flash, QuickTime or Windows Media have been until now the only way for Web developers to include video in their Web application. Unfortunately, resorting to proprietary plug-ins and patented codecs has drawbacks. I won’t get into the patent and proprietary code issues and focus on the fact that resorting to plug-ins for video brings some limitations to what one can do. Plug-ins are like boxy islands of information on a page. They can do wonders by themselves, but they have a hard time being mixed with the rest of the Web content. It’s hard for example to interact with a Flash video, unless you write the complete page in Flash. But all of this is now over, since Firefox 3.5 and other modern browsers support native video using the new element. Now, a native video is just an element in a page that you can manipulate with the DOM, style with CSS etc.

You can “make video a first class citizen of the browsers” by removing the barriers browsers impose to communicating with and using neutral cross-browser renderers. It’s “boxy” ’cause browsers still only offer the (slowly-improving) WMODE for better visual integration.

We still need you to fix the browser focus issues so people can tab easily throughout any element in the page. We need you to expose “Open in New Tab” functionality in the browser so plugins can ferry those instructions. We need you to expose a preference-setting mechanism so that Flash knows when the browser wants to stop cookies. We need your JavaScript to distinguish user-initiated events from programmatic events. And there’s never been a need to “write the complete page in Flash” — if it’s slow for your JavaScript to control video rendered by Flash, then fix the JavaScript/plugin bridges.

You can “make video a first-class citizen” with a whole lot less effort than you’re currently expending. Use what works, instead of trying to personally reinvent what already exists.

Just fix the browsers’ current integration problems with predictable third-party rendering. Having each browser vendor make their private re-implementations of proven technology is a dog’s way to go.

I don’t appreciate how Tristan avers menacingly to “proprietary plugins” and “patented codecs” without ever making a strong, sensible case. It’s fear-mongering. It’s unnecessary. Beneath his rap is the assumption “Ogg Theora (aka On2 VP3) will solve all needs”, and that blanket assertion still needs a strong defense. You can’t say “patented codecs are bad” without addressing why the world prefers modern codec technology. It’s religious gaming, not technical discussion.

There’s one other part of this that I find intellectually objectionable:

It’s built with native Open Web technologies: JavaScript + DOM, CSS and HTML 5 (canvas and video) that hundreds of thousand people are already familiar with.

There is no HTML5. It is only as real as ECMAScript 4 was. Both were proposals. Neither were ratified as academic de jure standards, much less graduated into becoming realworld de facto standards. To bill this phantasm as a concrete advantage is rank used-car salesmanship. I’m using the current release version of the browser that pays Tristan’s rent, and it only renders the de facto standard video format, not his potential de jure format. It ain’t “open” if it ain’t accessible.

The thing that bothers me most about this type of “Open Web” evangelism: it asserts polarities without ever defending those assumptions. It’s go-along-with-the-crowd sheepism. We humans do best when we realize what we share in common, and examine the individual facts which make up a case. But that “choose up sides and fight the other team” stuff is primitive, unhuman, and has got to go.

I’m glad you enjoy realtime video manipulation. I’m not glad that you assume only your own branding is acceptable.

Tristan Nitot, I’m calling on you to stop putting additional barriers in front of fresh browser makers. I’m calling on you to make it easier — not harder! — to enjoy HTML on new and smaller devices. Keep hypertext hypertext, and create some other spec for RIA engines; don’t pollute the two together. Use the technology that works, and drop your not-invented-here provincialism. Stop mysteriously asserting dangers from Flash… if you’ve got a concern, spit it out, and we can work on it together.

Open up the Open Web, and stop advertising how Closed it can be.

(And oh yeah, for “try doing view-source with a Flash applet”, try doing a web search on “view source flash”. It’s been years….)

Update: Tristan Nitot of Mozilla did follow up a bit, in a comment at Denver Gingerich’s OSSGuy blog: “I hadn’t see JD’s post, otherwise I would have answered myself (not sure if he would listen though, because it’s always harder for a man to understand something when he’s paid not to).” He didn’t address the issue, just made further aspersions, and didn’t back those up when challenged. That’s not admirable behavior.