[FYI] Involving "Web-App-on-TV" developers

Hello IG members,

I'd like to share with you the status of one of my challenges to improve the Web standards for TV through involving "Web-App-on-TV" developers.


TL;DR: The browser-based test runner of the W3C Web Platform Testing [1] wasn't runnable on some types of TV-like devices. "Web-App-on-TV" developers in Japan has hacked and made it runnable on those devices. The developers have also started reviewing the TV Control API CG works and will send comments to the CG this March. They have reasonable motivation to spare their time to improve the interop of Web browsers on TV-like devices and testing for Web standards, and also have sufficient skill to contribute to it. I think it's good for us to have them, this new type of stakeholders, involved in W3C and the Web and TV activity not only in Japan but also in various regions.


After TPAC 2014 in Santa Clara, Taku from Fuji-mic [2], Fumitaka and Yusuke from Tomo-Digi, and I have collaboratively held a series of "Web-App-on-TV" developer casual meetups in Tokyo, where we had averagely twelve attendees from six top-level developers in this area and analyzed issues in their Web app development process on TV-like devices. The consensus there was that improving the interop of Web browsers on TV-like devices including temporal behaviours of animation apis and techniques was the highest priority to better their dev processes.

The W3C WPT had two test runners: WebDriver-based and browser-based. We decided to focus on the browser-based test runner for the time being. This was because you could run the browser-based runner on whatever TV-like device you bought at a retail store, while you couldn't run the WebDriver version without asking CE/TV manufactures to open the device's network port the WebDriver protocol needed. Moreover, we were not sure how many CE/TV manufactures were actually using the WebDriver modules which browser vendors were provided for test automation.

However, unfortunately, the browser-based runner wasn't runnable on some types of TV-like devices. The major showstoppers were:

* Some types of TV-like devices didn't allow creating a new top-level browsing context for security reasons.
* Some products had disabled some EcmaScript functions for security reasons, perhaps.
* The runner accumulated all the result of tests into a DOM tree, which eventually consumed all memory of a TV-like device when it ran many tests at once.
* The runner's UI was not compatible with the devices which have no mouse or touch interfaces.
* The runner expected that testers copy-and-pasted its test result from the browser's textarea to a text editor, which the TV-like devices didn't have.

So we've hacked the runner on these major and other minor issues and now its runnable on variety of TV-like devices. We are soon to send pull requests to the W3C Github repo.

Our next steps in this direction are:

* Polish the hack and send pull requests
* Submit issues we found which are likely to be related to standards or implementations onto the WPT repo's and/or WG's issue tracker(s)
* Involve more developers in Japan
* Communicate with developers in other regions
* Involve CE/TV manufactures to this activity
* Encourage CE/TV manufactures to install WPT into their development cycles and/or QA processes
* Share the results with other TV SDOs

Additionally, the developers are also interested in making their apps runnable on as many TV sets as possible in various regions, which is the source of motivation for them to dig into the TV Control API CG's works especially in the light of APIs needed for services related to broadcasting services: the broadcasting industry has some divergence there. They are now reviewing the CG's works with the regional broadcasting standards in some regions and willing to make comments from the developer's viewpoint. This might be good input for us to revisit the agendum: how we can achieve better interoperability over the divergence between region standards such as HbbTV 2.0 and Hybridcast 2.0 in the short term, and the mid or long term.

The main reason I chose the local casual meetup style to proceed this work thus far was the language barrier: the developers here in Japan have really good skill on the Web standard and technologies but most of them are not so good at English: they can read technical documents, but not skilled at listening, speaking, and writing. This would be an additional important topic for the AB's TF on 'Best practices to support multilingual W3C' [3].

We're planning to have the next meetup in Tokyo this March. I will share the result and lessons from the event here and would like to start, with you, thinking about if we can expand this activity to other regions.

Finally, I'd like to say thanks to some W3C colleagues here in Tokyo; The developers have had good supports from the team and Membership thus far: Mike Smith has helped the developer community understand what WPT is and the direction of W3C's testing effort, while, at the same time, providing detailed advices on how to merge their hack to the repo. Daniel Davis has encouraged them to contribute to W3C in the light of 'Focus on Developers', one of the important item in the W3C's direction [4]. Sangwhan Moon from Opera has provided thoughtful comments on their efforts from a browser vendor's viewpoint.

Regards,
Yosuke


[1] https://github.com/w3c/web-platform-tests
[2] https://lists.w3.org/Archives/Team/team-webandtv-chairs/2014Oct/0018.html
[3] https://www.w3.org/wiki/AB/2014-2015_Priorities/multilingual_W3C
[4] https://www.w3.org/2014/Talks/TPAC-Jeff/main/



—
Yosuke Funahashi
co-Chair, W3C Web and TV IG
Web Media Specialist, W3C
Project Associate Professor, Keio University

Received on Monday, 9 March 2015 11:13:16 UTC