W3C home > Mailing lists > Public > public-websignage@w3.org > December 2012


From: Sangwhan Moon <smoon@opera.com>
Date: Tue, 25 Dec 2012 18:33:21 +0900
Message-ID: <50D972E1.1060509@opera.com>
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.


[1] http://dev.w3.org/csswg/css-device-adapt/
Received on Tuesday, 25 December 2012 09:33:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:23:26 UTC