회신: Re[2]: Our next step: Web-based Signage Player Requirements

Hi Futomi,

Good. It works well in chrome, safari PC browser, but not in IE8 browser (due to not support HTML5 yet ).
For IE8 :
<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script<http://html5shiv.googlecode.com/svn/trunk/html5.js%22%3E%3C/script>>
<![endif]-->

BR,
Sunghan
________________________________
보낸 사람 : "Futomi Hatano" <futomi.hatano@newphoria.co.jp>
보낸 날짜 : 2013-04-16 23:34:11 ( +09:00 )
받는 사람 : 김성한 <sh-kim@etri.re.kr>
참조 : public-websignage@w3.org <public-websignage@w3.org>
제목 : Re[2]: Our next step: Web-based Signage Player Requirements


Hi Sunghan,

Thanks for your quick response.

> IMHO, the profiles are already implemented or future plan?

I've tried to develop a very simple demo.
If you have time, try my demo.
http://www.html5.jp/Web-based-Signage/wbs_simple_demo/index.html

A part of the basic profile and media profile have been
implemented in my demo.
It adopts declarative approach.
All contents are marked up in the HTML.
The playlist data also is marked up in the HTML (data-* attributes).
http://www.w3.org/community/websignage/wiki/Web-based_Signage_Use_cases_and_Requirements#HTML


But I'm not sure the approach is best.
I don't like the architecture which the demo adopts for now.
So, I want to scrap and build the demo.
Personally, I think JSON is better for playlist for now.
And the iframe element is better for rendering each ad.
> And, is it possible executable on any browers over client devices, e.g pc,tab,....mobile.

Yes.
My demo works well in any devices as far as I've tried.
But all functions don't work in all devices.
Video and audio can be played in only PC.
I've tried PC, iOS 5.0+, Android 4.0+, some TV browser, Wii U, etc.
Regarding TV browser, I've tried two TV models which are sold in Japan.

* TOSHIBA REGZA Z742
* Panasonic VIERA TH-L42E60

I think both of the two adopt a webkit-based browser.
I'm interested in using TV browser for web-based signage personally.


> The profiles are all necessary for working on terminal side ?

Not all, but the basic profile should be implemented in terminal side.
So, we need to discuss which functions should be put in the basic profile.
As necessary, you can choose other profiles case by case.
I split the requirements into some profiles so that we can do so.

> player terminology is essential ? why use it?

Not essential. No reason.
For now, I'm not sure "Player" is best.
Do you come up with lovely term?

> regarding title , your suggestion seems that it is already next standard status
> after requirement stage. For the profiles description are usually followed after
> requirement step.
>
> Anyway, in my understanding for your context, profile is better rather requirement.
> so, Profiles for web-based signage ? or ..

Sounds lovely!

Cheers,
Futomi


On Tue, 16 Apr 2013 13:21:54 +0000
김성한 wrote:

> Hi Futomi,
>
> It is very interesting, practical approach of your js implementation to provide signage service.
>
> IMHO, the profiles are already implemented or future plan?
> And, is it possible executable on any browers over client devices, e.g pc,tab,....mobile.
> The profiles are all necessary for working on terminal side ?
> player terminology is essential ? why use it?
>
> regarding title , your suggestion seems that it is already next standard status after requirement stage. For the profiles description are usually followed after requirement step.
>
> Anyway, in my understanding for your context, profile is better rather requirement.
> so, Profiles for web-based signage ? or ..
>
> Execellent.
>
> br,
> sunghan
>
>
> 2013. 4. 16. ?�� 6:32 "Futomi Hatano" ����:
>
>
> Hi all,
>
> How's it going?
> I'm sorry for not contributing to the activity for a long time.
> I've been too busy this year, but still now...
>
> As you know, we decided to make "best practices" [1] before.
> Though I have been thinking how we should make it,
> I couldn't come up with a good idea.
>
> I think "best practices" is too vague at current our situation.
> When I started to make a js library for web-based signage,
> I realized that we don't have concrete and precise requirements for it.
>
> We've already had the requirements [2] and I believe it is valuable still now.
> But it is too rough and a little bit too future-oriented to make "best practices".
>
> I think we need to discuss more concrete and precise requirements.
> Besides, we need to limit the scope to some extent.
> It should be realistic and practical at the present moment.
> So I'd like to limit the scope to existing simple signs at first.
>
> I'd like to propose my idea for our next step.
> That is "Web-based Signage Player Requirements".
> My idea is ...
>
> [[
> Web-based Signage Player Requirements
>
> The "Web-based Signage Player Requirements" defines precise requirements for web-based signage players. Basically, a web-based signage player means a set of web runtime and javascript libraries. A web runtime means a common web browser (webkit-based browsers, Firefox, IE, etc.) or web-based app runtime (Firefox OS, Tizen, Windows 8, etc.) installed in tablets, PCs (connecting to a display), STBs, TV (most of current high-end TV products have a web-browser), etc.
> Basically, "web" in this context represents HTML5 (http://www.w3.org/TR/html5/) and CSS and JavaScript. The requirements for hardware of terminals are out of scope.
> The requirements also include recommended web APIs for each requirement (a kind of best practice) if needed.
> The requirements are separated into some profiles.
>
> * Basic Profile
>
> This profile is required for web-based signage players. Basically, it defines just requisite minimum. But it covers most of existing simple signs which show only a still image or a still html document for each ad. No video, no audio.
> It includes some items as blow.
>
> - playlist and scheduling
> - screen layout (multi-frame)
> - ticker
> - ad transition
> - updating whole playlist
> - updating each ad content separately
>
> The "ad transition" defines the transition effects between ads. For example, fade-in, fade-out, cross-fade, translate (left to right, etc.),
>
> The other requirements which aren't included in this profile will defines other profiles or extensions.
>
> * Basic Media Profile
>
> This Profile defines requirements for playing videos and audios which are downloaded from web servers or which are pre-fetched and stored in terminals.
> Protecting media data and streaming are out of scope. When we need them, we will make an profile as an extension.
>
> * Pre-fetch/Offline Profile
>
> This profile defines requirements for a offline situation, which are the way to pre-fetch all contents and store them, and the way to continue to play ads when the network is in trouble.
>
> * Basic Reporting Profile
>
> This profile defines what type of information should be stored in terminals, and uploaded to log servers (for example, the time when an ad started to be shown).
> This profile defines just requisite minimum. When we need more information as reporting, we will make an profile as an extension.
> ]]
>
> How do you think?
> I'd like to hear your thoughts.
> I welcome any comments.
>
> The naming is just my idea.
> I'm not sure it is best naming.
> If you come up with more lovely naming, let me know.
>
> When we agree with the idea, I'll publish above statements on the wiki.
>
> Thanks for your time.
>
> Cheers,
> Futomi
>
> [1] http://www.w3.org/community/websignage/wiki/Main_Page#Web-based_Signage_Best_Practices

> [2] http://www.w3.org/community/websignage/wiki/Web-based_Signage_Use_cases_and_Requirements

>
> --
> Newphoria Corporation
> Chief Technology Officer
> Futomi Hatano
> --
> futomi.hatano@newphoria.co.jp
> http://www.newphoria.co.jp/

>
>

--
Newphoria Corporation
Chief Technology Officer
Futomi Hatano
--
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/