Re: HTML Slidy remote - a Presentation API demo

On 2014-08-13 17:00, Kostiainen, Anssi wrote:
> Hi Francois, All,
>
> On 22 Jul 2014, at 13:25, Francois Daoust <fd@w3.org> wrote:
>
>> Hi Second Screen Presentation CG,
>>
>> In the interest of experimenting with the Presentation API, I updated the Presentation API JS shim that Dominik had created for the initial Presentation API demo to support:
>> 1. message passing as specified in the current report
>> 2. Chromecast devices through the Google Cast extension in Google Chrome
>>
>> I created an "HTML Slidy remote" demo that uses the shim and lets one project a presentation made with HTML Slidy onto a second screen and control it from the initial screen afterwards:
>>
>>   http://tidoust.github.io/slidyremote/
>>
>> For the source code, look at:
>>
>>   https://github.com/tidoust/slidyremote/
>
> Francois - it seems you’ve been doing some coding during the summer months :-) This is *excellent* work, thanks! Chromecast support works flawlessly with my setup (OS X, latest Chrome with the extensions installed).

Thanks, Anssi!


>
> We'll need to take your feedback from this experiment as it surely will help us iron out the rough edges in the API. This is what I call dogfooding :-)

The main difficulty for me was getting the order of events right to 
establish the communication channel.

The "present" event needs to be fired before the communication channel 
is established, otherwise the presentation page can easily miss the 
first few messages from the controlling page.

The code of the presentation page must also listen to the "present" 
event right away (as opposed to after some async operation, which could 
happen for instance if the code was to be put in a JS module loaded 
asynchronously with some module loader such as RequireJS), otherwise the 
"present" event could be missed.

The spec should clarify when the "present" event gets fired in the 
presentation page. No sooner than the tick that follows the "load" 
Window event? No sooner than the tick that follows the 
"DOMContentLoaded" event? Can implementations queue up the event up 
until it can be delivered? Or did I miss something? The "present" event 
is essential in the presentation page since it is the one that gives it 
the handler to the presentation session.

The other part that was not as straightforward to implement was handling 
reconnection to existing presentation sessions, be it only to cancel the 
previous session. That feature makes the life of the developer a bit 
harder but is really useful in the end, and I see Mark, Jonas, Anton, et 
al. have concrete proposals in that area.



>
>> The goal of this demo was to test the Presentation API with another type of remote screen and to try out a second screen scenario that did not involve videos.
>
> With your demo, we now have three experiments that demonstrate how the Presentation API can be used in a real world.
>
> Francois - is there an easy way to create a custom category similar to “Reports” on the CG page (http://www.w3.org/community/webscreens/) for “Demos”? I think it would be good to make these demos more visible on the group’s page:
>
> * HTML Slidy remote demo:
>
>    http://tidoust.github.io/slidyremote/
>
> * Experimental Chromium build and the initial video demo:
>
>    http://webscreens.github.io/demo/
>
> * requestShowMedia.js prollyfill and the <video> sharing demo:
>
>    http://webscreens.github.io/requestshowmedia/demo/

It's an excellent idea but there is no way to create a custom category 
on the CG page. The sections that appear on the home page are 
dynamically generated and cannot be customized.

The menu on the right can be customized but it's not as visible and it 
already contains link to other resources.


> Another thing that might be helpful would be to fork the production version of your slidyremote repo to the web screens GH org. You should now have the required privileges to do that.

Thanks! I'll do it. I started in my own repo simply because I did not 
know whether this would lead to anything.


> I think there would be value in keeping the demos under the same organization. Later on, if we evolve the other demos to use your shim, we might consider merging the demos into the same repo, while the shim could live in its own repo. For the time being the demos could stay in their own repos but under the same GH org.

Agreed. Dominik reported that my shim actually does not work with the 
custom Chromium build he prepared. We'll need to find out why before we 
can get down to one shim.

Thanks,
Francois

>
> Thanks,
>
> -Anssi
>

Received on Tuesday, 19 August 2014 16:42:58 UTC