• Print

Ubiquity and revenue streams: How HTML5 can help publishers

Google's Marcin Wichary brings HTML5 into perspective for publishers.

As technology makes the publishing space more and more geek-oriented, understanding how particular technologies can apply and how existing products or content can be adapted might seem to require a computer science degree.

In a recent interview, Google senior user experience designer Marcin Wichary brought one of those technologies — HTML5 — into perspective, explaining how it applies to publishers.

In design and layout, there’s a lot of things that HTML5 now does natively, without you having to hold its hand. Things like multimedia are native to HTML5 — you don’t need extensions or plug-ins; they’re integrated really well.

We have new devices like the iPad that require new input methods like multitouch or shaking the device. All of this is or will soon be supported by HTML5. So you can imagine delivering an experience through your application or your website or your publication that rivals that of a native application on any of the platforms you want to put it on.

On top of that, it’s the web. Al of the things that have been available on the web you also have as well. All the social networking, all the APIs, all the integration with other surfaces — you can just plug it in the way you want.

Wichary also explained how publishers can monetize the opportunities HTML5 brings to the table, and how it might even save money in the long run.

It’s very important to recognize that HTML5 fits all the devices you can think of, from the iPhone in your pocket to Google TV to the tablets to small screens and big screens. It’s very easy to take the content you already have and through the “magic” of HTML5, refine it so it works very well within a given context. You don’t have to do your work over and over again. Of course, all of these different means come with different monetization opportunities, like ads on the web or on mobile devices.

In the interview, Wichary also addressed how publishing workflows might be affected by HTML5 implementation and he outlined specific advantages HTML5 can bring to digital reading. The full interview is available in the following video:


tags: , , , ,

Comments: 4

  1. Thought provoking post….but I think your opening paragraph is headed the opposite direction. My personal take would be:

    As cloud computing and RESTful APIs continue to simply information technology (IT), understanding how particular technologies can apply and how existing products or content can be adapted can be approached by virtually anyone in the publishing space.

    HTMl5 and APIs are definitely heavily influencing publishing, but with quality SaaS implementations, widgets, embeds, API explorers, and more, technology implementation is less about having a CS degree and more about people being problem solvers and innovating….with existing tools / standards.

    Thanks for the post….people in publishing needs to keep hearing this, but they need to know its not rocket surgery.

  2. That’s a nice story to tell, but the reality is quite different. Many of the HTML5 demos I’ve seen online only work in a particular browser or particular device. HTML5 bring some great improvements to the browser, but often has to be redone over and over again. iOS’s Canvas implementation is really slow, so you need to do SVG and CSS3 transitions. However, that doesn’t run smoothly on Android, so you need to make a separate Canvas version for Android.

    Why can’t HTML5 advocates be more realistic about HTML5 and it’s capabilities rather than hyping it up as “magic”.

  3. Typically the “HTML5 advocates” are not the ones in the midsize to small developer trenches where the rubber hits the road having to make delivery schedules. They tend to be consultants or “strategic analysts.” They get paid for their ideas/opinions and not for a real deliverable. Google might be able to afford devs to produce for the various “gotchas” or mobile browser differences but I can’t. I need a platform that targets all the devices and allows for one codebase without a slew of if/else’s. HTML5 is not even close to doing that yet, in the future maybe but not now.

  4. I agree 100% with Matthew and especially Ethan.

    There was a ridiculously over-the-top cover page story about HTML5 in the December issue of MIT technology review, which made HTML5 sound like the mother of all silver bullets and prompted me to immediately write a letter to the editor.

    Also, seems to me that HTML5 needs to support DRM before publishers will really take it seriously, especially in the video space.

    I know we tech guys all hate DRM, but we don’t get any professional content without it, and that’s what most users want anyway.