HTML5: Well, Maybe.

I just finished reading an article about Roger McNamee’s bold predictions about social media.  Aside from some the interesting business predictions (e.g., don’t invest in new social media startups: that train has left the station) that I mostly agree with, he is strongly emphasizing the emergence of HTML5 as the technology that will drive application development in the future.  On this point, I’m not ready to throw my FlexBuilder, Visual Studio, Eclipse and Android SDK development environments in the dust bin just yet.  Forget about scrapping my Notepad++ or Oxygen environments, these are keepers for the long, long term.

Yeah, HTML5 definitely has much promise:  Canvas alone is just cool.  I’ve seen some really interesting things done with this, and it can only get better from there.  Yet one cool enhancement for a browser isn’t enough to keep my attention long term, nor is it a game-changer that will revolutionize how users interact with application interfaces. 

So what kinds of things will keep me saying, “you had me at hello.”?   The big deal for me is looking at the world through the publishing industry’s collective eye:  Many of the big publishers are in the midst of what can considered a paradigmatic shift – while print will still be a prominent part of their business model, it won’t be the dominant model.  This is a significant change.  Publishers will transform themselves from content designers to media conduits. 

OK, so how what will HTML5 need to have to be compelling for publishers to adopt it?  I see three things, all of which are requirements for the browser vendors to reconcile:

1. Media Codec Standardization
2. Support other key technical standards (EPUB, MathML, etc.)
3. Form-factor scaling

Media Codec Standardization

Right now, there are myriad of audio and video standards like H.264, Ogg (Theora for audio; Vorbis for video), MP3, Speex, AAC, WAV, and so on and on and on.  The problem is that none of the current browsers support a common set of these, and even when they do support them, their support varies.  Until they figure that out, HTML5 will not be able to leverage its full capability and publishers will be reluctant to adopt it.

References:  http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5_Media);

Native Support for other Standards

OK, this one is a big, huge stretch and probably not going to happen anytime really soon.  Well, OK.  Ever. That said, these are the types of challenges that publishers have to face currently as well as going forward.  EPUB is the biggest stretch only because it leverages HTML (and ZIP compression) anyway, but the capability to embed EPUB in an HTML container would be a big win.  Yet for technical publishers, i.e., engineering, science and math publishers,  there hasn’t been a good solution for displaying all manner of math equations in browsers – they’ve had to rely on either transforming the equation to a raster image (and only recently to vector images like SVG) or rely on plugins to render the equation.  More recently, we’ve seen developments like MathJAX (http://mathjax.org) that rely on Javascript libraries to consume LaTeX scripts and display equations.  A bit better, but not quite as elegant as leveraging structural markup. 

The bottom line is that this requirement is probably more of a “nice to have,” but for STM publishers, its key to their business. 

Form Factor

This is probably the most significant limitation today.  It would be one thing if all applications/browsers were bound to desktops and laptops.  The reality is that mobile devices, all of which have different dimensions ranging from relatively small smart phones to now tablets means that application interfaces have added challenges to support these different form factors.  Today, I would be hard-pressed to recommend HTML5 UI libraries over native mobile OS UI controls. 

The Future

Will HTML5 become the preeminent technology platform? My magic 8-ball on my smart phone says “Ask again later…”  This resonates the same for me.  I’m hopeful that HTML5 can live up to the promise and can become the common technology platform for all applications.  But right now, there’s just too many holes in the various browser engines to make it practical.  Don’t expect browser vendors to patch these holes quickly.  In the meantime, several factors will impede HTML5 adoption:  Flash, warts and all, is still largely ubiquitous.  Its influence is slowly diminishing, but it won’t go away anytime soon.  In addition, Javascript libraries like JQuery, YUI and Dojo are maturing, but I think we’ll need to see how they shake out over time.  I’ll defer to Javascript experts to tell me which of these will become integral for HTML5 applications.

Lastly, HTML5 won’t be promoted to true standard status for another 10 – 11 years.  This is a lifetime, almost an epoch, for technology.  Lots can happen in that time.  It’s hard to predict right now what emerging technologies will come along that will impact content and media, but chances are something will.

Update (7/23/2011 05:08 PM MST):  Even more articles are coming out suggesting HTML5 will be a boom industry (see http://gigaom.com/2011/07/22/the-html5-boom-is-coming-fast/):  Could be real, but could be a bubble.  I’m not convinced yet that browsers are up to the task – yet.

I Don't Care How the Sausage Is Made

There's a common notion that you don't want to know how sausage is made if you like eating them. In fact, there's a butcher (reminiscent of days gone by) down the street from where I live who makes all kinds of sausage from "old family recipes". What I read into this sort of thing is the butcher is saying, "Don't ask, I'm not telling." To which my reply would be, "I won't, because it tastes good."

In much the same fashion as I don't want to know what goes into the sausage, many writers I've had the experience of working with or consulting for really don't want to know or care about angle brackets, tags, attributes, containment, content models, namespaces, DTDs, schemas or processing instructions. In other words, "Let me write, and get out of my way!"

Part of this sturm und drang over markup languages is partly the unintended consequences of sophisticated desktop publishing tools that enable virtually anyone to create publication-ready content. The problem is that structure and semantics takes a back seat to formatting and presentation. And for the last 15-plus years, DTP applications have been the main tool in the writing tool chest. It didn't matter that the underlying format was proprietary - it just worked.

But the price of "freedom" with using these tools resulted in additional overhead to ensure that "publication-ready" content conformed to internal company standards for style and format.So here comes XML, with its promise of unlocking content from format and proprietary binary formats read only by proprietary applications. Structure and semantics now matter. In so many ways, this is a great thing. Consistency can be enforced by the underlying schema - no rogue "Heading 1" styles followed by a "Heading 3" or funky new format styles that deviate from the corporate template. Better yet, no more tedious hours reformatting content from other sources like OEM content, or being limited to "one-off" copies from originals.

The rub is that the tools needed to write XML put more onus on the writer to understand the content model. Even if these tools hide or abstract the content model, there is still a significant change management issue to train users that structured content authoring is signficantly different than what they might be used to. In exchange for "creative freedom," back-end publishing systems now have a reliable content to work with. But the problem is that some folks creating the content feel like they've gotten the short end of the stick. For those that do feel short shrifted, it feels like they're right in the middle of the sausage factory.

The real challenge is to develop tools that make XML content creation simple. Users don't want to know a hyperlink or image is marked up, they simply want to identify the URL and link text. Similarly, some users don't care if the content model is using a CALS or OASIS Exchange or HTML table model, they want to insert rows and cells. In many respects, this seems to suggest that the current markup complexity is getting in the way.

Many of the tools do have WYSIWYG-ish views into the content. Yet, as Eric Armstrong pointed out, even these tools fall short and tend to confuse users when they want to insert a particular element or structure not allowed in the context of the current cursor location.In many regards, this is too much overhead for the average user. They want to have a tool that allows them to insert paragraphs, lists, tables, images and section headings. One suggestion might have a higher level abstraction layer that all tools can easily support, and build the more complex XML markup under the covers.

One possible approach might be to use HTML-like WYSIWYG editors that support basic content structures. Under the covers, it can convert the HTML into more complex structures required by grammars like DocBook and DITA. In fact, the Interoperability Framework Scott Hudson and I have worked on uses this same approach.

While this type of approach takes away some control over very specific semantics, it reduces the complexity and clutter that more structured models introduce. That doesn't preclude editing tools to be smarter about how they enable more specific semantics. Much in the same way many HTML editors display a popup dialog for users to specify the URL and text for a hyperlink, tools can provide users with other dialogs for specifying (more like classifying) an abstract span element to indicate more detailed meaning.

This is not to suggest that "non-narrative" content, like data structures or configurations that are are used by many modern applications will want to use this approach. However, publication level markup can take advantage of this type of approach to simplify how users create content, and honor their request to remain unaware of how the sausage is made and will be happier to create content in a model they do understand.