- From: Sangwhan Moon <smoon@opera.com>
- Date: Tue, 25 Dec 2012 18:33:21 +0900
- To: public-websignage@w3.org
On 12/12/12 5:59 PM, Kai Hendry wrote: > On 12 December 2012 15:12, John C. Wang <John.Wang@iadea.com> wrote: >> Example of Web incompatibility: the first link you provided earlier >> https://play.renewchannel.com/ does not play in my IE9 browser, which is >> either the #1 or #2 browser on the Web today. I'd say HTML incompatibility >> is a widely recognized phenomenon. Many websites break when you try to run >> them from mobile browsers. > > Indeed it's a bad example, because Renew are pushing the envelope and > targeting only one browser and only one screen size. :( A bit like > what banks do with Internet Explorer. ;) > > I still think there is a lot of room for getting the basics right that > we could work on here. > > For example I was talking with a media agency today and hearing about > their problems when they purchase inventory from DOOH media owners. > The media owners often have to "convert" the media for their > proprietary systems in different awkward time-consuming ways. Their > media is usually pretty simple and I like to think a > scalable/responsive Web design can solve this problem far more > efficiently. Finding a way to minimize resolution/device dependency on the content is something that we _definitely_ need to provide a best practice for - as it is right now, most of the sign content I have seen is severely tied to a single screen resolution and/or software stack. [1] CSS device adaptation is something that we should consider for this, as most browsers have some form of functioning implementation that could be unified at a point the standard reaches CR. As a side question, which browser is this content designed for? I'd like to take a look but have failed to run it on every browser I have installed on my machine... (Opera 12, Chrome 13, Firefox 15, Safari 5) >> Regarding your comment that "most DOOH deployments use a USB stick" today, I >> do have some reservation. If that were the case, we run the danger of >> dreaming up a fake problem to solve here. Digital signage whose content >> needs to change once a month is more likely than not to run on a network >> today, and most of them already use HTTP as the transport. I'd argue they >> are already "web-based". > > I didn't see this coming. ;) Using the HTTP transport doesn't make it the Web. > > The Web is the HTML marked up information that's accessible from > robots and browsers across devices that exist in the Web ecosystem > today. There is probably a far better definition somewhere, but that's > the best I could come up with at short notice. Indeed. This could be arguably be translated as "This sign executes a Java2D powered application packed in a JAR file via HTTP hosted on a web server, hence it's web-based". The transport is probably the least relevant bit here. If HTML based signage content is hosted on a local filesystem and rsync'ed from a server for updates, that is still web-based, even if it's not displaying hosted content from the WWW. Regarding the "dreaming up a fake problem" bit, the use cases noted in the wiki list _does_ mostly cover actual use cases that are currently covered by native sign content players in some way or the other. The amount of functionality a average DOOH deployment provides in the western world and Asia have a vast difference, and some of more complex ones are quite Asia specific - so if there are use cases that do not make sense, please do ask the list for elaboration. Sangwhan [1] http://dev.w3.org/csswg/css-device-adapt/
Received on Tuesday, 25 December 2012 09:33:59 UTC