Subscribe

I beg to differ, HTML5 is ready for Digital Signage

October 12th, 2010 by Byron Darlison

11 Comments

Last week the web was alive with “W3C Says HTML5 Isn’t Ready for the Web“. All of which I thought was interesting but ignored as I just didn’t see how it was relative to our digital signage world. Then Dave Haynes picked it up over at SixteenNine “HTML Ain’t Ready Just Yet” and I realized I needed to give this some more thought.

I think this premise – HTML5 not ready – is wrong for digital signage and here’s why.

The W3C representative who was quoted said it wasn’t ready due to interoperability issues and lack of a video standard. Which to me means it doesn’t always run the same on all browsers and in some cases won’t run at all and you’re not guaranteed that the person viewing your video will have the codec to actually see it. The implied and not so implied alternative is Flash and Silverlight. Some articles went on to say that all browsers should be fully supporting the final standard within a year.

So let’s break this down:

  • Right now, with just plain HTML, web content doesn’t always appear the same or always work on all browsers and I am not guaranteed to be able to see your video if you use a codec I don’t have. I repeat – this situation exists now and I would argue is worse than the HTML5 standard in some cases.
  • Flash has licensing risks and continuously has memory leak and performance issues. Flash is one of our major sources of support problems with our uses.
  • Silverlight, albeit interesting, IMHO is never going to go anywhere, it is trying to gain traction against Flash and HTML5 in an already crowded space. I spent six months investing heavily in it before I canned it for just this reason, so I don’t say this lightly.
  • A year is a very short period of time. Do you build for what is behind you, or do you build for what is coming?

Digital signage is typically a closed loop. By this I mean I can control / recommend what is used to create and edit content and I can by design implement what is going to play that content. In our case we recommend Chrome or Chromium when using our editor and our player is Chromium. I said “digital signage” is a closed loop with some trepidation. I feel this is one of the biggest problems digital signage faces and it should be an open, cross platform, cross purposed solution, running on digital signage, the web and mobile devices, if I have my way, so I fully admit the current situation isn’t ideal. However, interoperability and video issues exist right now, there are big risks / costs with Flash and Silverlight isn’t going anywhere, and I don’t know about you but I prefer to invest in something with a future, not spend money on what is behind me, so for all of these reasons I personally have bought into the HTML5 kool aid.

How about you?

Click here to sign up for our free digital signage web service.
(seriously, FREE, GRATIS, NADA, and it doesn't expire, really)
  • http://twitter.com/IAdea DigitalSignage@IAdea

    Over the past years, we have always had projects where the integrator thought about using HTML as the playback description language. Over time, none of these matured into any real deployment. I think there are several reasons: HTML was largely designed as a static content format with embedded links. Digital signage often requires unambiguous specification of time, important for tasks like looping, day parting, billing, transitions, etc. These are commonly agreed as the required primitives for specifying digital signage needs. 

    Yes one can approximate these using JavaScript, which often goes hand-in-hand with HTML code. However JavaScript does not describe the high level semantics as a markup language does. A weekly schedule may be expressed in a dozen different ways depending on implementation. Communicating digital signage needs in HTML is in my opinion difficult if not impossible. 

    Other issues w/ HTML is that the content is specified for information, not presentation. There is no platform independent way to do a nice transition between screens, for example. 

    An alternative markup language may be SMIL which is getting good adoption by several digital signage industry players. It specializes in specifying time, media items, screens regions, animations, transitions, etc. A much better candidate IMHO. 

    • http://www.riseholdings.com/ Byron Darlison

      Hello IAdea and thanks for the feedback! I’m going to have to disagree with you about using HTML for digital signage because of timing and presentation restrictions, 5 years ago I would have agreed but not today. Now the degree of control and the visual results that can be achieved are without limit in my opinion and definitely not impossible to construct as we have already done it.

      But, let’s agree to disagree on this one as I would like to hear your opinion on convergence. My concern with SMIL is the lack of support for it in the browser and if the browser doesn’t support it I don’t see how one can easily cross purpose content across digital signage, the web and the mobile device. The world is racing to support the browser on every screen – the desktop, notebook, pad/slate, TV, mobile, car and IMHO digital signage. And with that much momentum behind the browser I am having problems grasping where SMIL can gain traction? Am I missing something?

      • http://twitter.com/IAdea DigitalSignage@IAdea

        I’d see HTML having its role in replacing Flash as a content format. However I think digital signage needs other mechanisms for managing the overall behavior on the screen, like scheduling, etc. True you can achieve the effect using JavaScript w/ HTML, but that’s like saying we should make C++ a digital signage standard because it can do everything.

        The good news is the both HTML and SMIL are XML-based, so they are meant to complement each other when needed.

        • http://www.riseholdings.com/ Byron Darlison

          Understood and to some extent I agree, but I think you missed my question on
          convergence? The world is converging on the browser but as far as I can tell
          the browser, or at least the major market share browsers, have not embraced
          and adopted SMIL as much as specific interest groups would like. Do you
          concur? And if you do, do you believe SMIL has a future without browser
          support fully behind it?

          Thanks!

          • http://twitter.com/IAdea DigitalSignage@IAdea

            Content format may be a small part of the scope in a digital signage operation and HTML is not sufficient to cover many important areas that are vital to the operation of a network. Having broad browser support alone may not make a successful digital signage technology or standard. I am not sure if browser support is the biggest issue today.

            POPAI’s Digital Standards Group once looked at HTML and rejected it early on precisely for the same reasons W3C is holding us back: the lack of consistency across implementations. In many cases, digital signage is even LESS tolerant than the web when it comes to presentation and formatting. Many digital signage clients will not tolerate if a line wraps unexpectedly and destroys the balance of the carefully crafted screen layout. Today this is likely to happen across browsers and operating systems.

            There could be casual uses of digital signage where this does not matter, and where broad browser support is more important than reliability and consistency. It’s just that today HTML does not seem to address the biggest concerns we have.

          • http://www.riseholdings.com/ Byron Darlison

            Thanks for the input. Most appreciated.

          • http://twitter.com/IAdea DigitalSignage@IAdea

            Byron I appreciate your openness for challenges. Do not be mistaken. What you are working on is noble and I admire you for every bit of it. I just hope to provide a data point from the other side. Hopefully this will help your team make a even stronger offering for the industry.

          • http://www.riseholdings.com/ Byron Darlison

            Thanks. I appreciate that and you taking the time for the dialogue. Cheers

          • http://twitter.com/virtualCableTV virtualCable TV

            I agree with IAdea (hello Rex) –however– SMIL like SVG was virtually killed off back in the day by Microsoft and Autodesk both of who colluded together to destroy SVG and took SMIL down with it. We only see a smattering of support for SMIL in Silverlight for example and it is really only useful in hardware media players. There are reasons for how and why this happened and we have to go back, way back to the era of day one so to speak. Actually day two or three eh? ;-)

            Although I cannot provide a link or proof at this time I know for a fact that Autodesk paid W3C $10,000 to sit on SVG committee when it was first formed. Autodesk was only there to spy so they could determine how not to support SVG as they wanted to ensure their proprietary DWG file format remained the dominant commercialized vector graphic format. This is also why they keep DWF crippled.

            I was quite the CAD expert back in the mainframe +> minicomputer platform era and was affected by the rise of the Autodesk hegemony all of which was based on the DXF file format that was marketed as Drawing Exchange when AUtodesk need to play nice. Once they took control of the manufacturing and construction makets they turned into wife beaters so to speak.

            The last thing Autodesk wanted to see SVG make possible was a new era of CAD which SVG vector graphics once promised. Microsoft’s VML was as important to protect in the same way and for the same reasons as Autodesk’s DWG/DWF hegemony.

            Granted, both SVG and SMIL are not mature and both continue to have inherent problems with performance and other criteria but this I contend is only because they have been largely ignored by the vendors who control the brightest developers who could have done something about it.

            Hence, the only value proposition for SMIL remains in hardware media players which is good for IAdea but not so good when one considers that particular type of device is not needed anymore.

            Personally, I do not like the situation as it pertains to IAdea because the company is between the same rock and the hard place as Silverlight but for different reasons; Silverlight because Steve Ballmer is a failure and is destroying Microsoft and most everybody hates the company now more than ever and IAdea because software and hardware always obviate the need for one another at some point in time when one or the other provides the more efficient and less expensive value proposition than the other.

            At the moment as it pertains to signage, software and especially virtualization is obviating the need for hardware at each point of demarcation not to mention the era of all-in-one HDTV networking that is just starting to peek over the fence to let everybody know its going to kick some serious ass the same way the minicomputer kicked the mainframe out of town and was then kicked out of town by the microcomputer which is now being kicked out of town by mobile devices.

  • http://twitter.com/virtualCableTV virtualCable TV

    HTML5 is only perfect for signage in the same way SIlverlight is perfect for signage and that’s because what is deployed only has to be parsed by one user agent (i.e. one player); none of the FUBAR HTML parsing by various browsers is relevant, 2-3 versions of the app no longer have to be developed and all design patterns can remain unsullied by all of the incessant client-side dependencies like CSS and JavaScript and the many work-arounds required to “reach” the persons using various browsers.

    Let’s put it this way: HTML was designed as a page layout markup language and HTML remains a page layout markup language. HTML5 is now like a square peg trying to force-fit into a round hole by trying to turn itself into an application development framework. I suspect the latter point being why it is taking so long to become “finished” which all developers know is a ridiculous postulation. Silverlight on the other hand was designed as an application development framework that supports many types of page layout which in perspective is an important but never the less small part of the application framework itself.

    The only pragmatic comparison then is reach vs. richness.

    HTML5 can now reach many if not most devices while Silverlight cannot as Silverlight is not being allowed to run on devices other than IE running on Windows.

    However, that is only pertinent for those building –websites– that need to reach the broadest audience possible. This is not pertinent with signage as –reach– is dependent on hardware deployed at each point of demarcation using whatever user agent (browser) the signage developer has chosen to use. Hence, there is no logic as it pertains to software development per se that really supports your premise Byron –unless– you intend to become a web developer that is concerned on the fidelity of his web pages being as consistent on as many different devices and different browsers as possible.

    <%= Clinton Gallagher

    • http://www.riseholdings.com/ Byron Darlison

      Hey Clinton,

      First off, let me say “WOW”. I like your analysis in this comment and the other one you posted. Thank you!

      And with regards to this post. When you say “Byron –unless– you intend to become a web developer that is concerned on the fidelity of his web pages being as consistent on as many different devices and different browsers as possible.” you hit the nail on the head. I don’t believe that digital signage is a silo, a unique market offerring. I believe that it will converge with every other display end point – be it large format, personal, mobile, tablet, whatever. And the message needs to cross all. I prefer to think of what we do as providing the ability to deliver a message to a web end point, which by the way can be digital signage.

      Having said this, you have many valid points and there definitely won’t be one way to solve this need. Many different paths could all end up converging…

      Cheers,
      Byron