Re: Use case 1

I'd agree starting with the use cases first.

I am not sure if we had covered all these scenarios during our meeting:

- Very simple signage that just loops simple content (like a DVD
player). Useful for own-brand product/service promotion with short dwell
time
- Day-parted playlists for venues with scheduled events (e.g.,
restaurants, conference venues)
- Ad-based playlists requiring accurate timing (time is money!) and
billing reports. Users specify number of repeats per time range and
playlist is auto-generated based on the criteria
- Digital signage that caters to the need of sub-organizations by
providing access control over sub-playlists. Useful for large chain
stores and MNCs
- Digital signage for the purpose of creating in-venue atmosphere. Often
content here have no specific purpose (e.g., showing bubbling seawater
in a high-end apparel store). Auto shuffling may be needed to avoid
content repetition. Also applies to audio-only applications
- Interactive signage that allows external triggers. This category
covers emergency alerts

Please see if these can be incorporated into the current document. Thanks.

John C. Wang
IAdea: Digital Signage Media Appliances
http://www.IAdea.com
Skype: jcwang_tw

On 7/4/2012 9:32 AM, Futomi Hatano wrote:
> Hi all,
>
> On Tue, 03 Jul 2012 21:29:48 +0200
> "Chaals McCathieNevile" <w3b@chaals.com> wrote:
>
>> On Tue, 03 Jul 2012 21:05:38 +0200, Futomi Hatano  
>> <futomi.hatano@newphoria.co.jp> wrote:
>>
>> Hi all,
>>
>>> Thank you for your information, Chaals.
>>>
>>> Folks, I'd like to consider every possible way,and list all ways in the  
>>> document.
>>> http://www.html5.jp/Web-based-Signage/Scenarios-and-Use-Cases/#use-case-making-contents-using-a-declarative-approach
>> I don't think we should try to list every possible way - and when we ask  
>> the HTML, SVG and other groups there may be other ways we still didn't  
>> think of. It is still a good idea to list the possibilities we see.
> My expression could be bad.
> I have no thought to set a goal to list all solutions.
> I don't think that we should list solutions for every use cases.
> And I don't want to choose one of them as a decision as this group in the document.
> I mean the *possibilities* as you say.
> If we have some possibilities, we could see whether we need a requirement or not.
> I think that gathering our ideas won't be harmful.
> I believe that the effort will be useful.
>
> Probably, some members in this group already have practical ways or ideas.
> If they want to introduce their solutions, I don't want to deny it.
>
> Of course, I know that this doesn't have priority.
> We have to list use cases first of all.
>
> What do you think, folks?
> Shouldn't we list solutions (possibilities) you have in the document?
>
>
>> We need to make sure that we are looking at the requirements for the use  
>> case, before coming up with the solution. It is surprisingly tempting to  
>> come up with the solution first, and then extract requirements for that  
>> solution. (I think it is an inherent risk in the way engineers like to  
>> solve problems :) ).
> Unfortunately, I am not familiar with this topic.
> Does anyone have an opinion about this topic?
>
> Best regards,
> Futomi
>
>
>
>>> For now, there are three ways for Use case 1.
>>>
>>> * SMIL + new elements (proposed at the workshop)
>>> * SMIL in SVG (given by Chaals)
>>> * HTML5 data-* attributes + handling by JavaScript (my proposal)
>>>
>>> If you have any other ideas, please post your ideas.
>> A combination of timing based on SVG animation, <animate id="secondThing"  
>> begin="firstThing.end"...> (I have used this for normal sequences and it's  
>> easy, and I have done the parallel things by grouping), with javascript to  
>> handle cases like swapping resources in and out. Although a lot of this  
>> can already be done with normal SVG animation, actually.
>>
>> cheers
>>
>> Chaals
>>
>>> Best regards,
>>> Futomi
>>>
>>>
>>> On Tue, 03 Jul 2012 18:32:37 +0200
>>> "Charles McCathieNevile" <chaals@myopera.com> wrote:
>>>
>>>> An alternative approach being proposed, essentially bringing the rest of
>>>> SMIL into SVG. Don't know where the thread went but it is worth looking
>>>> at. (IMHO it would make more sense to just add the SMIL elements).
>>>>
>>>> http://www.w3.org/mid/4F4306B0.3080103@mozilla.com
>>>>
>>>> cheers
>>>>
>>>> Chaals
>>>>
>>>> --
>>>> Charles McCathie Nevile - private mail account
>>> --
>>> Newphoria Corporation
>>> Chief Technology Officer
>>> Futomi Hatano
>>> --
>>> futomi.hatano@newphoria.co.jp
>>> http://www.newphoria.co.jp/
>>>
>>>
>>
>> -- 
>> Chaals - standards declaimer

Received on Wednesday, 4 July 2012 02:34:42 UTC