https://www.w3.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=HoschkaW3C Wiki - User contributions [en]2024-03-29T02:38:11ZUser contributionsMediaWiki 1.41.0https://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=81337Application Foundations/DeviceInteraction2015-02-11T21:28:17Z<p>Hoschka: /* Description */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
"Closely related to the Core Foundation is the Device Interaction Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to give access to all of the features offered by supporting devices. For mobile phones, <br />
APIs exist or are in development for access to camera, microphone, orientation, GPS, vibration, ambient light, pointer lock, screen orientation, battery status, touch events, bluetooth, NFC, and more.<br />
<br />
The next generation of Web attached devices will introduce new challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and [http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API design."<br />
<br />
== Next Steps ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
https://www.w3.org/2015/01/16-appfound-minutes.html<br />
<br />
"I'd like to get as broad an involvement from the public as possible"<br />
<br />
" we should be calling on the AB, Membership and public for help<br />
... we could put this on the agenda<br />
... of the AB<br />
... to keep them up-to-date"<br />
<br />
" we get to a point where we want to create a conference or workshop<br />
... there is an extensible web summit in April<br />
... could be presented there<br />
... or we can attach an app foundation summit and do something there"<br />
<br />
"public survey, good idea,"<br />
<br />
== Workplan ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
With that timeframe, focus should probably be on mobile.<br />
<br />
* Feb 15: Finalize list of relevant specs (for mobile, auto, wearables, personal medical equipment, home energy management, IoT)<br />
* Feb 28: First conversation with mobile developer scheduled (target: 5)<br />
* Mar 15: First draft of mobile gap analysis (including analysis of relevant literature/analyst reports etc.)<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts<br />
<br />
@@ All below is Foddder, please ignore<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* Second screen API<br />
* @@ to finalize<br />
<br />
== @@ Following is Fodder, please ignore ==<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
@@ dev outreach on sysapps, DAP, mobile IG - make that fit with HTML5Apps reviewer comments<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80682Application Foundations/DeviceInteraction2015-01-27T11:41:22Z<p>Hoschka: </p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to give access to all of the features offered by supporting devices. For mobile phones, <br />
APIs exist or are in development for access to camera, microphone, orientation, GPS, vibration, ambient light, pointer lock, screen orientation, battery status, touch events, bluetooth, NFC, and more.<br />
<br />
The next generation of Web attached devices will introduce new challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and [http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API design.<br />
<br />
== Next Steps ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
https://www.w3.org/2015/01/16-appfound-minutes.html<br />
<br />
"I'd like to get as broad an involvement from the public as possible"<br />
<br />
" we should be calling on the AB, Membership and public for help<br />
... we could put this on the agenda<br />
... of the AB<br />
... to keep them up-to-date"<br />
<br />
" we get to a point where we want to create a conference or workshop<br />
... there is an extensible web summit in April<br />
... could be presented there<br />
... or we can attach an app foundation summit and do something there"<br />
<br />
"public survey, good idea,"<br />
<br />
== Workplan ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
With that timeframe, focus should probably be on mobile.<br />
<br />
* Feb 15: Finalize list of relevant specs (for mobile, auto, wearables, personal medical equipment, home energy management, IoT)<br />
* Feb 28: First conversation with mobile developer scheduled (target: 5)<br />
* Mar 15: First draft of mobile gap analysis (including analysis of relevant literature/analyst reports etc.)<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts<br />
<br />
@@ All below is Foddder, please ignore<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* Second screen API<br />
* @@ to finalize<br />
<br />
== @@ Following is Fodder, please ignore ==<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
@@ dev outreach on sysapps, DAP, mobile IG - make that fit with HTML5Apps reviewer comments<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations&diff=80680Application Foundations2015-01-27T11:13:57Z<p>Hoschka: /* Team Coordinators */</p>
<hr />
<div>This is a public wiki for the community to share ideas for organizing and communicating [http://www.w3.org/appfoundations/ W3C's Application Foundations].<br />
<br />
== Resources ==<br />
<br />
* [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ Jeff Jaffe blog post] introducing Application Foundations on 2014-10-14<br />
* [https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_most_important#Core_task_force AB Most Important Priorities TF]<br />
<br />
=== Team Coordinators ===<br />
* [https://www.w3.org/wiki/Application_Foundations/SecurityPrivacy Security and Privacy]: Wendy<br />
* [https://www.w3.org/wiki/Application_Foundations/CoreDesignAndDev Core Web Design and Development]: Chris, Mike, PLH<br />
* [https://www.w3.org/wiki/Application_Foundations/DeviceInteraction Device Interaction]: Philipp, Dave, Dom<br />
* [https://www.w3.org/wiki/Application_Foundations/ApplicationLifecycle Application Lifecycle]: Dom, Mike, Xiaoqian<br />
* [https://www.w3.org/wiki/Application_Foundations/MediaRTC Media and Real-Time Communications]: Dom, Yves, PLH<br />
* [https://www.w3.org/wiki/Application_Foundations/PerformanceAndTuning Performance and Tuning]: PLH, Xiaoqian, Mike<br />
* [https://www.w3.org/wiki/Application_Foundations/UsabilityAndAccessibility Usability and Accessibility]: Richard, Bert, Judy<br />
* [https://www.w3.org/wiki/Application_Foundations/Services Services]: Felix, Doug, Wendy<br />
<br />
* [https://www.w3.org/wiki/Application_Foundations_all All on one page] -- giant transclusion of all the pages</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80679Application Foundations/DeviceInteraction2015-01-27T11:12:30Z<p>Hoschka: /* Goals */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Next Steps ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
https://www.w3.org/2015/01/16-appfound-minutes.html<br />
<br />
"I'd like to get as broad an involvement from the public as possible"<br />
<br />
" we should be calling on the AB, Membership and public for help<br />
... we could put this on the agenda<br />
... of the AB<br />
... to keep them up-to-date"<br />
<br />
" we get to a point where we want to create a conference or workshop<br />
... there is an extensible web summit in April<br />
... could be presented there<br />
... or we can attach an app foundation summit and do something there"<br />
<br />
"public survey, good idea,"<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Workplan ==<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
@@ dev outreach on sysapps, DAP, mobile IG - make that fit with HTML5Apps reviewer comments<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80678Application Foundations/DeviceInteraction2015-01-27T11:11:37Z<p>Hoschka: /* Next Steps */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Next Steps ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
https://www.w3.org/2015/01/16-appfound-minutes.html<br />
<br />
"I'd like to get as broad an involvement from the public as possible"<br />
<br />
" we should be calling on the AB, Membership and public for help<br />
... we could put this on the agenda<br />
... of the AB<br />
... to keep them up-to-date"<br />
<br />
" we get to a point where we want to create a conference or workshop<br />
... there is an extensible web summit in April<br />
... could be presented there<br />
... or we can attach an app foundation summit and do something there"<br />
<br />
"public survey, good idea,"<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
@@ dev outreach on sysapps, DAP, mobile IG - make that fit with HTML5Apps reviewer comments<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80676Application Foundations/DeviceInteraction2015-01-27T11:05:54Z<p>Hoschka: /* Next Steps */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Next Steps ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
https://www.w3.org/2015/01/16-appfound-minutes.html<br />
<br />
"I'd like to get as broad an involvement from the public as possible"<br />
<br />
" we should be calling on the AB, Membership and public for help<br />
... we could put this on the agenda<br />
... of the AB<br />
... to keep them up-to-date"<br />
<br />
" we get to a point where we want to create a conference or workshop<br />
... there is an extensible web summit in April<br />
... could be presented there<br />
... or we can attach an app foundation summit and do something there"<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
@@ dev outreach on sysapps, DAP, mobile IG - make that fit with HTML5Apps reviewer comments<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80675Application Foundations/DeviceInteraction2015-01-27T11:00:06Z<p>Hoschka: /* Goals */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Next Steps ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
https://www.w3.org/2015/01/16-appfound-minutes.html<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
@@ dev outreach on sysapps, DAP, mobile IG - make that fit with HTML5Apps reviewer comments<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80674Application Foundations/DeviceInteraction2015-01-27T10:59:04Z<p>Hoschka: /* Next Steps */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Next Steps ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
https://www.w3.org/2015/01/16-appfound-minutes.html<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80673Application Foundations/DeviceInteraction2015-01-27T10:51:36Z<p>Hoschka: /* Tasks */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Next Steps ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80672Application Foundations/DeviceInteraction2015-01-27T10:50:59Z<p>Hoschka: /* Tasks */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Tasks ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
https://www.w3.org/2015/01/09-appfound-minutes.html<br />
<br />
" as part of our workplan, I'd like to find developers we can talk to<br />
... If we spend a month talking to devs<br />
... if they say "they have no issues" -- great, nothing to do<br />
... if they say "these issues" then we have next steps for conversation<br />
... We should be flexible about what a workplan looks like<br />
... different in an area where we're more established<br />
... from one where we've had less traction<br />
... If we're serious about an area, we have to do something"<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80671Application Foundations/DeviceInteraction2015-01-27T10:42:19Z<p>Hoschka: /* Potential milestones */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Tasks ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
<br />
"Focus is on what can be accomplished in time for the May AC meeting."<br />
<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80670Application Foundations/DeviceInteraction2015-01-27T10:37:31Z<p>Hoschka: /* Tasks */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Tasks ==<br />
<br />
Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
"W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be."<br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80669Application Foundations/DeviceInteraction2015-01-27T10:36:48Z<p>Hoschka: </p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
== Tasks ==<br />
<br />
https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html<br />
<br />
W3M today concluded that it was time to take the current description <br />
to the next level. This would include: <br />
* comparing what we have in OWP with other platforms<br />
* gap analysis<br />
* prioritization<br />
* evangelizing. <br />
* It could also include a more detailed catalog of <br />
** what comprises each Foundation <br />
** what future requirements might be. <br />
<br />
== Relevant specs: ==<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
* Vehicle API spec<br />
* @@ to finalize<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80668Application Foundations/DeviceInteraction2015-01-27T10:25:45Z<p>Hoschka: </p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ "Applications Foundations for the Open Web Platform" - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 6: finalize workplan<br />
@@<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations&diff=80667Application Foundations2015-01-27T10:23:57Z<p>Hoschka: </p>
<hr />
<div>This is a public wiki for the community to share ideas for organizing and communicating [http://www.w3.org/appfoundations/ W3C's Application Foundations].<br />
<br />
== Resources ==<br />
<br />
* [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ Jeff Jaffe blog post] introducing Application Foundations on 2014-10-14<br />
* [https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_most_important#Core_task_force AB Most Important Priorities TF]<br />
<br />
=== Team Coordinators ===<br />
* [https://www.w3.org/wiki/Application_Foundations/SecurityPrivacy Security and Privacy]: Wendy<br />
* [https://www.w3.org/wiki/Application_Foundations/CoreDesignAndDev Core Web Design and Development]: Chris, Mike, PLH<br />
* [https://www.w3.org/wiki/Application_Foundations/DeviceInteraction Device Interaction]: Philipp, Dave<br />
* [https://www.w3.org/wiki/Application_Foundations/ApplicationLifecycle Application Lifecycle]: Dom, Mike, Xiaoqian<br />
* [https://www.w3.org/wiki/Application_Foundations/MediaRTC Media and Real-Time Communications]: Dom, Yves, PLH<br />
* [https://www.w3.org/wiki/Application_Foundations/PerformanceAndTuning Performance and Tuning]: PLH, Xiaoqian, Mike<br />
* [https://www.w3.org/wiki/Application_Foundations/UsabilityAndAccessibility Usability and Accessibility]: Richard, Bert, Judy<br />
* [https://www.w3.org/wiki/Application_Foundations/Services Services]: Felix, Doug, Wendy<br />
<br />
* [https://www.w3.org/wiki/Application_Foundations_all All on one page] -- giant transclusion of all the pages</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80663Application Foundations/DeviceInteraction2015-01-26T10:59:03Z<p>Hoschka: /* Goals */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80662Application Foundations/DeviceInteraction2015-01-26T10:58:24Z<p>Hoschka: /* Goals */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
<br />
== Goals ==<br />
<br />
@@ copied from media plan - for device interaction, sounds like lots of extra work in area where resources are already somewhat low<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80661Application Foundations/DeviceInteraction2015-01-26T10:56:51Z<p>Hoschka: /* Potential milestones */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
<br />
== Goals ==<br />
<br />
@@<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG<br />
* @@ <br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80660Application Foundations/DeviceInteraction2015-01-26T10:54:23Z<p>Hoschka: /* Goals */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
<br />
== Goals ==<br />
<br />
@@<br />
<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80659Application Foundations/DeviceInteraction2015-01-26T10:54:05Z<p>Hoschka: /* Description */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
<br />
== Goals ==<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80658Application Foundations/DeviceInteraction2015-01-26T10:53:45Z<p>Hoschka: /* Goals */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
<br />
@@<br />
== Goals ==<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80657Application Foundations/DeviceInteraction2015-01-26T10:52:29Z<p>Hoschka: /* Description */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], <br />
[http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working Group] all have a role to play in capturing <br />
good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* Sysapps specs<br />
* DAP specs<br />
* NFC spec<br />
* Bluetooth API CG<br />
<br />
== Goals ==<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80656Application Foundations/DeviceInteraction2015-01-26T10:50:08Z<p>Hoschka: /* Description */</p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], [http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working<br />
Group] all have a role to play in capturing good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* @@ Sysapps specs<br />
* @@ DAP specs<br />
* @@ NFC<br />
* @@ workers<br />
* @@<br />
* [http://www.w3.org/html/wg/drafts/html/master/ HTML5.1] and [https://www.w3.org/2015/01/html-plan/ HTML WG work plan 2015] focus on media<br />
* [https://w3c.github.io/webrtc-pc/ WebRTC]<br />
* [http://w3c.github.io/mediacapture-main/ Media Capture and Streams] (aka getUserMedia)<br />
* [https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html Media Source Extensions]<br />
* [http://w3c.github.io/encrypted-media/ Encryped Media Extensions]<br />
* [http://webaudio.github.io/web-audio-api/ Web Audio API]<br />
* [http://w3c.github.io/presentation-api/ Presentation API] (2nd screen)<br />
* [https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html Network Service Discovery]<br />
* [http://w3c.github.io/mediacapture-fromelement/ MediaStream Generation from HTML content]<br />
* [http://w3c.github.io/mediacapture-output/ Audio Output Devices API]<br />
* [https://github.com/w3c/mediacapture-screen-share Screen Capture API]<br />
<br />
== Goals ==<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80655Application Foundations/DeviceInteraction2015-01-26T10:49:22Z<p>Hoschka: </p>
<hr />
<div>== Description ==<br />
<br />
Source: [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ APPLICATION FOUNDATIONS FOR THE OPEN WEB PLATFORM - Jeff Jaffe]<br />
<br />
<Closely related to the Core Foundation is the Device Interaction<br />
Foundation, which describes the ways that devices are used to control<br />
or provide data to applications. New Web APIs are proposed weekly to<br />
give access to all of the features offered by supporting devices. For<br />
mobile phones, APIs exist or are in development for access to camera,<br />
microphone, orientation, GPS, vibration, ambient light, pointer lock,<br />
screen orientation, battery status, touch events, bluetooth, NFC, and<br />
more.<br />
<br />
The next generation of Web attached devices will introduce new<br />
challenges. For instance, the [http://www.w3.org/community/autowebplatform/ Automotive and Web<br />
Platform Business Group] is developing APIs to access information<br />
about vehicle speed, throttle position, interior lights, horn, and<br />
other car data that could help improve driving safety and<br />
convenience. We anticipate some of that work will advance to the<br />
standards track. In general, wearables, personal medical equipment<br />
devices, home energy management devices, and the Internet of Things<br />
will drive developer demand for data in applications, and for Web<br />
abstractions to simplify what will be new complexity in underlying<br />
networks. To achieve that simplicity for developers, the TAG, [http://www.w3.org/2009/dap/ Device APIs Working Group], [http://www.w3.org/2008/webapps/ Web Apps Working Group], and<br />
[http://www.w3.org/2012/sysapps/ Systems Applications Working<br />
Group] all have a role to play in capturing good practices for API<br />
design.<br />
<br />
Relevant specs:<br />
* @@ Sysapps specs<br />
* @@ DAP specs<br />
* @@ NFC<br />
* @@ workers<br />
* @@<br />
* [http://www.w3.org/html/wg/drafts/html/master/ HTML5.1] and [https://www.w3.org/2015/01/html-plan/ HTML WG work plan 2015] focus on media<br />
* [https://w3c.github.io/webrtc-pc/ WebRTC]<br />
* [http://w3c.github.io/mediacapture-main/ Media Capture and Streams] (aka getUserMedia)<br />
* [https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html Media Source Extensions]<br />
* [http://w3c.github.io/encrypted-media/ Encryped Media Extensions]<br />
* [http://webaudio.github.io/web-audio-api/ Web Audio API]<br />
* [http://w3c.github.io/presentation-api/ Presentation API] (2nd screen)<br />
* [https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html Network Service Discovery]<br />
* [http://w3c.github.io/mediacapture-fromelement/ MediaStream Generation from HTML content]<br />
* [http://w3c.github.io/mediacapture-output/ Audio Output Devices API]<br />
* [https://github.com/w3c/mediacapture-screen-share Screen Capture API]<br />
<br />
== Goals ==<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations/DeviceInteraction&diff=80654Application Foundations/DeviceInteraction2015-01-26T10:42:11Z<p>Hoschka: Created page with "Relevant specs: * @@ Sysapps specs * @@ DAP specs * @@ NFC * @@ workers * @@ * [http://www.w3.org/html/wg/drafts/html/master/ HTML5.1] and [https://www.w3.org/2015/01/html-pla..."</p>
<hr />
<div>Relevant specs:<br />
* @@ Sysapps specs<br />
* @@ DAP specs<br />
* @@ NFC<br />
* @@ workers<br />
* @@<br />
* [http://www.w3.org/html/wg/drafts/html/master/ HTML5.1] and [https://www.w3.org/2015/01/html-plan/ HTML WG work plan 2015] focus on media<br />
* [https://w3c.github.io/webrtc-pc/ WebRTC]<br />
* [http://w3c.github.io/mediacapture-main/ Media Capture and Streams] (aka getUserMedia)<br />
* [https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html Media Source Extensions]<br />
* [http://w3c.github.io/encrypted-media/ Encryped Media Extensions]<br />
* [http://webaudio.github.io/web-audio-api/ Web Audio API]<br />
* [http://w3c.github.io/presentation-api/ Presentation API] (2nd screen)<br />
* [https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html Network Service Discovery]<br />
* [http://w3c.github.io/mediacapture-fromelement/ MediaStream Generation from HTML content]<br />
* [http://w3c.github.io/mediacapture-output/ Audio Output Devices API]<br />
* [https://github.com/w3c/mediacapture-screen-share Screen Capture API]<br />
<br />
== Goals ==<br />
* document which use cases fall under this foundation<br />
* define a prioritization framework for these various use cases<br />
* evaluate how much of these use cases are currently achievable with existing techs<br />
* for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed<br />
* among those that are needed and in progress, determine how to accelerate their development<br />
* among those that are needed and not in progress, determine how to get them started<br />
* compare Web capabilities to native platforms<br />
* ensure consistencies of separately-developed specs<br />
<br />
== Potential milestones ==<br />
* Feb 15: identify sources of use cases not yet involved in W3C<br />
* Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)<br />
* Feb 28: proposed framework for prioritizing use cases<br />
* March 15: List of prioritized use cases<br />
* March 15: Review of capabilities of native platforms in this space<br />
* March 15: Map of use cases to Web technologies<br />
* April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment<br />
* April 24: Report for progress on application foundation due for AC meeting<br />
* May 5: AC meeting starts</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Application_Foundations&diff=80653Application Foundations2015-01-26T10:38:32Z<p>Hoschka: /* Resources */</p>
<hr />
<div>This is a public wiki for the community to share ideas for organizing and communicating [http://www.w3.org/appfoundations/ W3C's Application Foundations].<br />
<br />
== Resources ==<br />
<br />
* [http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ Jeff Jaffe blog post] introducing Application Foundations on 2014-10-14<br />
* [https://www.w3.org/wiki/AB/2014-2015_Priorities/w3c_most_important#Core_task_force AB Most Important Priorities TF]<br />
<br />
=== Team Coordinators ===<br />
* [https://www.w3.org/wiki/Application_Foundations/SecurityPrivacy Security and Privacy]: Wendy<br />
* [https://www.w3.org/wiki/Application_Foundations/CoreDesignAndDev Core Web Design and Development]: Chris, Mike, PLH<br />
* [https://www.w3.org/wiki/Application_Foundations/DeviceInteraction Device Interaction]: Philipp, Dave<br />
* [https://www.w3.org/wiki/Application_Foundations/ApplicationLifecycle Application Lifecycle]: Philipp, Dom, Mike, Xiaoqian<br />
* [https://www.w3.org/wiki/Application_Foundations/MediaRTC Media and Real-Time Communications]: Philipp, Dom, Yves, PLH<br />
* [https://www.w3.org/wiki/Application_Foundations/PerformanceAndTuning Performance and Tuning]: PLH, Xiaoqian, Mike<br />
* [https://www.w3.org/wiki/Application_Foundations/UsabilityAndAccessibility Usability and Accessibility]: Richard, Bert, Judy<br />
* [https://www.w3.org/wiki/Application_Foundations/Services Services]: Felix, Doug, Wendy<br />
<br />
* [https://www.w3.org/wiki/Application_Foundations_all All on one page] -- giant transclusion of all the pages</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Mobile/TPAC_Face-to-Face&diff=72032Mobile/TPAC Face-to-Face2014-02-17T11:18:09Z<p>Hoschka: </p>
<hr />
<div>The first face-to-face Web and Mobile Interest Group meeting will be at TPAC 2013! <br />
<br />
==Details==<br />
<br />
* '''Date:''' Thursday 14th & Friday 15th November 2013<br />
* '''Location:''' Shenzhen Wuzhou Guest House (TPAC Venue), Shenzhen, China<br />
* '''Observers:''' Permitted, please ask chair's approval<br />
* '''TPAC Registration:''' [https://www.w3.org/2002/09/wbs/35125/TPAC2013/ W3C TPAC Event Page]<br />
<br />
==Visas==<br />
<br />
Please remember that travelling to China means many of us will need to apply for visas. Please leave plenty of time to do this! For all TPAC information including visas, location, hotel and schedule please check the TPAC website [http://www.w3.org/2013/11/TPAC/].<br />
<br />
==Agenda==<br />
<br />
Please note that this agenda is subject to change. If you have any suggestions, please email the public mailing list ([mailto:public-web-mobile@w3.org public-web-mobile@w3.org]).<br />
=== [http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Thursday Thursday 14th November] ===<br />
[http://www.w3.org/2013/11/14-webmob-minutes.html minutes]<br />
<br />
=== [http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Friday Friday 15th November] ===<br />
[http://www.w3.org/2013/11/15-webmob-minutes.html minutes]<br />
<br />
==Questions==<br />
<br />
If you have any further questions or comments please contact the chairs by sending an email to the public mailing list [mailto:public-web-mobile@w3.org public-web-mobile@w3.org].<br />
<br />
==Conclusions ==<br />
<br />
Our Group<br />
* Task forces<br />
* Actions through mailing list<br />
* Wiki<br />
<br />
Documentation<br />
* Automation<br />
* Dashboard<br />
* Closing the Gap<br />
* WebAppState<br />
* Taking Use Cases and Requirements into the wider dashboard style report<br />
* Sort through Marcos's github issues on Coremob<br />
<br />
Offline<br />
* ServiceWorker<br />
* Use Cases obtained<br />
* Demos and Tests are next!<br />
* Keep adding status and implementation to docs / dashboard<br />
<br />
Scrolling<br />
* Talked about trends such as Infinite Scrolling<br />
* Is there a need for better / configurable garbage collection here?<br />
* Momentum scrolling<br />
* Build into docs / dashboard<br />
<br />
Testing Effort<br />
* Strong link to some of the work we will do<br />
* Funding issue right now<br />
* If work continues we can use this to pull in automations into our doc / dashboard<br />
<br />
Homescreen Bookmarking / Installable Webapps<br />
* Currently assessing the situation<br />
* Marcos and Ernesto are working on this<br />
* Need to pull in details from FFOS and Chrome Beta<br />
<br />
Push<br />
* Bryan took us through the push api<br />
* PAG is resolved<br />
* Add to doc / dashboard<br />
* A key proposal in closing the gap<br />
<br />
API Gap<br />
* Stats and figures from Vision Mobile report and Phone Gap<br />
* Showing importance of some APIs such as Network Info, Camera etc.<br />
* Need to pull this into docs / dashboard<br />
* This data can be key for closing the gap part of doc / dashboard<br />
<br />
Closing the Gap<br />
* Great work on this by Dom!<br />
* Everyone wishes for this to continue<br />
* Call to continue building the 'app types' table<br />
* Also include horizontal aspects such as 'accessibility'<br />
* Build into the dashboard<br />
<br />
WebAppState<br />
* More great work by Dom!<br />
* Taking this to the wiki and creating JSON files<br />
* Taken information from many sources such as 'Can I Use'<br />
* Some automated, some manual<br />
* Want to allow more groups to use this<br />
* Continue to build this work<br />
<br />
Payments<br />
* Detailed talk about the status of payments<br />
* Lots of aspects to cover<br />
* Workshop in March<br />
* Will need some use cases / requirements from this group<br />
<br />
Permissions<br />
* Permissions model different from web and native apps<br />
* Dom going to discuss with the TAG<br />
* Analysis on this would be good, pull into docs / dashboard<br />
<br />
Security<br />
* Web model very different from native<br />
* As we close the gap we need to understand how this changes<br />
* Another case of documenting<br />
* But what is also key is working with the Security IG to make sure we are not duplicating work and our work in this IG supports the proposals they create<br />
<br />
Developer Tools / Diagnostics / Debug<br />
* Web Driver<br />
* Diagnostics API<br />
* Wiki page [http://www.w3.org/wiki/Mobile/Dev_Tools http://www.w3.org/wiki/Mobile/Dev_Tools]<br />
* Document tools<br />
* Recruit dev tools experts<br />
<br />
Task Forces<br />
* Dividing groups in Task Forces<br />
* Assigning actions<br />
* I will send emails about this to the group<br />
* Please volunteer for something whilst you can!<br />
<br />
Dev Outreach / Education<br />
* Let's start talking about getting in touch with devs!</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Headlights2014/W3C_Workshop_on_Web_Apps_and_Marketplaces&diff=71754Headlights2014/W3C Workshop on Web Apps and Marketplaces2014-01-30T22:14:45Z<p>Hoschka: /* Feedback/Questions on the idea */</p>
<hr />
<div>===Name of idea===<br />
<br />
W3C Workshop on Web Apps and Marketplaces<br />
<br />
===Submitter name===<br />
<br />
Dave Raggett<br />
<br />
===Classification===<br />
<br />
This idea is:<br />
<br />
* A trend in information technology that requires further standardization<br />
<br />
===One Hundred Word Description of the Idea===<br />
<br />
We want to organize a W3C workshop to identify a roadmap for further standardization for web applications. The general aim is to make the Web the compelling choice for application developers, based upon open standards for rich access to device capabilities, excellent performance, strong security and privacy, ease of app discovery and monetization, accessibility, and low development and maintenance costs for targeting a heterogeneous mix of device types.<br />
<br />
The Workshop will build upon existing efforts, e.g. the System Applications and Web Apps Working Groups, and many other W3C Groups contributing to making the Web stronger for application development. The aim is to clarify opportunities for rechartering existing groups, for chartering new groups, and to create a shared vision for what we want to realize and the roadmap for getting there.<br />
<br />
This Headlights exercise will focus on clarifying the scope and objectives for the workshop, with a view to holding the workshop in Q3 2014.<br />
<br />
===Benefit(s) to Web or W3C===<br />
<br />
* Focusing effort on where new standards are needed<br />
<br />
* A stronger and more competitive Web, both online and offline<br />
<br />
* Improving the user experience of Web applications compared to native apps<br />
<br />
* Making it easier for users to discover and pay for services<br />
<br />
* Reducing the barriers for developers wishing to deploy apps to a wide range of devices<br />
<br />
===Which of our stakeholders would be the most enthusiastic in supporting===<br />
<br />
* Device manufacturers<br />
* Browser vendors<br />
* App developers<br />
* Online advertisers<br />
<br />
=== Feedback/Questions on the idea===<br />
<br />
* Philipp: the original idea was to hold a "Web OS" workshop to potentially refocus our "closing the gap' efforts and coordinate and focus the work currently spread over several WGs Main reason to make this a headlights project was that there was no funding available for the workshop when the idea was brought up at a ubiweb meeting, so would suggest to earmark 20K Euros for hosting this workshop - which we may not need if we find enough sponsors.<br />
<br />
See thread on SysApps List:<br />
<br />
* http://lists.w3.org/Archives/Public/public-sysapps/2014Jan/0005.html<br />
<br />
In summary:<br />
<br />
Wonsuk Lee (Samsung) is in favour, and wants to hear more about the ideas for scoping the proposed workshop.<br />
<br />
Marcos Caceres (Mozilla) suggests focusing on areas where the Web has fallen behind technically rather than stores, adding that changing the security model of the Web is tough. The experience of the DAP WG is a reminder of the need to stay nimble. He says that W3C needs to make it clearer that workshops are open meetings and not at all like academic workshops. The workshop needs a clear focus and tangible outcomes.<br />
<br />
Anssi Kostiainen (Intel) says we must embrace the prevalent permission, security, and trust models of the Web and build upon them to get the benefits of the Web too. Good things like universal access, discoverability through search engines, and an ability to share and discover content through plain old URLs without the middleman, for example.<br />
<br />
That said, Anssi says there’s an opportunity to make progress on some topics that could be in scope for the workshop:<br />
<br />
* How to gradually build trust when a user is having a conversation with a web resource, mediated by the User Agent? In abstract this is pretty similar to how humans interact with each other when they build trust relationships. Trust builds over time. You do not give your keys to a stranger you just met, but you probably happily tell your first name, for example. How this relates to the Web? Perhaps a user who has bookmarked a site trusts it a bit more than a site that she has not bookmarked? Or if a user visits a particular site every day, she may trust the site more. Or if other people she relates to do the same (reputation system). This should work both ways, and a site may lose a user’s trust as well.<br />
<br />
* We have a set of trust gestures built in to the platform such as bookmarking, uploading a file using the file picker, and drag and drop. I think it is important to ensure we understand and use these implicit permissions grants where appropriate instead of inventing new ones. The good old writeup by Robert O’Callahan at [1] is still relevant. Also the Mozilla’s position paper [2] from a 2008 workshop gives historical background from the time when the Geolocation API was the new thing.<br />
<br />
[1] http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html<br />
[2] http://www.w3.org/2008/security-ws/papers/mozilla.html<br />
<br />
To sum up, exposing more powerful APIs to the platform is not inherently bad. But if such APIs are only exposed to a subset of the Web (e.g. content distributed through often curated marketplaces), it is certainly not optimal considering the long-term health of the Web. We must ensure we evolve the Web as a whole, without boundaries.<br />
<br />
Understanding, evolving, and building atop the permission, security and trust models *of the Web* is the crux. Having a workshop — assuming we do not revisit the problems we have tried to solve multiple times before without great success -- sounds like a good idea.<br />
<br />
Charles McCathie Nevile (Yandex) says it is likely that there would be a lot of noisy pushback if the outcome is a new working group. He support's Marcos and Anssi in the need to focus on outcomes -- what can we usefully improve on and how do we ensure that we learn from the last decade (at least) of going round and round this circle? He is less worried about revisiting things -- that's how we learn.<br />
<br />
Charles adds that he would be appalled to see W3C simply start up Yet Another Group For APIs without a very strong push to recognise what has gone before. (To cite history, when sysapps proposed an app: URI spec that was a simple copy/paste of the widget: URI spec without acknowledging that history I think it made a grave mistake on several levels).<br />
<br />
There is obviously continuing interest in this area, so thinking about how to harness it towards developing standards, rather than the current mess of fragmentation, would be a useful thing to do if we can get support from those who are pushing forward the current different flavours of the same thing.<br />
<br />
Anssi responds: Yes, I tried to say we should not revisit the same problems without new input to the process, IOW do the same thing over and over again and expect different results.<br />
<br />
That said, I’m confident that with the right participants and scope we are able to make progress, especially if the same problems are shared with many products that are widely deployed.<br />
<br />
To take an example, Dom’s analysis of permissions handling in modern browsers ''(see below)'' is new input, describes a concrete problem, which I believe browser vendors have acknowledged and have interest in solving. Also, that is a problem that I assume can be solved in a reasonable time, or at least the situation can be improved significantly.<br />
<br />
''Extract from Charles' email:''<br />
<blockquote><br />
I would be appalled to see W3C simply start up Yet Another Group For APIs without a very strong push to recognise what has gone before. (To cite history, when sysapps proposed an app: URI spec that was a simple copy/paste of the widget: URI spec without acknowledging that history I think it made a grave mistake on several levels).<br />
<br />
There is obviously continuing interest in this area, so thinking about how to harness it towards developing standards, rather than the current mess of fragmentation, would be a useful thing to do if we can get support from those who are pushing forward the current different flavours of the same thing.<br />
</blockquote><br />
<br />
Agreed. Good candidates for further standards work are often evolutionary improvements that solve real-world problems that exist on the platform today, without disconnect to the current technology stack.<br />
<br />
Dominique Hazael-Massieux (W3C Staff) notes: Somewhat relevant to this thread, I published last week a review of existing permission requests across a set of Web APIs and features:<br />
<br />
* http://lists.w3.org/Archives/Public/public-web-mobile/2014Jan/0001.html<br />
* http://dontcallmedom.github.io/web-permissions-req/matrix.html<br />
<br />
Since a lot of the tension between in-browser vs out-of-the-browser<br />
application discussions resolve around permission and trust management,<br />
this might be useful input to this discussion.<br />
<br />
Also, I've recently added a number of references and quotes to [3]<br />
which would be good additional input.<br />
<br />
[3] http://www.w3.org/wiki/Mobile/articles#API_Permissions<br />
<br />
Anssi responds: Dom - this is a great overview on the subject of permission handling on the Web Platform. The concrete examples on the current state are especially telling. Thanks for kicking this off, informing the TAG.<br />
<br />
''Extract from Dom's email:''<br />
<blockquote><br />
Since a lot of the tension between in-browser vs out-of-the-browser application discussions resolve around permission and trust management, this might be useful input to this discussion.<br />
</blockquote><br />
<br />
I feel the topics you mention should definitely be in scope for the planned workshop. These are real problems that now exists in shipping modern browsers and harm the user experience of in-browser applications that use new features and APIs that require user consent.<br />
<br />
''Extract from Dom's email:''<br />
<blockquote><br />
Also, I've recently added a number of references and quotes to [3] which would be good additional input.<br />
</blockquote><br />
<br />
All - if you have good contacts in the academic world, doing HCI research, feel free to let them know we’re collecting relevant research papers on the topic to the above wiki.</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Headlights2014/W3C_Workshop_on_Web_Apps_and_Marketplaces&diff=71753Headlights2014/W3C Workshop on Web Apps and Marketplaces2014-01-30T21:54:27Z<p>Hoschka: /* Feedback/Questions on the idea */</p>
<hr />
<div>===Name of idea===<br />
<br />
W3C Workshop on Web Apps and Marketplaces<br />
<br />
===Submitter name===<br />
<br />
Dave Raggett<br />
<br />
===Classification===<br />
<br />
This idea is:<br />
<br />
* A trend in information technology that requires further standardization<br />
<br />
===One Hundred Word Description of the Idea===<br />
<br />
We want to organize a W3C workshop to identify a roadmap for further standardization for web applications. The general aim is to make the Web the compelling choice for application developers, based upon open standards for rich access to device capabilities, excellent performance, strong security and privacy, ease of app discovery and monetization, accessibility, and low development and maintenance costs for targeting a heterogeneous mix of device types.<br />
<br />
The Workshop will build upon existing efforts, e.g. the System Applications and Web Apps Working Groups, and many other W3C Groups contributing to making the Web stronger for application development. The aim is to clarify opportunities for rechartering existing groups, for chartering new groups, and to create a shared vision for what we want to realize and the roadmap for getting there.<br />
<br />
This Headlights exercise will focus on clarifying the scope and objectives for the workshop, with a view to holding the workshop in Q3 2014.<br />
<br />
===Benefit(s) to Web or W3C===<br />
<br />
* Focusing effort on where new standards are needed<br />
<br />
* A stronger and more competitive Web, both online and offline<br />
<br />
* Improving the user experience of Web applications compared to native apps<br />
<br />
* Making it easier for users to discover and pay for services<br />
<br />
* Reducing the barriers for developers wishing to deploy apps to a wide range of devices<br />
<br />
===Which of our stakeholders would be the most enthusiastic in supporting===<br />
<br />
* Device manufacturers<br />
* Browser vendors<br />
* App developers<br />
* Online advertisers<br />
<br />
=== Feedback/Questions on the idea===<br />
<br />
* Philipp: this is an exciting and timely idea to potentially refocus our "closing the gap' efforts and coordinate and focus the work currently spread over several WGs Main reason to make this a headlights project was that there was no funding available for the workshop when brought up at a ubiweb meeting, so would suggest to earmark 20K Euros for hosting this workshop - which we may not need if we find enough sponsors.<br />
<br />
See thread on SysApps List:<br />
<br />
* http://lists.w3.org/Archives/Public/public-sysapps/2014Jan/0005.html<br />
<br />
In summary:<br />
<br />
Wonsuk Lee (Samsung) is in favour, and wants to hear more about the ideas for scoping the proposed workshop.<br />
<br />
Marcos Caceres (Mozilla) suggests focusing on areas where the Web has fallen behind technically rather than stores, adding that changing the security model of the Web is tough. The experience of the DAP WG is a reminder of the need to stay nimble. He says that W3C needs to make it clearer that workshops are open meetings and not at all like academic workshops. The workshop needs a clear focus and tangible outcomes.<br />
<br />
Anssi Kostiainen (Intel) says we must embrace the prevalent permission, security, and trust models of the Web and build upon them to get the benefits of the Web too. Good things like universal access, discoverability through search engines, and an ability to share and discover content through plain old URLs without the middleman, for example.<br />
<br />
That said, Anssi says there’s an opportunity to make progress on some topics that could be in scope for the workshop:<br />
<br />
* How to gradually build trust when a user is having a conversation with a web resource, mediated by the User Agent? In abstract this is pretty similar to how humans interact with each other when they build trust relationships. Trust builds over time. You do not give your keys to a stranger you just met, but you probably happily tell your first name, for example. How this relates to the Web? Perhaps a user who has bookmarked a site trusts it a bit more than a site that she has not bookmarked? Or if a user visits a particular site every day, she may trust the site more. Or if other people she relates to do the same (reputation system). This should work both ways, and a site may lose a user’s trust as well.<br />
<br />
* We have a set of trust gestures built in to the platform such as bookmarking, uploading a file using the file picker, and drag and drop. I think it is important to ensure we understand and use these implicit permissions grants where appropriate instead of inventing new ones. The good old writeup by Robert O’Callahan at [1] is still relevant. Also the Mozilla’s position paper [2] from a 2008 workshop gives historical background from the time when the Geolocation API was the new thing.<br />
<br />
[1] http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html<br />
[2] http://www.w3.org/2008/security-ws/papers/mozilla.html<br />
<br />
To sum up, exposing more powerful APIs to the platform is not inherently bad. But if such APIs are only exposed to a subset of the Web (e.g. content distributed through often curated marketplaces), it is certainly not optimal considering the long-term health of the Web. We must ensure we evolve the Web as a whole, without boundaries.<br />
<br />
Understanding, evolving, and building atop the permission, security and trust models *of the Web* is the crux. Having a workshop — assuming we do not revisit the problems we have tried to solve multiple times before without great success -- sounds like a good idea.<br />
<br />
Charles McCathie Nevile (Yandex) says it is likely that there would be a lot of noisy pushback if the outcome is a new working group. He support's Marcos and Anssi in the need to focus on outcomes -- what can we usefully improve on and how do we ensure that we learn from the last decade (at least) of going round and round this circle? He is less worried about revisiting things -- that's how we learn.<br />
<br />
Charles adds that he would be appalled to see W3C simply start up Yet Another Group For APIs without a very strong push to recognise what has gone before. (To cite history, when sysapps proposed an app: URI spec that was a simple copy/paste of the widget: URI spec without acknowledging that history I think it made a grave mistake on several levels).<br />
<br />
There is obviously continuing interest in this area, so thinking about how to harness it towards developing standards, rather than the current mess of fragmentation, would be a useful thing to do if we can get support from those who are pushing forward the current different flavours of the same thing.<br />
<br />
Anssi responds: Yes, I tried to say we should not revisit the same problems without new input to the process, IOW do the same thing over and over again and expect different results.<br />
<br />
That said, I’m confident that with the right participants and scope we are able to make progress, especially if the same problems are shared with many products that are widely deployed.<br />
<br />
To take an example, Dom’s analysis of permissions handling in modern browsers ''(see below)'' is new input, describes a concrete problem, which I believe browser vendors have acknowledged and have interest in solving. Also, that is a problem that I assume can be solved in a reasonable time, or at least the situation can be improved significantly.<br />
<br />
''Extract from Charles' email:''<br />
<blockquote><br />
I would be appalled to see W3C simply start up Yet Another Group For APIs without a very strong push to recognise what has gone before. (To cite history, when sysapps proposed an app: URI spec that was a simple copy/paste of the widget: URI spec without acknowledging that history I think it made a grave mistake on several levels).<br />
<br />
There is obviously continuing interest in this area, so thinking about how to harness it towards developing standards, rather than the current mess of fragmentation, would be a useful thing to do if we can get support from those who are pushing forward the current different flavours of the same thing.<br />
</blockquote><br />
<br />
Agreed. Good candidates for further standards work are often evolutionary improvements that solve real-world problems that exist on the platform today, without disconnect to the current technology stack.<br />
<br />
Dominique Hazael-Massieux (W3C Staff) notes: Somewhat relevant to this thread, I published last week a review of existing permission requests across a set of Web APIs and features:<br />
<br />
* http://lists.w3.org/Archives/Public/public-web-mobile/2014Jan/0001.html<br />
* http://dontcallmedom.github.io/web-permissions-req/matrix.html<br />
<br />
Since a lot of the tension between in-browser vs out-of-the-browser<br />
application discussions resolve around permission and trust management,<br />
this might be useful input to this discussion.<br />
<br />
Also, I've recently added a number of references and quotes to [3]<br />
which would be good additional input.<br />
<br />
[3] http://www.w3.org/wiki/Mobile/articles#API_Permissions<br />
<br />
Anssi responds: Dom - this is a great overview on the subject of permission handling on the Web Platform. The concrete examples on the current state are especially telling. Thanks for kicking this off, informing the TAG.<br />
<br />
''Extract from Dom's email:''<br />
<blockquote><br />
Since a lot of the tension between in-browser vs out-of-the-browser application discussions resolve around permission and trust management, this might be useful input to this discussion.<br />
</blockquote><br />
<br />
I feel the topics you mention should definitely be in scope for the planned workshop. These are real problems that now exists in shipping modern browsers and harm the user experience of in-browser applications that use new features and APIs that require user consent.<br />
<br />
''Extract from Dom's email:''<br />
<blockquote><br />
Also, I've recently added a number of references and quotes to [3] which would be good additional input.<br />
</blockquote><br />
<br />
All - if you have good contacts in the academic world, doing HCI research, feel free to let them know we’re collecting relevant research papers on the topic to the above wiki.</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Headlights2014/W3C_Workshop_on_Web_Apps_and_Marketplaces&diff=71752Headlights2014/W3C Workshop on Web Apps and Marketplaces2014-01-30T21:53:24Z<p>Hoschka: /* Feedback/Questions on the idea */</p>
<hr />
<div>===Name of idea===<br />
<br />
W3C Workshop on Web Apps and Marketplaces<br />
<br />
===Submitter name===<br />
<br />
Dave Raggett<br />
<br />
===Classification===<br />
<br />
This idea is:<br />
<br />
* A trend in information technology that requires further standardization<br />
<br />
===One Hundred Word Description of the Idea===<br />
<br />
We want to organize a W3C workshop to identify a roadmap for further standardization for web applications. The general aim is to make the Web the compelling choice for application developers, based upon open standards for rich access to device capabilities, excellent performance, strong security and privacy, ease of app discovery and monetization, accessibility, and low development and maintenance costs for targeting a heterogeneous mix of device types.<br />
<br />
The Workshop will build upon existing efforts, e.g. the System Applications and Web Apps Working Groups, and many other W3C Groups contributing to making the Web stronger for application development. The aim is to clarify opportunities for rechartering existing groups, for chartering new groups, and to create a shared vision for what we want to realize and the roadmap for getting there.<br />
<br />
This Headlights exercise will focus on clarifying the scope and objectives for the workshop, with a view to holding the workshop in Q3 2014.<br />
<br />
===Benefit(s) to Web or W3C===<br />
<br />
* Focusing effort on where new standards are needed<br />
<br />
* A stronger and more competitive Web, both online and offline<br />
<br />
* Improving the user experience of Web applications compared to native apps<br />
<br />
* Making it easier for users to discover and pay for services<br />
<br />
* Reducing the barriers for developers wishing to deploy apps to a wide range of devices<br />
<br />
===Which of our stakeholders would be the most enthusiastic in supporting===<br />
<br />
* Device manufacturers<br />
* Browser vendors<br />
* App developers<br />
* Online advertisers<br />
<br />
=== Feedback/Questions on the idea===<br />
<br />
* Philipp: this is an exciting and timely idea to potentially refocus our "closing the gap' efforts and coordinate and focus the work currently spread over several WGs Main reason to make this a headlights project was that there was no funding available for the workshop, so would suggest to earmark 20K Euros for hosting this workshop - which we may not need if we find enough sponsors.<br />
<br />
See thread on SysApps List:<br />
<br />
* http://lists.w3.org/Archives/Public/public-sysapps/2014Jan/0005.html<br />
<br />
In summary:<br />
<br />
Wonsuk Lee (Samsung) is in favour, and wants to hear more about the ideas for scoping the proposed workshop.<br />
<br />
Marcos Caceres (Mozilla) suggests focusing on areas where the Web has fallen behind technically rather than stores, adding that changing the security model of the Web is tough. The experience of the DAP WG is a reminder of the need to stay nimble. He says that W3C needs to make it clearer that workshops are open meetings and not at all like academic workshops. The workshop needs a clear focus and tangible outcomes.<br />
<br />
Anssi Kostiainen (Intel) says we must embrace the prevalent permission, security, and trust models of the Web and build upon them to get the benefits of the Web too. Good things like universal access, discoverability through search engines, and an ability to share and discover content through plain old URLs without the middleman, for example.<br />
<br />
That said, Anssi says there’s an opportunity to make progress on some topics that could be in scope for the workshop:<br />
<br />
* How to gradually build trust when a user is having a conversation with a web resource, mediated by the User Agent? In abstract this is pretty similar to how humans interact with each other when they build trust relationships. Trust builds over time. You do not give your keys to a stranger you just met, but you probably happily tell your first name, for example. How this relates to the Web? Perhaps a user who has bookmarked a site trusts it a bit more than a site that she has not bookmarked? Or if a user visits a particular site every day, she may trust the site more. Or if other people she relates to do the same (reputation system). This should work both ways, and a site may lose a user’s trust as well.<br />
<br />
* We have a set of trust gestures built in to the platform such as bookmarking, uploading a file using the file picker, and drag and drop. I think it is important to ensure we understand and use these implicit permissions grants where appropriate instead of inventing new ones. The good old writeup by Robert O’Callahan at [1] is still relevant. Also the Mozilla’s position paper [2] from a 2008 workshop gives historical background from the time when the Geolocation API was the new thing.<br />
<br />
[1] http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html<br />
[2] http://www.w3.org/2008/security-ws/papers/mozilla.html<br />
<br />
To sum up, exposing more powerful APIs to the platform is not inherently bad. But if such APIs are only exposed to a subset of the Web (e.g. content distributed through often curated marketplaces), it is certainly not optimal considering the long-term health of the Web. We must ensure we evolve the Web as a whole, without boundaries.<br />
<br />
Understanding, evolving, and building atop the permission, security and trust models *of the Web* is the crux. Having a workshop — assuming we do not revisit the problems we have tried to solve multiple times before without great success -- sounds like a good idea.<br />
<br />
Charles McCathie Nevile (Yandex) says it is likely that there would be a lot of noisy pushback if the outcome is a new working group. He support's Marcos and Anssi in the need to focus on outcomes -- what can we usefully improve on and how do we ensure that we learn from the last decade (at least) of going round and round this circle? He is less worried about revisiting things -- that's how we learn.<br />
<br />
Charles adds that he would be appalled to see W3C simply start up Yet Another Group For APIs without a very strong push to recognise what has gone before. (To cite history, when sysapps proposed an app: URI spec that was a simple copy/paste of the widget: URI spec without acknowledging that history I think it made a grave mistake on several levels).<br />
<br />
There is obviously continuing interest in this area, so thinking about how to harness it towards developing standards, rather than the current mess of fragmentation, would be a useful thing to do if we can get support from those who are pushing forward the current different flavours of the same thing.<br />
<br />
Anssi responds: Yes, I tried to say we should not revisit the same problems without new input to the process, IOW do the same thing over and over again and expect different results.<br />
<br />
That said, I’m confident that with the right participants and scope we are able to make progress, especially if the same problems are shared with many products that are widely deployed.<br />
<br />
To take an example, Dom’s analysis of permissions handling in modern browsers ''(see below)'' is new input, describes a concrete problem, which I believe browser vendors have acknowledged and have interest in solving. Also, that is a problem that I assume can be solved in a reasonable time, or at least the situation can be improved significantly.<br />
<br />
''Extract from Charles' email:''<br />
<blockquote><br />
I would be appalled to see W3C simply start up Yet Another Group For APIs without a very strong push to recognise what has gone before. (To cite history, when sysapps proposed an app: URI spec that was a simple copy/paste of the widget: URI spec without acknowledging that history I think it made a grave mistake on several levels).<br />
<br />
There is obviously continuing interest in this area, so thinking about how to harness it towards developing standards, rather than the current mess of fragmentation, would be a useful thing to do if we can get support from those who are pushing forward the current different flavours of the same thing.<br />
</blockquote><br />
<br />
Agreed. Good candidates for further standards work are often evolutionary improvements that solve real-world problems that exist on the platform today, without disconnect to the current technology stack.<br />
<br />
Dominique Hazael-Massieux (W3C Staff) notes: Somewhat relevant to this thread, I published last week a review of existing permission requests across a set of Web APIs and features:<br />
<br />
* http://lists.w3.org/Archives/Public/public-web-mobile/2014Jan/0001.html<br />
* http://dontcallmedom.github.io/web-permissions-req/matrix.html<br />
<br />
Since a lot of the tension between in-browser vs out-of-the-browser<br />
application discussions resolve around permission and trust management,<br />
this might be useful input to this discussion.<br />
<br />
Also, I've recently added a number of references and quotes to [3]<br />
which would be good additional input.<br />
<br />
[3] http://www.w3.org/wiki/Mobile/articles#API_Permissions<br />
<br />
Anssi responds: Dom - this is a great overview on the subject of permission handling on the Web Platform. The concrete examples on the current state are especially telling. Thanks for kicking this off, informing the TAG.<br />
<br />
''Extract from Dom's email:''<br />
<blockquote><br />
Since a lot of the tension between in-browser vs out-of-the-browser application discussions resolve around permission and trust management, this might be useful input to this discussion.<br />
</blockquote><br />
<br />
I feel the topics you mention should definitely be in scope for the planned workshop. These are real problems that now exists in shipping modern browsers and harm the user experience of in-browser applications that use new features and APIs that require user consent.<br />
<br />
''Extract from Dom's email:''<br />
<blockquote><br />
Also, I've recently added a number of references and quotes to [3] which would be good additional input.<br />
</blockquote><br />
<br />
All - if you have good contacts in the academic world, doing HCI research, feel free to let them know we’re collecting relevant research papers on the topic to the above wiki.</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Web_and_Automotive&diff=64140Web and Automotive2013-02-15T12:29:01Z<p>Hoschka: </p>
<hr />
<div>'''Please check out <br />
<br />
'''[http://www.w3.org/2012/08/web-and-automotive/ W3C Web and Automotive Workshop page]''' <br />
<br />
'''for up-to-date news on this topic'''<br />
<br />
'''The below is historic material'''<br />
<br />
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''<br />
<br />
This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive mailing list].<br />
<br />
== Web Applications in the Car ==<br />
<br />
The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.<br />
<br />
Web technologies have a significant edge over proprietary application development technologies.<br />
<br />
== Advantages of Web Applications ==<br />
<br />
* It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.<br />
* There is huge knowledge base already available on Web technologies.<br />
* In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.<br />
<br />
== Challenges to adopt Web Technology in the Car ==<br />
<br />
There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.<br />
<br />
<ul><br />
<li>Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.</li><br />
<li>Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs</li><br />
</ul><br />
<br />
=== Road map ===<br />
<br />
Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.<br />
<br />
We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.<br />
<br />
== How to get involved ==<br />
<br />
Please subscribe to the public mailing list [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive@w3.org]. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the [http://www.w3.org/Help/Account/ account request form].<br />
<br />
In case of further questions, please contact the following:<br />
<br />
* Dave Raggett <dsr@w3.org><br />
* Bernard Gidon <bgidon@w3.org><br />
<br />
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy].<br />
<br />
== Recent meetings ==<br />
<br />
* [[EIT-ICT Labs - 2012-04-23]]<br />
* [[GENIVI All Members meeting - 2012-04-26]]<br />
<br />
== Some relevant topics ==<br />
<br />
This is probably incomplete, and we welcome your comments and suggestions.<br />
<br />
=== Use Cases and Ecosystems ===<br />
<br />
Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.<br />
<br />
==== Example Applications ====<br />
<br />
This is a sampling of some of the applications we may expect:<br />
<br />
* Media player for local and streamed media<br />
* News and weather -- local, national, international, sports, business, arts, ...<br />
* SatNav with live traffic data and parking information<br />
* Location based search and advertising<br />
* Games -- for passengers<br />
* Social network apps -- tweets, posts, photos, location, ...<br />
* Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...<br />
* Custom enterprise apps<br />
* Car status -- fuel efficiency, servicing info, ...<br />
<br />
=== HTML5 ===<br />
<br />
With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?<br />
<br />
=== Application Packaging ===<br />
<br />
The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.<br />
<br />
=== Foreground Applications and Background Services ===<br />
<br />
In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of [http://dev.w3.org/html5/workers/ Web Workers] that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by [http://nodejs.org/ node.js] where services are defined in terms of event driven JavaScript modules and libraries of APIs. <br />
A related challenge is what is the most effective way for users to switch between applications?<br />
<br />
=== Multi-Device Applications ===<br />
<br />
In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?<br />
<br />
=== User input controls ===<br />
<br />
Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?<br />
<br />
=== Vocal and multimodal interfaces ===<br />
<br />
Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services? <br />
<br />
Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?<br />
<br />
=== Context Awareness ===<br />
<br />
How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.<br />
<br />
We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.<br />
<br />
=== Notifications ===<br />
<br />
How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's [http://www.w3.org/2010/web-notifications/ Web Notification Working Group].<br />
<br />
The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.<br />
<br />
=== Automotive Specific APIs ===<br />
<br />
What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?<br />
<br />
=== Security, Privacy and Trust ===<br />
<br />
The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.<br />
<br />
Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?<br />
<br />
One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.<br />
<br />
=== User Preferences ===<br />
<br />
Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.<br />
<br />
=== Advertising ===<br />
<br />
What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.<br />
<br />
=== Payments ===<br />
<br />
There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the [http://www.w3.org/wiki/Payments_Task_Force W3C Payments Task Force wiki].<br />
<br />
== Web and Automotive Workshop ==<br />
<br />
* [http://www.w3.org/2005/10/Process-20051014/events.html Process requirements for W3C Workshops]<br />
<br />
W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.<br />
<br />
At this time, the workshop is now expected to be during the '''2nd half of November 2012''', but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.<br />
<br />
=== Program Committee Members ===<br />
<br />
* James Ausmus, Intel<br />
* Diana Cheng, Vodafone<br />
* Virginie Galindo, Gemalto<br />
* Matthias Goebl, BMW<br />
* Andy Gryc, QNX<br />
* Wolfgang Haberl, BMW<br />
* Christopher Hilton, Harman<br />
* Nobuhide Kotsuka, KDDI<br />
* Roger C. Lanctot, Strategy Analytics<br />
* Håkon Lie, Opera Software<br />
* James McGinley, Intel<br />
* Maximilian Michel, BMW<br />
* Christian Müller, DFKI<br />
* Scott Pennock, QNX<br />
* Youngsun Ryu, Samsung<br />
* Ryuji Wakikawa, Toyota ITC</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Web_and_Automotive&diff=64139Web and Automotive2013-02-15T12:28:30Z<p>Hoschka: </p>
<hr />
<div>'''The below is historic material'''<br />
<br />
'''Please check out <br />
<br />
'''[http://www.w3.org/2012/08/web-and-automotive/ W3C Web and Automotive Workshop page]''' <br />
<br />
'''for up-to-date news on this topic'''<br />
<br />
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''<br />
<br />
This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive mailing list].<br />
<br />
== Web Applications in the Car ==<br />
<br />
The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.<br />
<br />
Web technologies have a significant edge over proprietary application development technologies.<br />
<br />
== Advantages of Web Applications ==<br />
<br />
* It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.<br />
* There is huge knowledge base already available on Web technologies.<br />
* In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.<br />
<br />
== Challenges to adopt Web Technology in the Car ==<br />
<br />
There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.<br />
<br />
<ul><br />
<li>Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.</li><br />
<li>Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs</li><br />
</ul><br />
<br />
=== Road map ===<br />
<br />
Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.<br />
<br />
We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.<br />
<br />
== How to get involved ==<br />
<br />
Please subscribe to the public mailing list [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive@w3.org]. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the [http://www.w3.org/Help/Account/ account request form].<br />
<br />
In case of further questions, please contact the following:<br />
<br />
* Dave Raggett <dsr@w3.org><br />
* Bernard Gidon <bgidon@w3.org><br />
<br />
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy].<br />
<br />
== Recent meetings ==<br />
<br />
* [[EIT-ICT Labs - 2012-04-23]]<br />
* [[GENIVI All Members meeting - 2012-04-26]]<br />
<br />
== Some relevant topics ==<br />
<br />
This is probably incomplete, and we welcome your comments and suggestions.<br />
<br />
=== Use Cases and Ecosystems ===<br />
<br />
Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.<br />
<br />
==== Example Applications ====<br />
<br />
This is a sampling of some of the applications we may expect:<br />
<br />
* Media player for local and streamed media<br />
* News and weather -- local, national, international, sports, business, arts, ...<br />
* SatNav with live traffic data and parking information<br />
* Location based search and advertising<br />
* Games -- for passengers<br />
* Social network apps -- tweets, posts, photos, location, ...<br />
* Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...<br />
* Custom enterprise apps<br />
* Car status -- fuel efficiency, servicing info, ...<br />
<br />
=== HTML5 ===<br />
<br />
With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?<br />
<br />
=== Application Packaging ===<br />
<br />
The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.<br />
<br />
=== Foreground Applications and Background Services ===<br />
<br />
In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of [http://dev.w3.org/html5/workers/ Web Workers] that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by [http://nodejs.org/ node.js] where services are defined in terms of event driven JavaScript modules and libraries of APIs. <br />
A related challenge is what is the most effective way for users to switch between applications?<br />
<br />
=== Multi-Device Applications ===<br />
<br />
In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?<br />
<br />
=== User input controls ===<br />
<br />
Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?<br />
<br />
=== Vocal and multimodal interfaces ===<br />
<br />
Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services? <br />
<br />
Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?<br />
<br />
=== Context Awareness ===<br />
<br />
How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.<br />
<br />
We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.<br />
<br />
=== Notifications ===<br />
<br />
How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's [http://www.w3.org/2010/web-notifications/ Web Notification Working Group].<br />
<br />
The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.<br />
<br />
=== Automotive Specific APIs ===<br />
<br />
What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?<br />
<br />
=== Security, Privacy and Trust ===<br />
<br />
The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.<br />
<br />
Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?<br />
<br />
One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.<br />
<br />
=== User Preferences ===<br />
<br />
Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.<br />
<br />
=== Advertising ===<br />
<br />
What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.<br />
<br />
=== Payments ===<br />
<br />
There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the [http://www.w3.org/wiki/Payments_Task_Force W3C Payments Task Force wiki].<br />
<br />
== Web and Automotive Workshop ==<br />
<br />
* [http://www.w3.org/2005/10/Process-20051014/events.html Process requirements for W3C Workshops]<br />
<br />
W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.<br />
<br />
At this time, the workshop is now expected to be during the '''2nd half of November 2012''', but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.<br />
<br />
=== Program Committee Members ===<br />
<br />
* James Ausmus, Intel<br />
* Diana Cheng, Vodafone<br />
* Virginie Galindo, Gemalto<br />
* Matthias Goebl, BMW<br />
* Andy Gryc, QNX<br />
* Wolfgang Haberl, BMW<br />
* Christopher Hilton, Harman<br />
* Nobuhide Kotsuka, KDDI<br />
* Roger C. Lanctot, Strategy Analytics<br />
* Håkon Lie, Opera Software<br />
* James McGinley, Intel<br />
* Maximilian Michel, BMW<br />
* Christian Müller, DFKI<br />
* Scott Pennock, QNX<br />
* Youngsun Ryu, Samsung<br />
* Ryuji Wakikawa, Toyota ITC</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Web_and_Automotive&diff=64138Web and Automotive2013-02-15T12:28:09Z<p>Hoschka: </p>
<hr />
<div>'''The below is historic material'''<br />
<br />
'''Please check out <br />
<br />
'''[http://www.w3.org/2012/08/web-and-automotive/ W3C Web and Automotive Workshop page]''' <br />
<br />
for up-to-date news on this topic'''<br />
<br />
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''<br />
<br />
This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive mailing list].<br />
<br />
== Web Applications in the Car ==<br />
<br />
The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.<br />
<br />
Web technologies have a significant edge over proprietary application development technologies.<br />
<br />
== Advantages of Web Applications ==<br />
<br />
* It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.<br />
* There is huge knowledge base already available on Web technologies.<br />
* In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.<br />
<br />
== Challenges to adopt Web Technology in the Car ==<br />
<br />
There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.<br />
<br />
<ul><br />
<li>Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.</li><br />
<li>Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs</li><br />
</ul><br />
<br />
=== Road map ===<br />
<br />
Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.<br />
<br />
We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.<br />
<br />
== How to get involved ==<br />
<br />
Please subscribe to the public mailing list [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive@w3.org]. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the [http://www.w3.org/Help/Account/ account request form].<br />
<br />
In case of further questions, please contact the following:<br />
<br />
* Dave Raggett <dsr@w3.org><br />
* Bernard Gidon <bgidon@w3.org><br />
<br />
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy].<br />
<br />
== Recent meetings ==<br />
<br />
* [[EIT-ICT Labs - 2012-04-23]]<br />
* [[GENIVI All Members meeting - 2012-04-26]]<br />
<br />
== Some relevant topics ==<br />
<br />
This is probably incomplete, and we welcome your comments and suggestions.<br />
<br />
=== Use Cases and Ecosystems ===<br />
<br />
Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.<br />
<br />
==== Example Applications ====<br />
<br />
This is a sampling of some of the applications we may expect:<br />
<br />
* Media player for local and streamed media<br />
* News and weather -- local, national, international, sports, business, arts, ...<br />
* SatNav with live traffic data and parking information<br />
* Location based search and advertising<br />
* Games -- for passengers<br />
* Social network apps -- tweets, posts, photos, location, ...<br />
* Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...<br />
* Custom enterprise apps<br />
* Car status -- fuel efficiency, servicing info, ...<br />
<br />
=== HTML5 ===<br />
<br />
With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?<br />
<br />
=== Application Packaging ===<br />
<br />
The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.<br />
<br />
=== Foreground Applications and Background Services ===<br />
<br />
In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of [http://dev.w3.org/html5/workers/ Web Workers] that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by [http://nodejs.org/ node.js] where services are defined in terms of event driven JavaScript modules and libraries of APIs. <br />
A related challenge is what is the most effective way for users to switch between applications?<br />
<br />
=== Multi-Device Applications ===<br />
<br />
In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?<br />
<br />
=== User input controls ===<br />
<br />
Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?<br />
<br />
=== Vocal and multimodal interfaces ===<br />
<br />
Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services? <br />
<br />
Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?<br />
<br />
=== Context Awareness ===<br />
<br />
How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.<br />
<br />
We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.<br />
<br />
=== Notifications ===<br />
<br />
How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's [http://www.w3.org/2010/web-notifications/ Web Notification Working Group].<br />
<br />
The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.<br />
<br />
=== Automotive Specific APIs ===<br />
<br />
What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?<br />
<br />
=== Security, Privacy and Trust ===<br />
<br />
The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.<br />
<br />
Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?<br />
<br />
One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.<br />
<br />
=== User Preferences ===<br />
<br />
Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.<br />
<br />
=== Advertising ===<br />
<br />
What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.<br />
<br />
=== Payments ===<br />
<br />
There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the [http://www.w3.org/wiki/Payments_Task_Force W3C Payments Task Force wiki].<br />
<br />
== Web and Automotive Workshop ==<br />
<br />
* [http://www.w3.org/2005/10/Process-20051014/events.html Process requirements for W3C Workshops]<br />
<br />
W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.<br />
<br />
At this time, the workshop is now expected to be during the '''2nd half of November 2012''', but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.<br />
<br />
=== Program Committee Members ===<br />
<br />
* James Ausmus, Intel<br />
* Diana Cheng, Vodafone<br />
* Virginie Galindo, Gemalto<br />
* Matthias Goebl, BMW<br />
* Andy Gryc, QNX<br />
* Wolfgang Haberl, BMW<br />
* Christopher Hilton, Harman<br />
* Nobuhide Kotsuka, KDDI<br />
* Roger C. Lanctot, Strategy Analytics<br />
* Håkon Lie, Opera Software<br />
* James McGinley, Intel<br />
* Maximilian Michel, BMW<br />
* Christian Müller, DFKI<br />
* Scott Pennock, QNX<br />
* Youngsun Ryu, Samsung<br />
* Ryuji Wakikawa, Toyota ITC</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Web_and_Automotive&diff=64137Web and Automotive2013-02-15T12:27:25Z<p>Hoschka: </p>
<hr />
<div>'''The below is historic material'''<br />
<br />
'''Please check out [http://www.w3.org/2012/08/web-and-automotive/ W3C Web and Automotive Workshop page] for most news on this topic'''<br />
<br />
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''<br />
<br />
This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive mailing list].<br />
<br />
== Web Applications in the Car ==<br />
<br />
The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.<br />
<br />
Web technologies have a significant edge over proprietary application development technologies.<br />
<br />
== Advantages of Web Applications ==<br />
<br />
* It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.<br />
* There is huge knowledge base already available on Web technologies.<br />
* In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.<br />
<br />
== Challenges to adopt Web Technology in the Car ==<br />
<br />
There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.<br />
<br />
<ul><br />
<li>Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.</li><br />
<li>Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs</li><br />
</ul><br />
<br />
=== Road map ===<br />
<br />
Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.<br />
<br />
We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.<br />
<br />
== How to get involved ==<br />
<br />
Please subscribe to the public mailing list [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive@w3.org]. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the [http://www.w3.org/Help/Account/ account request form].<br />
<br />
In case of further questions, please contact the following:<br />
<br />
* Dave Raggett <dsr@w3.org><br />
* Bernard Gidon <bgidon@w3.org><br />
<br />
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy].<br />
<br />
== Recent meetings ==<br />
<br />
* [[EIT-ICT Labs - 2012-04-23]]<br />
* [[GENIVI All Members meeting - 2012-04-26]]<br />
<br />
== Some relevant topics ==<br />
<br />
This is probably incomplete, and we welcome your comments and suggestions.<br />
<br />
=== Use Cases and Ecosystems ===<br />
<br />
Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.<br />
<br />
==== Example Applications ====<br />
<br />
This is a sampling of some of the applications we may expect:<br />
<br />
* Media player for local and streamed media<br />
* News and weather -- local, national, international, sports, business, arts, ...<br />
* SatNav with live traffic data and parking information<br />
* Location based search and advertising<br />
* Games -- for passengers<br />
* Social network apps -- tweets, posts, photos, location, ...<br />
* Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...<br />
* Custom enterprise apps<br />
* Car status -- fuel efficiency, servicing info, ...<br />
<br />
=== HTML5 ===<br />
<br />
With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?<br />
<br />
=== Application Packaging ===<br />
<br />
The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.<br />
<br />
=== Foreground Applications and Background Services ===<br />
<br />
In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of [http://dev.w3.org/html5/workers/ Web Workers] that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by [http://nodejs.org/ node.js] where services are defined in terms of event driven JavaScript modules and libraries of APIs. <br />
A related challenge is what is the most effective way for users to switch between applications?<br />
<br />
=== Multi-Device Applications ===<br />
<br />
In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?<br />
<br />
=== User input controls ===<br />
<br />
Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?<br />
<br />
=== Vocal and multimodal interfaces ===<br />
<br />
Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services? <br />
<br />
Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?<br />
<br />
=== Context Awareness ===<br />
<br />
How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.<br />
<br />
We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.<br />
<br />
=== Notifications ===<br />
<br />
How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's [http://www.w3.org/2010/web-notifications/ Web Notification Working Group].<br />
<br />
The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.<br />
<br />
=== Automotive Specific APIs ===<br />
<br />
What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?<br />
<br />
=== Security, Privacy and Trust ===<br />
<br />
The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.<br />
<br />
Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?<br />
<br />
One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.<br />
<br />
=== User Preferences ===<br />
<br />
Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.<br />
<br />
=== Advertising ===<br />
<br />
What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.<br />
<br />
=== Payments ===<br />
<br />
There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the [http://www.w3.org/wiki/Payments_Task_Force W3C Payments Task Force wiki].<br />
<br />
== Web and Automotive Workshop ==<br />
<br />
* [http://www.w3.org/2005/10/Process-20051014/events.html Process requirements for W3C Workshops]<br />
<br />
W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.<br />
<br />
At this time, the workshop is now expected to be during the '''2nd half of November 2012''', but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.<br />
<br />
=== Program Committee Members ===<br />
<br />
* James Ausmus, Intel<br />
* Diana Cheng, Vodafone<br />
* Virginie Galindo, Gemalto<br />
* Matthias Goebl, BMW<br />
* Andy Gryc, QNX<br />
* Wolfgang Haberl, BMW<br />
* Christopher Hilton, Harman<br />
* Nobuhide Kotsuka, KDDI<br />
* Roger C. Lanctot, Strategy Analytics<br />
* Håkon Lie, Opera Software<br />
* James McGinley, Intel<br />
* Maximilian Michel, BMW<br />
* Christian Müller, DFKI<br />
* Scott Pennock, QNX<br />
* Youngsun Ryu, Samsung<br />
* Ryuji Wakikawa, Toyota ITC</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Web_and_Automotive&diff=64136Web and Automotive2013-02-15T12:27:01Z<p>Hoschka: </p>
<hr />
<div>'''The below is historic material'''<br />
<br />
'''Please check out [http://www.w3.org/2012/08/web-and-automotive/ W3C Web and Automotive Workshop page] for most news on this topic'''<br />
<br />
----<br />
<br />
<br />
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''<br />
<br />
This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive mailing list].<br />
<br />
== Web Applications in the Car ==<br />
<br />
The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.<br />
<br />
Web technologies have a significant edge over proprietary application development technologies.<br />
<br />
== Advantages of Web Applications ==<br />
<br />
* It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.<br />
* There is huge knowledge base already available on Web technologies.<br />
* In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.<br />
<br />
== Challenges to adopt Web Technology in the Car ==<br />
<br />
There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.<br />
<br />
<ul><br />
<li>Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.</li><br />
<li>Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs</li><br />
</ul><br />
<br />
=== Road map ===<br />
<br />
Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.<br />
<br />
We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.<br />
<br />
== How to get involved ==<br />
<br />
Please subscribe to the public mailing list [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive@w3.org]. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the [http://www.w3.org/Help/Account/ account request form].<br />
<br />
In case of further questions, please contact the following:<br />
<br />
* Dave Raggett <dsr@w3.org><br />
* Bernard Gidon <bgidon@w3.org><br />
<br />
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy].<br />
<br />
== Recent meetings ==<br />
<br />
* [[EIT-ICT Labs - 2012-04-23]]<br />
* [[GENIVI All Members meeting - 2012-04-26]]<br />
<br />
== Some relevant topics ==<br />
<br />
This is probably incomplete, and we welcome your comments and suggestions.<br />
<br />
=== Use Cases and Ecosystems ===<br />
<br />
Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.<br />
<br />
==== Example Applications ====<br />
<br />
This is a sampling of some of the applications we may expect:<br />
<br />
* Media player for local and streamed media<br />
* News and weather -- local, national, international, sports, business, arts, ...<br />
* SatNav with live traffic data and parking information<br />
* Location based search and advertising<br />
* Games -- for passengers<br />
* Social network apps -- tweets, posts, photos, location, ...<br />
* Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...<br />
* Custom enterprise apps<br />
* Car status -- fuel efficiency, servicing info, ...<br />
<br />
=== HTML5 ===<br />
<br />
With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?<br />
<br />
=== Application Packaging ===<br />
<br />
The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.<br />
<br />
=== Foreground Applications and Background Services ===<br />
<br />
In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of [http://dev.w3.org/html5/workers/ Web Workers] that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by [http://nodejs.org/ node.js] where services are defined in terms of event driven JavaScript modules and libraries of APIs. <br />
A related challenge is what is the most effective way for users to switch between applications?<br />
<br />
=== Multi-Device Applications ===<br />
<br />
In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?<br />
<br />
=== User input controls ===<br />
<br />
Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?<br />
<br />
=== Vocal and multimodal interfaces ===<br />
<br />
Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services? <br />
<br />
Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?<br />
<br />
=== Context Awareness ===<br />
<br />
How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.<br />
<br />
We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.<br />
<br />
=== Notifications ===<br />
<br />
How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's [http://www.w3.org/2010/web-notifications/ Web Notification Working Group].<br />
<br />
The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.<br />
<br />
=== Automotive Specific APIs ===<br />
<br />
What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?<br />
<br />
=== Security, Privacy and Trust ===<br />
<br />
The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.<br />
<br />
Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?<br />
<br />
One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.<br />
<br />
=== User Preferences ===<br />
<br />
Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.<br />
<br />
=== Advertising ===<br />
<br />
What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.<br />
<br />
=== Payments ===<br />
<br />
There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the [http://www.w3.org/wiki/Payments_Task_Force W3C Payments Task Force wiki].<br />
<br />
== Web and Automotive Workshop ==<br />
<br />
* [http://www.w3.org/2005/10/Process-20051014/events.html Process requirements for W3C Workshops]<br />
<br />
W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.<br />
<br />
At this time, the workshop is now expected to be during the '''2nd half of November 2012''', but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.<br />
<br />
=== Program Committee Members ===<br />
<br />
* James Ausmus, Intel<br />
* Diana Cheng, Vodafone<br />
* Virginie Galindo, Gemalto<br />
* Matthias Goebl, BMW<br />
* Andy Gryc, QNX<br />
* Wolfgang Haberl, BMW<br />
* Christopher Hilton, Harman<br />
* Nobuhide Kotsuka, KDDI<br />
* Roger C. Lanctot, Strategy Analytics<br />
* Håkon Lie, Opera Software<br />
* James McGinley, Intel<br />
* Maximilian Michel, BMW<br />
* Christian Müller, DFKI<br />
* Scott Pennock, QNX<br />
* Youngsun Ryu, Samsung<br />
* Ryuji Wakikawa, Toyota ITC</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Standards_for_Web_Applications_on_Mobile&diff=61949Standards for Web Applications on Mobile2012-10-28T15:59:28Z<p>Hoschka: /* Status */</p>
<hr />
<div>= Status =<br />
This is the live copy of a document that the [http://mobiwebapp.eu MobiWebApp project] publishes every three month, reflecting the current status of the Web technologies that are the most relevant on mobile devices ([http://www.w3.org/Mobile/mobile-web-app-state/ latest release]). Contributions to this document are very welcome.<br />
<br />
TODO:<br />
* look at [[BrowserTechnologies]]<br />
* Microdata?<br />
* I18N/Multiscripts: but what?<br />
* EXI<br />
<br />
= Intro =<br />
<br />
<p>Web technologies have become powerful enough that they are used to build full-featured applications; this has been true for many years in the desktop and laptop computer realm, but is increasingly so on mobile devices as well.</p><br />
<br />
<p>This document summarizes the various technologies developed in W3C that increase the capabilities of Web applications, and how they apply more specifically to the mobile context.</p><br />
<br />
<ol><br />
<li>[[#Graphics]]</li><br />
<li>[[#Multimedia]]</li><br />
<li>[[#Device Adaptation]]</li><br />
<li>[[#Forms]]</li><br />
<li>[[#User interactions]]</li><br />
<li>[[#Data storage]]</li><br />
<li>[[#Personal Information Management]]</li><br />
<li>[[#Sensors and hardware integration]]</li><br />
<li>[[#Network]]</li><br />
<li>[[#Communication_and_Discovery]]</li><br />
<li>[[#Packaging]]</li><br />
<li>[[#Performance &amp; Optimization]]</li><br />
</ol><br />
<br />
<p>The data in this report should be <strong>used with caution</strong>. Feedback on every aspect of this document should be sent to the author (dom@w3.org) and will serve as input for the next iteration of the document.</p><br />
<br />
<p>The features that these technologies add to the Web platform are organized under the following categories: [[#Graphics]], [[#Multimedia]], [[#Device_Adaptation]], [[#Forms]], [[#User_interactions]], [[#Data_storage]], [[#Personal_Information_Management]], [[#Sensors_and_hardware_integration]], [[#Network]], [[#Communication_and_Discovery]], [[#Packaging]], [[#Performance_.26_Optimization]].</p><br />
<br />
<p>In each category, a table summarizes for each feature:</p><br />
<ul><br />
<li>which W3C specification defines the feature,</li><br />
<li>which W3C group is responsible of the said specification,</li><br />
<li>the stage of the specification in the W3C Recommendation track (see below),</li><br />
<li>the estimated stability of the document, i.e. how widely the document is expected to change, as estimated by the author of this report, with three levels: low (the document is mostly stable), medium (some parts are stable, others are expected to change significantly), high (the document is expected to evolve significantly),</li><br />
<li>some qualitative indication on availability of implementations on mobile devices, based on data collected primarily from [http://caniuse.com/ Can I Use&hellip;] and [http://mobilehtml5.org/ mobile HTML5], completed with data from [https://developer.mozilla.org/ Mozilla developer network], [http://quirksmode.org/ QuirksMode], as well as the author’s understanding of the mobile devices market (see also the [https://github.com/dontcallmedom/canmymobilebrowser code used to generate the support icons])</li><br />
<li>a link to the latest editors draft of the document,</li><br />
<li>a link to the test suite for the said feature.</li><br />
</ul><br />
<br />
<br />
<p>As a reminder, W3C creates Web standards by progressing documents through its [http://www.w3.org/2005/10/Process-20051014/tr.html#Reports Recommendation track], with the following stages:</p><br />
<ul><br />
<li>“Editors drafts” represent the current view of the editors of the specification but have no standing in terms of standardization.</li><br />
<li>“Working Drafts” are early milestones of the Working Group progress.</li><br />
<li>“Last Call Working Drafts” signal that the Working Group has determined that the specification fulfills its requirements and all the known issues have been resolved, and thus requests feedback from the larger community.</li><br />
<li>“Candidate Recommendations” trigger a call for implementations where implementers are invited to implement the specification and send feedback; Working Groups are expected to show the specification gets implemented by running test suites they have developed.</li><br />
<li>“Proposed Recommendations” manifests that the group has gathered sufficient implementation experience, and triggers the final review by W3C Members</li><br />
<li>“W3C Recommendations” are stable and completed Web standards; these documents only get updated rarely, through the “Edited Recommendation” process, as a results from errata collected by Working Groups.</li><br />
</ul><br />
<p>Prior to starting standardization, a Working Group needs to be chartered, based on input from W3C Members, often through the organization of a [http://www.w3.org/2003/08/Workshops/ workshop], or after the reception of a [http://www.w3.org/Submission/ W3C Member Submission].</p><br />
<br />
<p>W3C has set up [http://www.w3.org/community/ Community Groups], a mechanism that allows anyone to do experimental work within the W3C infrastructure, under IPR rules that are compatible to transition the work to the W3C standardization process.</p><br />
== Graphics ==<br />
<p><strong>[http://www.w3.org/standards/techs/svg SVG]</strong>, Scalable Vector Graphics, provides an XML-based markup language to describe two-dimensions vector graphics. Since these graphics are described as a set of geometric shapes, they can be zoomed at the user request, which makes them well-suited to create graphics on mobile devices where screen space is limited. They can also be easily animated, enabling the creation of very advanced and slick user interfaces.</p><br />
<p>The integration of SVG in HTML5 opens up new possibilities, for instance applying advanced graphic filters (through SVG filters) to multimedia content, including videos. SVG 2.0 is set to facilitate that integration and complete the set of features in SVG.</p><br />
<br />
<p>In complement to the declarative approach provided by SVG, the <strong><code>&lt;canvas&gt;</code></strong> element added in HTML5 enables a [http://dev.w3.org/html5/2dcontext/ 2D programmatic API] that is well-suited for processing graphics in a less memory intensive way. That API not only allows rendering graphics, but can also be used to do image processing and analysis.</p><br />
<br />
<p>Both SVG and HTML can be styled using <strong>[http://www.w3.org/standards/techs/css CSS]</strong> (Cascading Style Sheets); in particular, CSS3 (the third level of the specification) is built as a collection of specifications set to offer a large number of new features that make it simple to create graphical effects, such as rounded corners, complex background images, shadow effects (<cite>[http://www.w3.org/TR/css3-background/ CSS Backgrounds and Borders]</cite>), rotated content (<cite>[http://www.w3.org/TR/css3-2d-transforms CSS 2D Transforms]</cite>), animations (<cite>[http://www.w3.org/TR/css3-animations CSS Animations]</cite>, <cite>[http://www.w3.org/TR/css3-transitions CSS Transitions]</cite>), and even 3D effects (<cite>[http://www.w3.org/TR/css3-3d-transforms CSS 3D Transforms]</cite>).</p><br />
<br />
<p>Animations can be resource intensive — the possibility offered by the <cite>[http://www.w3.org/TR/animation-timing/ Timing control for script-based animations API]</cite> to manage the rate of updates to animations can help keep them under control.</p><br />
<br />
<p>Fonts play also an important role in building appealing graphical interfaces, but mobile devices are in general distributed with only a limited set of fonts. <strong>[http://www.w3.org/TR/WOFF WOFF]</strong> (<cite>Web Open Font Format</cite>) addresses that limitation by making it easy to use fonts that are automatically downloaded through style sheets, while keeping the size of the downloaded fonts limited to what is actually needed to render the interface.</p><br />
<br />
<p>Another important aspect in graphics-intensive applications (e.g. games) is the possibility to use the entire screen to display the said graphics; the <strong><cite>[http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html Fullscreen API]</cite></strong> lets a Web application requests and detects full screen display.</p><br />
<br />
<p>Likewise, in these scenarios, it is often useful to be able to <strong>lock the orientation of the screen</strong>; the <cite>[http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html Screen Orientation API]</cite> allows not only to detect orientation change, but also to lock the orientation in a specific state.</p><br />
<br />
<p>NB: work on defining a [http://www.khronos.org/webgl/ 3D graphic API called WebGL] has started outside of W3C, as part of the [http://www.khronos.org/ Khronos Group]; this API has been built to be compatible with [http://www.khronos.org/opengles/ OpenGL ES], i.e. for embedded systems, and is intended to work on mobile devices.</p><br />
<br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th rowspan="2">2D Vector Graphics</th><td><cite>[http://www.w3.org/TR/SVGTiny12/ SVG Tiny 1.2]</cite></td><td rowspan="2">[http://www.w3.org/Graphics/SVG/ SVG Working Group]</td><td class="high maturity">Recommendation</td><td class="high">Finished</td><td>New version of SVG (SVG 2.0) in preparation</td><td class="high svg12">Widely deployed</td><td class="high">[http://www.w3.org/Graphics/SVG/Test/ High coverage]</td></tr><br />
<tr><td>[http://www.w3.org/TR/SVG2/ SVG 2]</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dev.w3.org/SVG/profiles/2.0/publish/index.html editors draft]</td><td class="low">N/A</td><td class="low">N/A</td></tr><br />
<tr><th>2D Programmatic API</th><td><cite>[http://www.w3.org/TR/2dcontext/ HTML Canvas 2D Context]</cite></td><td>[http://www.w3.org/html/wg/ HTML Working Group]</td><td class="medium maturity">Working Draft</td><td class="medium">Mostly stable</td><td>[http://dev.w3.org/html5/2dcontext/ Updated regularly]</td><td class="high canvas">Widely deployed</td><td class="medium">[http://w3c-test.org/html/tests/approved/canvas/ Good coverage]</td></tr><br />
<tr><th>Rounded Corners</th><td rowspan="3"><cite>[http://www.w3.org/TR/css3-background/ CSS Backgrounds and Borders]</cite></td><td rowspan="7">[http://www.w3.org/Style/CSS/members CSS Working Group]</td><td class="high maturity" rowspan="3">Candidate Recommendation</td><td class="high" rowspan="3">Mostly finished</td><td rowspan="3">[http://dev.w3.org/csswg/css3-background/ Updated regularly]</td><td class="high css-rounded">Deployed as an extension in many mobile browsers</td><td class="low" rowspan="3">None</td></tr><br />
<tr><th>Complex background images</th><td class="medium css-border">Growing deployment</td></tr><br />
<tr><th>Box shadow effects</th><td class="high css-boxshadow">Widely deployed</td></tr><br />
<tr><th>2D Effects</th><td rowspan="2"><cite>[http://www.w3.org/TR/css3-transforms/ CSS Transforms]</cite></td><td rowspan="2" class="low maturity">Working Draft</td><td class="medium">Mostly stable</td><td rowspan="2">[http://dev.w3.org/csswg/css3-transforms/ Latest update Aug 2012]</td><td class="high css-2d">Well deployed</td><td rowspan="2" class="medium">[http://test.csswg.org/harness/test/CSS3-TRANSFORMS_DEV/ Good coverage]</td></tr><br />
<tr><th>3D Effects</th><td class="low">Stabilizing</td><td class="medium css-3d">Growing deployment</td></tr><br />
<tr><th rowspan="3">Animations</th><td><cite>[http://www.w3.org/TR/css3-animations CSS Animations Module Level 3]</cite></td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dev.w3.org/csswg/css3-animations/ Updated regularly]</td><td class="medium css-animation">Growing deployment</td><td class="low">None</td></tr><br />
<tr><td><cite>[http://www.w3.org/TR/css3-transitions CSS Transitions Module Level 3]</cite></td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dev.w3.org/csswg/css3-transitions/ Latest update July 2012]</td><td class="high css-transitions">Well deployed</td><td class="low">None</td></tr><br />
<tr><td><cite>[http://www.w3.org/TR/animation-timing/ Timing control for script-based animations API]</cite></td><td>[http://www.w3.org/2010/webperf/ Web Performance Working Group]</td><td class="medium maturity">Last Call Working Draft</td><td class="medium">Stabilizing</td><td>[http://w3c-test.org/webperf/specs/RequestAnimationFrame/ Regularly updated]</td><td class="low animation-timing">Very limited</td><td class="low">[https://dvcs.w3.org/hg/webperf/file/tip/tests Started]</td></tr><br />
<tr><th>Downloadable fonts</th><td><cite>[http://www.w3.org/TR/WOFF WOFF File Format 1.0]</cite></td><td>[http://www.w3.org/Fonts/WG/ WebFonts Working Group]</td><td class="high maturity">Candidate Recommendation</td><td class="medium">Mostly stable</td><td>[http://dev.w3.org/webfonts/WOFF/spec/ Latest update Jan 2012]</td><td class="medium woff">Good deployment</td><td class="medium">[http://dev.w3.org/webfonts/WOFF/tests/Format/Tests/testcaseindex.xht Good coverage]</td></tr><br />
<tr><th>Fullscreen display</th><td><cite>[http://www.w3.org/TR/fullscreen/ Fullscreen API]</cite></td><td>[http://www.w3.org/2008/webapps/ Web Apps] and [http://www.w3.org/Style/CSS/members CSS] Working Groups</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html Regularly updated]</td><td class="low fullscreen">Very limited</td><td class="low">None</td></tr><br />
<tr><th>Orientation Lock</th><td><cite>[http://www.w3.org/TR/screen-orientation/ The Screen Orientation API]</cite></td><td>[http://www.w3.org/2008/webapps/ Web Apps Working Groups]</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html Regularly updated]</td><td class="low screenlock">Very limited</td><td class="low">None</td></tr><br />
</table><br />
<br />
== Multimedia ==<br />
<br />
<p>HTML5 adds two tags that dramatically improve the integration of multimedia content on the Web: the <code><strong>[http://dev.w3.org/html5/spec/video.html#video &lt;video>]</strong></code> and <code><strong>[http://dev.w3.org/html5/spec/video.html#audio &lt;audio>]</strong></code> tags. Respectively, these tags allow embedding video and audio content, and make it possible for Web developers to interact much more freely with that content than they would through plug-ins. They make multimedia content first-class citizens of the Web, the same way images have been for the past 15 years.</p><br />
<br />
<p>To cater for the needs of some content providers, a proposal to enable <strong>playback of protected content</strong>, <cite>[http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Encrypted Media Extensions]</cite> is an API that is under consideration in the [http://www.w3.org/html/wg/ HTML Working Group].</p><br />
<br />
<p>The <cite>[http://w3c-test.org/dap/gallery/ Pick Media Intent]</cite> offers a Web-intent based approach to search and retrieve <strong>locally or remotely stored media content</strong>, while the [http://w3c-test.org/dap/discovery-api/ <cite>Networked Service Discovery and Messaging</cite> API] opens the door for integrating DLNA-hosted content into Web applications.</p><br />
<br />
<p>While the new HTML5 tags allow to play multimedia content, the <cite>[http://dev.w3.org/2009/dap/camera/ HTML Media Capture]</cite> defines a <strong>markup-based mechanism to access captured multimedia content</strong> using attached camera and microphones, a very common feature on mobile devices. The [http://www.w3.org/2011/04/webrtc/ Web Real-Time Communications Working Group] and the [http://www.w3.org/2009/dap/ Device APIs Working Group] are building together an [http://dev.w3.org/2011/webrtc/editor/getusermedia.html API (<code>getUserMedia</code>)] to directly manipulate <strong>streams from camera and microphones</strong>.</p><br />
<br />
<p>Beyond recording, two additional APIs add multimedia manipulation capabilities to the Web platform. We have already mentioned the <cite>[http://dev.w3.org/html5/2dcontext/ Canvas 2D Context]</cite> API: it enables modifying images, which in turn opens up the possibility of <strong>video editing</strong>.</p><br />
<br />
<p>In a similar vein, the [http://www.w3.org/2011/audio/ Audio Working Group] is working on an API that that makes it possible to modify audio content, as well as <strong>analyze, modify and synthesize sounds</strong>, the [http://www.w3.org/TR/webaudio/ Web Audio API], in favor of which the competing proposal called [http://www.w3.org/TR/streamproc/ MediaStream Processing API] has been abandoned.</p><br />
<br />
<p>The combination of all these features marks the starting point of the Web as a comprehensive platform for multimedia, both for consuming and producing. The rising interest around bridging the Web and TV worlds (manifested through the [http://www.w3.org/2011/webtv/ W3C Web and TV Interest Group]) should strengthen that trend in the coming months. Mobile devices are expected to take a growing role in many users TV experience, providing a “second screen” experience, where users can find more information on or interact with a TV program they're watching via their mobile devices.</p><br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th>Video playback</th><td>[http://www.w3.org/TR/html5/video.html#video <cite>HTML5</cite> <code>video</code> element]</td><td rowspan="3">[http://www.w3.org/html/wg/ HTML Working Group]</td><td class="medium maturity">Working Draft</td><td rowspan="2" class="medium">Stabilizing</td><td rowspan="2">[http://dev.w3.org/html5/spec/video.html#video Updated regularly]</td><td class="medium video">Good deployment</td><td class="low">[http://w3c-test.org/html/tests/approved/video/ Just started]</td></tr><br />
<tr><th>Audio playback</th><td>[http://dev.w3.org/html5/spec/video.html#audio <cite>HTML5</cite> <code>audio</code> element]</td><td class="medium maturity">Last Call Working Draft</td><td class="medium audio">Good deployment</td><td class="low">[http://w3c-test.org/html/tests/approved/audio/ Barely started]</td></tr><br />
<tr><th>Protected content playback</th><td><cite>Encrypted Media Extensions</cite></td><td class="low maturity">N/A</td><td class="low">Early proposal</td><td>[http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html Latest update Aug 2012]</td><td class="low drm">None</td><td class="low">None</td></tr><br />
<tr><th rowspan="2">Multimedia Gallery access</th><td>[http://www.w3.org/TR/gallery/ Pick Media Intent]</td><td rowspan="2">[http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Early Web-intents based approach</td><td>[http://dev.w3.org/2009/dap/gallery/ Last updated Aug 2012]</td><td class="low gallery">None</td><td class="low">N/A</td></tr><br />
<tr><td>[http://www.w3.org/TR/discovery-api/ Networked Service Discovery and Messaging]</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://w3c-test.org/dap/discovery-api/ Last updated Aug 2012]</td><td class="low discovery">None</td><td class="low">None</td></tr><br />
<tr><th rowspan="2">Capturing audio/video</th><td><cite>[http://www.w3.org/TR/html-media-capture/ HTML Media Capture]</cite></td><td>[http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="medium maturity">Last Call Working Draft</td><td class="medium">Stabilizing</td><td>[http://dev.w3.org/2009/dap/camera/ Latest update July 2012]</td><td class="low inputaccept">Limited, but growing</td><td class="low">None</td></tr><br />
<tr><td>[http://www.w3.org/TR/mediacapture-streams/ Media Capture and Streams]</td><td>Joint work between [http://www.w3.org/2011/04/webrtc/ Web Real-Time Communications Working Group] and [http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Stabilizing, but still subject to large changes</td><td>[http://dev.w3.org/2011/webrtc/editor/getusermedia.html last updated Aug 2012]</td><td class="low getusermedia">A few experimental ones</td><td class="low">[https://dvcs.w3.org/hg/media-capture/file/tip/ Started]</td></tr><br />
<br />
<tr><th>Image &amp; Video analysis, modification</th><td><cite>[http://www.w3.org/TR/2dcontext/ HTML Canvas 2D Context]</cite></td><td>[http://www.w3.org/html/wg/ HTML Working Group]</td><td class="medium maturity">Working Draft</td><td class="medium">Mostly stable</td><td>[http://dev.w3.org/html5/2dcontext/ Updated regularly]</td><td class="high canvas">Widely deployed</td><td class="medium">[http://w3c-test.org/html/tests/approved/canvas/ Good coverage]</td></tr><br />
<tr><th rowspan="2">Audio analysis, modification</th><td><cite>[http://www.w3.org/TR/webaudio/ Web Audio API]</cite></td><td rowspan="2">[http://www.w3.org/2011/audio/ Audio Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Early work</td><td>[https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html Regularly updated]</td><td class="low webaudio">A couple</td><td class="low">None</td></tr><br />
<tr><td><cite>[http://www.w3.org/TR/streamproc/ MediaStream Processing API]</cite></td><td class="low maturity">Abandoned</td><td class="low">Abandoned</td><td>N/A</td><td class="low streamproc">None</td><td class="low">None</td></tr><br />
<br />
</table><br />
<br />
== Device Adaptation ==<br />
<br />
<p>Mobile devices not only differ widely from traditional computers, but they also have a lot of variations among themselves, in term of screen size, resolution, type of keyboard, media recording capabilities, etc.</p><br />
<p>The [http://www.w3.org/TR/DDR-Simple-API/ Device Description Repository API] is a unified server-side API that allows Web developers to retrieve data on the devices that are accessing their pages on a variety of device information database.</p><br />
<p>The [http://www.w3.org/wiki/Media_Capture Media Capture task force] is currently evaluating if and how to expose capabilities from camera and microphones to make it possible to take advantage of the large variety of media capturing devices provided on mobile phones.</p><br />
<p>[http://www.w3.org/TR/css3-mediaqueries/ CSS Media Queries] offer a mechanism that allows adapting the layout and behavior of a Web page based on some of the characteristics of the device, including the screen resolution. [http://dev.w3.org/csswg/css-device-adapt/ CSS Device Adaptation] defines a set of CSS directives to define the size on which this layout should be based, relatively to the size of the underlying device — specifying what has been implemented using the <code>&lt;meta name="viewport"&gt;</code> element so far.</p><br />
<br />
<p>The [http://www.w3.org/community/respimg/ Responsive Images Community Group] has been exploring proposals to make it possible to load and display images in HTML that are best adapted to the resolution of the device, and is now [http://lists.w3.org/Archives/Public/public-html/2012Jul/0123.html looking into incorporating] a [http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html <code>&lt;picture&gt;</code> element in HTML5].</p><br />
<br />
<p>Complementarily, the [http://www.w3.org/community/whatwg/ WHATWG] is discussing a [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html proposal for a <code>srcset</code> attribute] that would let Web developers define the various existing resolutions of an image, letting the browser pick the best choice for the resolution of the screen.</p><br />
<br />
<table class="simple" border="1"><br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th rowspan="2">Device information</th><td>[http://www.w3.org/TR/DDR-Simple-API/ Device Description Repository Simple API] (server-side)</td><td>Device Description Working Group (now closed)</td><td class="high maturity">Recommendation</td><td class="high">finished</td><td>N/A</td><td class="low">Limited</td><td class="high">[http://www.w3.org/2005/MWI/DDWG/drafts/api/test-report.html Good Coverage]</td></tr><br />
<tr><td>Media Capture Capabilities API</td><td>[http://www.w3.org/2011/04/webrtc/ WebRTC] and [http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="low">N/A</td><td class="low">Not started</td><td>N/A</td><td class="low">N/A</td><td class="low">N/A</td></tr><br />
<tr><th rowspan="2">CSS-based adaptation</th><td>[http://www.w3.org/TR/css3-mediaqueries/ Media Queries]</td><td rowspan="2">[http://www.w3.org/Style/CSS CSS Working Group]</td><td class="high maturity">Recommendation</td><td class="high">Finished</td><td>[http://dev.w3.org/csswg/css3-mediaqueries/ Latest update Apr 2012]</td><td class="high mediaqueries">Widely deployed</td><td class="high">[http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/ Good coverage]</td></tr><br />
<tr><td>[http://www.w3.org/TR/css-device-adapt/ CSS Device Adaptation]</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dev.w3.org/csswg/css-device-adapt/ Latest update Apr 2012]</td><td class="low css-device-adapt">Very limited</td><td class="low">N/A</td></tr><br />
<tr><th rowspan="2">Adaptive images</th><td><code>picture</code> element</td><td>[http://www.w3.org/html/ HTML Working Group]</td><td class="low maturity">N/A</td><td class="low">Proposal</td><td>[http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html Last updated Aug 2012]</td><td class="low picture">None</td><td class="low">N/A</td></tr><br />
<tr><td><code>srcset</code> attribute</td><td>[http://www.w3.org/community/whatwg/ WHATWG]</td><td class="low maturity">N/A</td><td class="low">Proposal</td><td>[http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset Regularly updated]</td><td class="low srcset">None</td><td class="low">None</td></tr><br />
</table><br />
<br />
== Forms ==<br />
<p>The ability to build rich forms with HTML is the basis for user input in most Web-based applications. Due to their limited keyboards, text input on mobile devices remains a difficult task for most users; <cite>[http://dev.w3.org/html5/spec/ HTML5]</cite> address parts of this problem by offering new type of form controls that optimize the way users will enter data:</p><br />
<ul><br />
<li><strong>[http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#date-and-time-state date and time entries]</strong> can take advantage of a number of dedicated form controls (e.g. <code>&lt;input type="date"&gt;</code>) where the user can use a native calendar control;</li><br />
<li>the <code>[http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#e-mail-state &lt;input type="<strong>email</strong>"&gt;]</code>, <code>[http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#telephone-state &lt;input type="<strong>tel</strong>"&gt;]</code> and <code>[http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#url-state &lt;input type="<strong>url</strong>"&gt;]</code> can be used to optimize the ways user enter these often-difficult to type data, e.g. through dedicated virtual keyboards, or by accessing on-device records for these data (from the address book, bookmarks, etc.);</li><br />
<li>the <code>[http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-pattern-attribute <strong>pattern</strong>]</code> attribute allows both to guide user input as well as to avoid server-side validation (which requires a network round-trip) or JavaScript-based validation (which takes up more resources);</li><br />
<li>the <code><strong>[http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-placeholder-attribute placeholder]</strong></code> attribute allows to guide user input by inserting hints as to what type of content is expected in a text-entry control;</li><br />
<li>the new <code>[http://dev.w3.org/html5/spec/the-button-element.html#the-datalist-element &lt;datalist&gt;]</code> element allows creating free-text input controls coming with <strong>pre-defined values</strong> the user can select from.</li><br />
</ul><br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th>Date and time entries</th><td>[http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-and-time-state <cite>HTML5</cite> Date and Time state of <code>input</code> element]</td><td rowspan="5">[http://www.w3.org/html/wg/ HTML Working Group]</td><td class="medium maturity">Working Draft</td><td class="medium">Stabilizing</td><td>[http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#date-and-time-state Updated regularly]</td><td class="low inputdate">Limited</td><td class="low">[http://w3c-test.org/html/tests/submission/MOSQUITO/input/ Just started]</td></tr><br />
<tr><th>Customized text entries (<code>tel</code>, <code>email</code>, <code>url</code>)</th><td>[http://www.w3.org/TR/html5/states-of-the-type-attribute.html#telephone-state <cite>HTML5</cite> telephone, email and URL state of <code>input</code> element]</td><td class="medium maturity">Working Draft</td><td class="medium">Stabilizing</td><td>[http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#telephone-state Updated regularly]</td><td class="medium inputtext">Limited, but growing</td><td class="low">None</td></tr><br />
<tr><th>Input pattern</th><td>[http://www.w3.org/TR/html5/common-input-element-attributes.html#the-pattern-attribute <cite>HTML5</cite> <code>pattern</code> attribute]</td><td class="medium maturity">Working Draft</td><td class="medium">Stabilizing</td><td>[http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-pattern-attribute Updated regularly]</td><td class="low inputpattern">Very limited</td><td class="low">[http://w3c-test.org/html/tests/submission/MOSQUITO/input/ Just started]</td></tr><br />
<tr><th>Input hint</th><td>[http://www.w3.org/TR/html5/common-input-element-attributes.html#the-placeholder-attribute <cite>HTML5</cite> <code>placeholder</code> attribute]</td><td class="medium maturity">Working Draft</td><td class="medium">Stabilizing</td><td>[http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-placeholder-attribute Updated regularly]</td><td class="high inputhint">Well deployed</td><td class="low">None</td></tr><br />
<tr><th>Pre-defined values for text entries</th><td>[http://www.w3.org/TR/html5/the-button-element.html#the-datalist-element <cite>HTML5</cite> <code>datalist</code> element]</td><td class="medium maturity">Working Draft</td><td class="medium">Stabilizing</td><td>[http://dev.w3.org/html5/spec/the-button-element.html#the-datalist-element Updated regularly]</td><td class="low datalist">Very limited</td><td class="low">None</td></tr><br />
<br />
</table><br />
<br />
== User interactions ==<br />
<br />
<p>An increasing share of mobile devices relies on touch-based interactions. While the traditional interactions recognized in the Web platform (keyboard, mouse input) can still be applied in this context, a more specific handling of touch-based input is a critical aspect of creating well-adapted user experiences, which <strong>[https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html Touch Events in the DOM]</strong> (Document Object Model) enable. The work on that specification is now nearly finished, as the [http://www.w3.org/2004/01/pp-impl/45559/status patents that had been disclosed] have been [http://www.w3.org/2012/te-pag/pagreport determined to not apply].</p><br />
<br />
<p>Conversely, many mobile devices use haptic feedback (such as vibration) to create new form of interactions (e.g. in games); work on a <strong>[http://dev.w3.org/2009/dap/vibration/ vibration API]</strong> in the [http://www.w3.org/2009/dap/ Device APIs Working Group] is making good progress.</p><br />
<br />
<p>But as the Web reaches new devices, and as devices gain new user interactions mechanisms, it also becomes important to allow Web developers to react to a more abstract set of user interactions: instead of having to work in terms of “click”, “key press”, or “touch event”, being able to react to an “undo” command, or a “next page” command independently of how the user instructed it to the device will prove beneficial to the development of device-independent Web applications. Work on <strong>abstract DOM events</strong> that would address this need is planned as part of a joint task force between the [http://www.w3.org/2010/webevents/ Web Events Working Group] and the [http://www.w3.org/WAI/IndieUI/ Indie UI Working Group].</p><br />
<br />
<p>Mobile devices follow their users everywhere, and many mobile users rely on them to remind them or notify them of events, such as messages: the <cite><strong>[http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html Web Notifications]</strong></cite> specification proposes to add that feature to the Web environment.</p><br />
<br />
<p>Mobile devices, and mobile phones in particular, are also in many cases well-suited to be used through voice-interactions; the [http://www.w3.org/community/speech-api/ <strong>Speech API Community Group</strong>] is exploring the opportunity of starting standardization work around a [http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html JavaScript API] that would make it possible for users to interact with a Web page through spoken commands.</p><br />
<br />
<p>The hardware constraints of mobile devices, and their different usage context can make [http://www.w3.org/WAI/mobile/experiences mobile users experience similar barriers to people with disabilities]. These similarities in barriers mean that similar solutions can be used to cater for them, [http://www.w3.org/WAI/mobile/overlap making a Web site accessible both for people with disabilities and mobile devices] a natural goal.</p><br />
<p>How Web Content Accessibility Guidelines (WCAG) and User Agent Accessibility Guidelines (UAAG) provide guidance on mobile accessibility &mdash; that is, making websites and applications more accessible to people with disabilities when they are using mobile phones and a broad range of other devices &mdash; is discussed in [http://www.w3.org/WAI/mobile/ Mobile Accessibility].</p><br />
<p>[http://www.w3.org/TR/wai-aria/ <cite>WAI-ARIA</cite>] provides semantic information on widgets, structures and behaviors hooks to make Web applications more accessible, including on mobile devices.</p><br />
<br />
<br />
<table class="simple" border="1"><br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th>Touch-based interactions</th><td>[http://www.w3.org/TR/touch-events/ Touch Events Specification]</td><td>[http://www.w3.org/2010/webevents/ Web Events Working Group]</td><td class="high maturity">Candidate Recommendation</td><td class="high">Mostly finished</td><td>[https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html Updated regularly]</td><td class="high touchevent">Largely deployed</td><td class="low">[http://w3c-test.org/webevents/tests/touch-events-v1/ Just started]</td></tr><br />
<tr><th>Vibration</th><td>[http://www.w3.org/TR/vibration/ Vibration API]</td><td>[http://www.w3.org/2009/dap/ Device API]</td><td class="high maturity">Candidate Recommendation</td><td class="High">Stable</td><td>[http://dev.w3.org/2009/dap/vibration/ Updated regularly]</td><td class="low vibration">Experimental implementations</td><td class="low">[http://w3c-test.org/dap/tests/vibration/ started]</td></tr><br />
<tr><th>Intent-based events</th><td>N/A</td><td>[http://www.w3.org/WAI/IndieUI/ Indie UI Working Group] and [http://www.w3.org/2010/webevents/ Web Events Working Group]</td><td class="low">N/A</td><td class="low">Not started</td><td>Not started</td><td class="low intents">None</td><td class="low">None</td></tr><br />
<tr><th>Notification</th><td>[http://www.w3.org/TR/notifications/ Web Notifications]</td><td>[http://www.w3.org/2010/web-notifications/ Web Notifications Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html Regularly updated]</td><td class="low notification">A few experimental ones</td><td class="low">None</td></tr><br />
<tr><th>Speech-based interactions</th><td>N/A</td><td>[http://www.w3.org/community/speech-api/ Speech API Community Group]</td><td class="low">N/A</td><td class="low">N/A</td><td>[http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html Regularly updated]</td><td class="low speechinput">N/A</td><td class="low">N/A</td></tr><br />
<tr><th>Model-based user interfaces</th><td>N/A</td><td>[http://www.w3.org/2011/mbui/ Model-Based User Interfaces Working Group]</td><td class="low">N/A</td><td class="low">N/A</td><td>[http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-20100504/ Model-based UI Incubator Group report]</td><td class="low">N/A</td><td class="low">N/A</td></tr><br />
<tr><br />
<th rowspan="2">Accessibility</th><br />
<td>[http://www.w3.org/TR/mwbp-wcag/ <cite>Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG)</cite>]</td><br />
<td>Mobile Web Best Practices Working Group &amp; Education and Outreach Working Group</td><br />
<td class="high maturity">Working Group Note</td><br />
<td class="high">Finished</td><br />
<td>N/A</td><br />
<td>N/A</td><br />
<td>N/A</td><br />
</tr><br />
<tr><br />
<td><cite>[http://www.w3.org/TR/wai-aria/ Accessible Rich Internet Applications (WAI-ARIA) 1.0]</cite></td><br />
<td>[http://www.w3.org/WAI/PF/ Protocols &amp; Formats Working Group]</td><br />
<td class="high maturity">Candidate Recommendation</td><br />
<td class="high">Stable</td><br />
<td>[http://www.w3.org/WAI/PF/aria/ Latest update May 2012]</td><br />
<td class="medium aria">Growing deployment</td><br />
<td class="low">None</td><br />
</tr><br />
</table><br />
<br />
== Data storage ==<br />
<p>A critical component of many applications is the ability to save state, export content, as well as integrate data from other files and services on the system.</p><br />
<p>For simple data storage, the <cite><strong>[http://dev.w3.org/html5/webstorage/ Web Storage]</strong></cite> specification offers two basic mechanisms, <code>localStorage</code> and <code>sessionStorage</code>, that can preserve data respectively indefinitely, or on a browser-session basis.</p><br />
<p>For richer interactions, the Web platform has a growing number of APIs to interact with a device filesystem: the <cite><strong>[http://dev.w3.org/2006/webapi/FileAPI/ File Reader API]</strong></cite> makes it possible to load the content of a file, the <cite><strong>[http://dev.w3.org/2009/dap/file-system/file-writer.html File Writer API]</strong></cite> allows saving or modifying a file, while the nascent <strong>[http://dev.w3.org/2009/dap/file-system/file-dir-sys.html FileSystems API]</strong> give access to more general file operations, including directory management.</p><br />
<p>On top of this file-based access, the <cite><strong>[http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html Indexed Database API]</strong></cite> defines a database of values and hierarchical objects that integrates naturally with JavaScript, and can be queried and updated very efficiently. Note that the work around a client-side SQL-based database, which had been started in 2009, has been abandoned in favor of this new system.</p><br />
<p>As more and more data need to be stored by the browser (e.g. for offline usage), it becomes critical for developers to get reliable storage space, which the proposed <strong>[http://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html Quota Mangement API]</strong> will offer to Web applications.</p><br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th>Simple data storage</th><td>[http://www.w3.org/TR/webstorage/ Web Storage]</td><td rowspan="7">[http://www.w3.org/2008/webapps/ Web Applications Working Group]</td><td class="high maturity">Candidate Recommendation</td><td class="high">Stable</td><td>[http://dev.w3.org/html5/webstorage/ Updated regularly]</td><td class="high webstorage">Well deployed</td><td class="medium">[http://w3c-test.org/webapps/WebStorage/tests/ Well started]</td></tr><br />
<tr><th>File reading</th><td>[http://www.w3.org/TR/FileAPI/ File API]</td><td class="low maturity">Working Draft</td><td class="medium">Stabilizing toward LC</td><td>[http://dev.w3.org/2006/webapi/FileAPI/ Regular updates]</td><td class="medium filereader">Growing</td><td class="low">None</td></tr><br />
<tr><th>File writing</th><td><cite>[http://www.w3.org/TR/file-writer-api/ File API: Writer]</cite></td><td class="low maturity">Working Draft</td><td class="low">Early draft (but starting to stabilize)</td><td>[http://dev.w3.org/2009/dap/file-system/file-writer.html Latest update Mar 2012]</td><td class="low filewrite">None</td><td class="low">None</td></tr><br />
<tr><th>Filesystems operations</th><td><cite>[http://www.w3.org/TR/file-system-api/ File API: Directories and System]</cite></td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dev.w3.org/2009/dap/file-system/file-dir-sys.html Latest update Mar 2012]</td><td class="low filesystem">None</td><td class="low">None</td></tr><br />
<tr><th rowspan="2">Database query/update</th><td><cite>[http://www.w3.org/TR/IndexedDB/ Indexed Database API]</cite></td><td class="medium maturity">Last Call Working Draft</td><td class="medium">Stabilizing</td><td>[http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html Regularly updated]</td><td class="medium indexeddb">Growing</td><td class="low">[http://w3c-test.org/webapps/IndexedDB/tests/ Started]</td></tr><br />
<tr><td>[http://www.w3.org/TR/webdatabase/ Web SQL API]</td><td class="low maturity">Working Group Note</td><td class="low">Abandoned</td><td>N/A</td><td class="medium websql">Somewhat deployed, but won’t be further deployed</td><td class="low">N/A</td></tr><br />
<tr><th>Quota for Storage</th><td><cite>[http://www.w3.org/TR/quota-api/ Quota Management API]</cite></td><td class="low maturity">Working Draft</td><td class="low">Early work</td><td>[http://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html Last updated June 2012]</td><td class="low">N/A</td><td class="low">N/A</td></tr><br />
</table><br />
<br />
== Personal Information Management ==<br />
<br />
<p>Applications can benefit from integrating with existing data records; on mobile devices, the address book and calendar are particularly useful source of information, which the <cite><strong>[http://dev.w3.org/2009/dap/contacts/ Contacts API]</strong></cite> and the <cite><strong>[http://dev.w3.org/2009/dap/calendar/ Calendar API]</strong></cite> bring access to.</p><br />
<br />
<p>The current JavaScript APIs are being replaced with an approach based on <cite>[http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html Web Intents]</cite>. A purely programmatic approach is also part of the proposed new [http://www.w3.org/2012/05/sysapps-wg-charter.html System Applications Working Group].</p><br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th>Address book data</th><td>[http://www.w3.org/TR/contacts-api/ Pick Contacts Intent]</td><td rowspan="2">[http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Early Web-intents based approach; a more complete API will be developed in the proposed new SysApps Working Group</td><td>[http://dev.w3.org/2009/dap/contacts/ Last updated Aug 2012]</td><td class="low contacts">None</td><td class="low">[http://w3c-test.org/dap/contacts/tests/ Early draft based on previous API]</td></tr><br />
<tr><th>Calendar data</th><td>[http://www.w3.org/TR/calendar-api/ Calendar API]</td><td class="low maturity">Working Draft</td><td class="low">Will likely change significantly</td><td>[http://dev.w3.org/2009/dap/calendar/ Regularly updated]</td><td class="low calendar">None</td><td class="low">None</td></tr><br />
<br />
</table><br />
<br />
== Sensors and hardware integration ==<br />
<br />
<p>Mobile devices are packed with sensors, making them a great bridge between the real and virtual worlds: GPS, accelerometer, ambient light detector, microphone, camera, thermometer, etc.</p><br />
<br />
<p>To take full advantage of these sensors in mobile Web applications, Web developers need to be provided with hooks to interact with them.</p><br />
<br />
<p>The <cite><strong>[http://dev.w3.org/geo/api/spec-source.html Geolocation API]</strong></cite> provides a common interface for locating the device, independently of the underlying technology (GPS, WIFI networks identification, triangulation in cellular networks, etc.) The proposed [http://www.w3.org/TR/geolocation-API-v2/ second version of that API] which would have added the ability to retrieve a civic address matching the user’s current location, has been [http://lists.w3.org/Archives/Public/public-geolocation/2012Mar/0023.html abandoned] due to lack of demand.</p><br />
<br />
<p>Web applications can also now access <strong>orientation and acceleration</strong> data via the <cite>[http://dev.w3.org/geo/api/spec-source-orientation.html DeviceOrientation Event Specification]</cite>.</p><br />
<br />
<p>The work on a generic <cite>[http://dev.w3.org/2009/dap/system-info/Sensors.html Sensor API]</cite> has been put on hold in favor to designing APIs for specific sensors, such as the [http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html <cite>Proximity Events</cite> API], the [http://dvcs.w3.org/hg/dap/raw-file/tip/light/Overview.html <cite>Ambient Light Events</cite> API] or the proposed [http://dvcs.w3.org/hg/dap/raw-file/tip/humidity/Overview.html <cite>Ambient Humidity Events</cite> API].</p><br />
<br />
<p>As already mentioned in the section on [[#Multimedia]], there is ongoing work on APIs to open up access to camera and microphone streams.</p><br />
<br />
<p>[http://lists.w3.org/Archives/Public/public-nfc/ Discussions on enabling Web applications to use <strong>Near-Field Communications (NFC)</strong>] mechanisms have led to a [http://www.w3.org/2012/05/nfc-wg-charter.html proposed charter for a dedicated Working Group], and would likely lead to the creation of a dedicated Working Group, currently under [http://lists.w3.org/Archives/Public/public-new-work/2012Jul/0009.html review by W3C Members].</p><br />
<br />
<p>A more global access to sensors and hardware (including USB and bluetooth) would be in scope for the proposed <strong>new [http://www.w3.org/2012/05/sysapps-wg-charter.html System Applications Working Group]</strong>, currently under [http://lists.w3.org/Archives/Public/public-new-work/2012Jul/0008.html review by W3C Members].</p><br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th rowspan="2">Geolocation</th><td><cite>[http://www.w3.org/TR/geolocation-API/ Geolocation API]</cite></td><td rowspan="3">[http://www.w3.org/2008/geolocation/ Geolocation Working Group]</td><td class="high maturity">Proposed Recommendation</td><td class="high">Mostly finished</td><td>[http://dev.w3.org/geo/api/spec-source.html Regularly updated]</td><td class="high geolocation">Widely deployed</td><td class="medium">[http://dev.w3.org/geo/api/test-suite/Overview.html Good coverage]</td></tr><br />
<tr><td><cite>[http://www.w3.org/TR/geolocation-API-v2/ Geolocation API v2]</cite></td><td class="low maturity">Abandoned</td><td class="low">Abandoned</td><td>N/A</td><td class="low">None</td><td class="low">N/A</td></tr><br />
<tr><th>Motion sensors</th><td><cite>[http://www.w3.org/TR/orientation-event/ DeviceOrientation Event Specification]</cite></td><td class="medium maturity">Last Call Working Draft</td><td class="medium">Stabilizing</td><td>[http://dev.w3.org/geo/api/spec-source-orientation.html Regularly updated]</td><td class="medium accelerometer">Growing</td><td class="low">[https://dvcs.w3.org/hg/geo/file/tip Started]</td></tr><br />
<tr><th>Battery Status</th><td><cite>[http://www.w3.org/TR/battery-status/ Battery Status API]</cite></td><td rowspan="4">[http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="high maturity">Candidate Recommendation</td><td class="high">Stable</td><td>[http://dev.w3.org/2009/dap/system-info/battery-status.html Updated regularly]</td><td class="low battery">Experimental implementations</td><td class="low">None</td></tr><br />
<tr><th>Proximity sensors</th><td><cite>[http://www.w3.org/TR/proximity/ Proximity Events]</cite></td><td class="low">Working Draft</td><td class="low">Early draft</td><td>[http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html Regularly updated]</td><td class="low proximity">A couple of experimental ones</td><td class="low">[https://github.com/marcoscaceres/proximitysensor/blob/master/DeviceProximityEvent_tests.js Started]</td></tr><br />
<tr><th>Ambient Light sensor</th><td><cite>[http://www.w3.org/TR/ambient-light/ Ambient Light Events]</cite></td><td class="low">Working Draft</td><td class="low">Early draft</td><td>[http://dvcs.w3.org/hg/dap/raw-file/tip/light/Overview.html Regularly updated]</td><td class="low ambientlight">None</td><td class="low">[http://dvcs.w3.org/hg/dap/file/89e088d0d774/light/tests Started]</td></tr><br />
<tr><th>Humidity sensor</th><td><cite>Ambient Humidity Events</cite></td><td class="low">N/A</td><td class="low">Unofficial draft</td><td>[http://dvcs.w3.org/hg/dap/raw-file/tip/humidity/Overview.html Last updated Aug 2012]</td><td class="low humidity">None</td><td class="low">N/A</td></tr><br />
<tr><th>Camera &amp; Microphone streams</th><td><cite>[http://www.w3.org/TR/mediacapture-streams/ Media Capture Streams]</cite></td><td>[http://www.w3.org/2011/04/webrtc/ Web Real-Time Communications Working Group] and [http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Stabilizing, but still subject to large changes</td><td>[http://dev.w3.org/2011/webrtc/editor/getusermedia.html Latest update Aug 2012 ]</td><td class="low getusermedia">A few experimental ones</td><td class="low">[https://dvcs.w3.org/hg/media-capture/file/tip/ Started]</td></tr><br />
<br />
<br />
</table><br />
<br />
== Network ==<br />
<br />
<p>Network connectivity represents a major asset for mobile devices: the Web is an immense store of content, as well as an almost endless source of processing power, overcoming two of the limitations of mobile devices.</p><br />
<br />
<p>The Web platform is growing a number of APIs that facilitate establishing network connectivity in different contexts.</p><br />
<br />
<p><cite><strong>[http://dev.w3.org/2006/webapi/XMLHttpRequest/ XMLHttpRequest]</strong></cite> (the “X” in AJAX) is a widely deployed API to load content from Web servers using the HTTP and HTTPs protocol: the W3C specification (formerly known as <cite>XMLHttpRequest Level 2</cite>) completes the existing deployed API with the ability to make requests on servers in a different domain, programmatic feedback on the progress of the network operations, and more efficient handling of binary content. The work on documenting the currently deployed API (XMLHttpRequest Level 1) has been abandoned in favor of getting the new API developed more quickly.</p><br />
<br />
<p>By default, browsers do not allow to make request across different domains (or more specifically, across different <em class="def">origins</em>, a combination of the protocol, domain and port) from a single Web page; this rule protects the user from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the <cite><strong>[http://dev.w3.org/2006/waf/access-control/ Cross-Origin Resource Sharing]</strong></cite> mechanism, opening up much wider cooperation across Web applications and services.</p><br />
<br />
<p>XMLHttpRequest is useful for client-initiated network requests, but mobile devices with their limited network capabilities and the cost that network requests induce on their battery (and sometimes on their users bill) can often make better use of server-initiated requests. The <cite><strong>[http://dev.w3.org/html5/eventsource/ Server-Sent Events]</strong></cite> API allows triggerring DOM events based on push notifications (via HTTP and other protocols.)</p><br />
<br />
<p>Early work on a <strong>[http://dvcs.w3.org/hg/push/raw-file/default/index.html Push API]</strong> would allow Web applications to receive server-sent messages whether or not the said Web app is active in a browser window.</p><br />
<br />
<p>The <cite><strong>[http://dev.w3.org/html5/websockets/ WebSocket API]</strong></cite>, built on top of the IETF <cite>[http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-05 WebSocket protocol]</cite>, offers a bidirectional, more flexible, and less resource intensive network connectivity than XMLHttpRequest.</p><br />
<br />
<p>The work on [http://www.w3.org/TR/webrtc/ Web Real-Time Communications] will also provide direct <strong>peer-to-peer data connections</strong> between browsers with real-time characteristics, opening the way to collaborative multi-devices Web applications.</p><br />
<br />
<p>Of course, an important part of using network connectivity relies on being able to determine if such connectivity exists, and the type of network available. The [http://dev.w3.org/html5/spec/offline.html#event-online HTML5 <strong>onLine DOM flag</strong>] (and its associated change event, <code>ononline</code>) signals when network connectivity is available to the Web environment.</p><br />
<br />
<p>The [http://dev.w3.org/2009/dap/netinfo/ <strong>network-information API</strong>] addresses discovery of the network characteristics, allowing to determine for instance the rough bandwidth of the current connection.</p><br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th>HTTP(s) network API</th><td><cite>[http://www.w3.org/TR/XMLHttpRequest/ XMLHttpRequest]</cite></td><td rowspan="5">[http://www.w3.org/2008/webapps/ Web Applications Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Still changing, but starting to stabilize</td><td>[http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Regularly updated]</td><td class="medium xhr2">Very broad for level 1 features, growing for level 2</td><td class="low">[http://w3c-test.org/webapps/XMLHttpRequest/tests/ Coverage of XMLHTTPRequest "level 1"]</td></tr><br />
<tr><th>Cross-domain requests</th><td><cite>[http://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]</cite></td><td class="medium maturity">Last Call Working Draft<td class="medium">Stable</td><td>[http://dev.w3.org/2006/waf/access-control/ Latest update May 2012]</td><td class="medium cors">Growing deployment</td><td class="low">[http://w3c-test.org/webapps/CORS/tests/ Started]</td></tr><br />
<tr><br />
<th rowspan="2">Server-pushed requests</th><br />
<td><cite>[http://www.w3.org/TR/eventsource/ Server-Sent Event]</cite><br />
</td><br />
<td class="medium maturity">Last Call Working Draft</td><br />
<td class="medium">Stabilizing</td><br />
<td>[http://dev.w3.org/html5/eventsource/ Regularly updated]<br />
</td><br />
<td class="medium eventsource">Growing</td><br />
<td class="low">None (?)</td><br />
</tr><br />
<tr><br />
<td><cite>Push API</cite></td><br />
<td class="low maturity">N/A</td><br />
<td class="low">Very early draft</td><br />
<td>[http://dvcs.w3.org/hg/push/raw-file/default/index.html Last updated Aug 2012]</td><br />
<td class="low">None</td><br />
<td class="low">N/A</td><br />
</tr><br />
<tr><th>Bidirectional connections</th><td><cite>[http://www.w3.org/TR/websockets/ The WebSocket API]</cite></td><td class="medium maturity">Last Call Working Draft</td><td class="high">Stable</td><td>[http://dev.w3.org/html5/websockets/ Regularly updated]</td><td class="medium websockets">Growing</td><td class="low">[http://w3c-test.org/webapps/WebSockets/tests/ Started]</td></tr><br />
<tr><th>P2P data connections</th><td><cite>[http://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]</cite></td><td>[http://www.w3.org/2011/04/webrtc/ Web Real-Time Communications Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td >[http://dev.w3.org/2011/webrtc/editor/webrtc.html Regularly updated]</td><td class="low p2p">None</td><td class="low">None</td></tr><br />
<tr><th>on-line state</th><td>[http://www.w3.org/TR/html5/offline.html#browser-state <cite>HTML5</cite> onLine DOM state]</td><td>[http://www.w3.org/html/wg/ HTML Working Group]</td><td class="medium maturity">Working Draft</td><td class="high">Mostly stable</td><td>[http://dev.w3.org/html5/spec/offline.html#event-online regularly updated]</td><td class="low online">Limited</td><td class="low">None</td></tr><br />
<tr><th>Network characteristics</th><td><cite>[http://www.w3.org/TR/netinfo-api/ The Network Information API]</cite></td><td>[http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://dev.w3.org/2009/dap/netinfo/ Regularly updated]</td><td class="low networkapi">Very limited</td><td class="low">None</td></tr><br />
<br />
<br />
</table><br />
<br />
== Communication and Discovery ==<br />
<br />
<p>Beyond connection to on-line services, allowing communications between users, but also between devices and between applications is an important aspect of a good mobile development platform. To communicate with unknown devices or pre-existing services, a discovery component is critical.</p><br />
<br />
<p>The <cite><strong>[http://dev.w3.org/2009/dap/messaging/ Messaging API]</strong></cite> completes the existing ability to create and send message through links (with <code>sms:</code>, <code>mms:</code> and <code>mailto:</code> URI schemes) with more control on adding attachments and the success of the message sending. At this time, this API is likely to be entirely replaced by an approach based on <cite>[http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html Web Intents]</cite>.</p><br />
<br />
<p>The <code><strong>postMessage</strong></code> API of <cite>[http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging]</cite> allows for Web Applications to communicate between each other.</p><br />
<br />
<p>Work has started in a joint task force of the Device APIs and Web Apps Working Groups that open up possibilities of closer integration of Web applications, as well as of Web applications with native applications via a mechanism called [http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html Web Intents].</p><br />
<br />
<p>The [http://w3c-test.org/dap/discovery-api/ Networked Service Discovery and Messaging] API offers to discover services on the local network (such as the ones offered via DLNA), enabling mobile Web applications to integrate seamlessly with these services.</p><br />
<br />
<p>The <strong>[http://www.w3.org/2011/04/webrtc/ Web Real-Time Communications Working Group]</strong> is the host of specifications for a wider set of communication opportunities:</p><br />
<ul><br />
<li><strong>Peer-to-peer connection</strong> across devices,</li><br />
<li><strong>P2P Audio and video streams</strong> allowing for real-time communications between users.</li><br />
</ul><br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th>Emails, SMS and MMS with generated attachments</th><td><cite>[http://www.w3.org/TR/messaging-api/ The Messaging API]</cite></td><td>[http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Candidate for replacement by a [http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html Web Intents]-based approach</td><td>[http://dev.w3.org/2009/dap/messaging/ Latest update July 2011]</td><td class="low messaging">None</td><td class="low">None</td></tr><br />
<tr><th>Inter-app communications</th><td><cite>[http://www.w3.org/TR/webmessaging/ HTML5 Web Messaging]</cite></td><td>[http://www.w3.org/2008/webapps/ Web Applications Working Group]</td><td class="high maturity">Candidate Recommendation</td><td class="high">Stable</td><td>[http://dev.w3.org/html5/postmsg/ Regularly updated]</td><td class="high postmessage">Well deployed</td><td class="low">[http://w3c-test.org/webapps/WebMessaging/tests/ Started]</td></tr><br />
<tr><th>Inter-app triggers</th><td>[http://www.w3.org/TR/web-intents/ Web Intents]</td><td>[http://www.w3.org/2009/dap/ Device APIs Working Group] and [http://www.w3.org/2008/webapps/ Web Apps Working Group]</td><td class="low">Working Draft</td><td class="low">Early draft</td><td>[http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html regularly updated]</td><td class="low intents">Experimental</td><td class="low">None</td></tr><br />
<tr><th>Networked services discovery</th><td>[http://www.w3.org/TR/discovery-api/ Networked Service Discovery and Messaging]</td><td>[http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="low maturity">Working Draft</td><td class="low">Early draft</td><td>[http://w3c-test.org/dap/discovery-api/ Last updated Aug 2012]</td><td class="low discovery">None</td><td class="low">None</td></tr><br />
<tr><th>P2P connections</th><td rowspan="2"><cite>[http://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]</cite></td><td rowspan="2">[http://www.w3.org/2011/04/webrtc/ Web Real-Time Communications Working Group]</td><td rowspan="2" class="low maturity">Working Draft</td><td rowspan="2" class="low">Early draft</td><td rowspan="2">[http://dev.w3.org/2011/webrtc/editor/webrtc.html Regularly updated]</td><td rowspan="2" class="low p2p">None</td><td rowspan="2" class="low">None</td></tr><br />
<tr><th>P2P Video/Audio streams</th></tr><br />
<br />
</table><br />
<br />
== Packaging ==<br />
<br />
<p>An important aspect of the user experience of applications is linked to how the user perceives the said application is available permanently (even when off-line, which is particularly important on mobile devices), as well as how it can be shared and distributed, typically through purchases via applications stores — this is adequately addressed by packaging the application.</p><br />
<br />
<p>The Web platform offers two complementary approaches to packaging Web applications:</p><br />
<ul><br />
<li>HTML5’s <code><strong>[http://dev.w3.org/html5/spec/offline.html#appcache ApplicationCache]</strong></code> enables access to Web applications off-line through the definition of a manifest of files that the browser is expected to keep in its cache;</li><br />
<li>the <strong>[http://www.w3.org/standards/techs/widgets W3C Widgets]</strong> family of specifications define technologies for distributing Web applications as Zip files which include a configuration file (see <cite>[http://www.w3.org/TR/widgets/ Widget Packaging and Configuration]</cite>); this configuration file enables the inclusion of additional features such as [http://www.w3.org/TR/widgets-digsig/ signature of applications] , controlled access to advanced APIs, [http://www.w3.org/TR/widgets-access/ restricted network usage], etc. In addition to aiding in the development of client-side Web applications for mobile devices, W3C Widgets have been used as server side-applications, standalone applications, daemons, starting point for hybrid Web/native applications, and as a Browser extension format.</li><br />
</ul><br />
<p>As part of its [http://www.w3.org/2008/webapps/charter/ new charter], the Web Apps Working Group is considering to work on an evolution of the Widgets configuration file based on a [http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html JSON format], although the [http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/thread.html#msg979 latest discussions on it] have established a likely dependency with the [http://www.w3.org/2012/05/sysapps-wg-charter.html proposed new System Applications Working Group].</p><br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th>Application Cache</th><td>[http://www.w3.org/TR/html5/offline.html#appcache <cite>HTML5</cite> Application Cache]</td><td>[http://www.w3.org/html/wg/ HTML Working Group]</td><td class="medium maturity">Working Draft</td><td class="low">Still changing but stabilizing</td><td>[http://dev.w3.org/html5/spec/offline.html#offline Regularly updated]</td><td class="high manifest">Well deployed</td><td class="low">None</td></tr><br />
<tr><th rowspan="3">Widgets</th><td>[http://www.w3.org/TR/widgets/ Widgets Packaging &amp; Configuration]</td><td rowspan="4">[http://www.w3.org/2008/webapps/ Web Applications Working Group]</td><td class="high maturity">Recommendation</td><td class="high">Finished</td><td>[http://dev.w3.org/2006/waf/widgets/ Latest update Aug 2011]</td><td class="low widgets">[http://dev.w3.org/2006/waf/widgets/imp-report/ 4 complete implementations; 1 impl 99%]</td><td class="high">[http://dev.w3.org/2006/waf/widgets/test-suite/ Full coverage]</td></tr><br />
<tr><td><cite>[http://www.w3.org/TR/widgets-digsig/ Digital Signatures for Widgets]</cite></td><td class="high maturity">Proposed Recommendation</td><td class="high">Finished</td><td>[http://dev.w3.org/2006/waf/widgets-digsig/ Latest update Aug 2011]</td><td class="low">[http://dev.w3.org/2006/waf/widgets-digsig/imp-report/ 2 or more implementations pass each test]</td><td class="high">[http://dev.w3.org/2006/waf/widgets-digsig/test-suite/ Full coverage]</td></tr><br />
<tr><td><cite>[http://www.w3.org/TR/widgets-access/ Widget Access Request Policy] (WARP)</cite></td><td class="high maturity">Recommendation</td><td class="high">Finished</td><td>[http://dev.w3.org/2006/waf/widgets-access/ Latest update Dec 2011]</td><td class="low">[http://dev.w3.org/2006/waf/widgets-access/imp-report/ 3 complete implementations; 1 impl 98%]</td><td class="high">[http://dev.w3.org/2006/waf/widgets-access/test-suite/ Full coverage]</td></tr><br />
<tr><th>Packaged Web App</th><td><cite>Web Application Manifest Format and Management APIs</cite></td><td class="low">N/A</td><td class="low">N/A</td><td>[http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html Last updated June 2012]</td><td class="low">N/A</td><td class="low">N/A</td></tr><br />
</table><br />
<br />
== Performance &amp; Optimization ==<br />
<br />
<p>Due to their limited CPU, and more importantly to their limited battery, mobile devices require a lot of attention in terms of performance.</p><br />
<br />
<p>The work started by the [http://www.w3.org/2010/webperf/ Web Performance Working Group] on <cite><strong>[http://w3c-test.org/webperf/specs/NavigationTiming/ Navigation Timing]</strong></cite>, <cite><strong>[http://w3c-test.org/webperf/specs/ResourceTiming/ Resource Timing]</strong></cite>, and more recently <cite><strong>[http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PerformanceTimeline/Overview.html Performance Timeline]</strong></cite> and <cite><strong>[https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.html User Timing]</strong></cite>, gives tools to Web developers for optimizing their Web applications. </p><br />
<br />
<p>The proposed work on [http://w3c-test.org/webperf/specs/setImmediate/ Efficient Script Yielding] offers the opportunity to Web developers to use more efficiently asynchronous programming.</p><br />
<br />
<p>The [http://www.w3.org/TR/page-visibility/ API to determine whether a Web page is being displayed] (<cite><strong>Page Visibility API</strong></cite>) can also be used to adapt the usage of resources to the need of the Web application, for instance by reducing network activity when the page is minimized. Likewise, the [http://www.w3.org/TR/animation-timing/ Timing control for script-based animations API] can help reduce the usage of resources needed for playing animations.</p><br />
<br />
<p>The [http://dev.w3.org/2009/dap/system-info/battery-status.html battery API] allows adjusting the use of resources to the current level of power available in the battery of a mobile device.</p><br />
<br />
<p>Beyond optimization of resources, the perceived reactivity of an application is also a critical aspect of the mobile user experience. The <strong>thread-like mechanism</strong> made possible via <cite>[http://dev.w3.org/html5/workers/ Web Workers]</cite> allows keeping the user interface responsive by offloading the most resource-intensive operations into a background process.</p><br />
<br />
<p>The <cite>[http://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices]</cite> provide general advice on how to build Web applications that work well on mobile devices, taking into account in particular the needs for optimization.</p><br />
<br />
<br />
<table class="simple" border="1"><br />
<br />
<tr><th>Feature</th><th>Specification</th><th>Working Group</th><th>Maturity</th><th>Stability</th><th>Latest editors draft</th><th>Current implementations</th><th>Test suite</th></tr><br />
<tr><th rowspan="4">Timing hooks</th><td>[http://www.w3.org/TR/navigation-timing/ Navigation Timing]</td><td rowspan="7">[http://www.w3.org/2010/webperf/ Web Performance Working Group]</td><td class="high maturity">Proposed Recommendation</td><td class="high">Mostly finished</td><td>[http://w3c-test.org/webperf/specs/NavigationTiming/ Regularly updated]</td><td class="medium nav-timing">Getting deployed</td><td class="medium">[http://w3c-test.org/webperf/tests/ Medium coverage]</td></tr><br />
<tr><td>[http://www.w3.org/TR/resource-timing/ Resource timing]</td><td class="high maturity">Candidate Recommendation</td><td class="high">Stable</td><td>[http://www.w3c-test.org/webperf/specs/ResourceTiming/ Regularly updated]</td><td class="low res-timing">None</td><td class="low">None</td></tr><br />
<tr><td>[http://www.w3.org/TR/performance-timeline/ Performance Timeline]</td><td class="high maturity">Candidate Recommendation</td><td class="medium">Stabilizing</td><td>[http://www.w3c-test.org/webperf/specs/PerformanceTimeline/ Regularly updated]</td><td class="low perf-timeline">None</td><td class="low">None</td></tr><br />
<tr><td>[http://www.w3.org/TR/user-timing/ User timing]</td><td class="high maturity">Candidate Recommendation</td><td class="high">Stable</td><td>[http://www.w3c-test.org/webperf/specs/UserTiming/ Regularly updated]</td><td class="low user-timing">None</td><td class="low">None</td></tr><br />
<tr><th>Priority handling</th><td>Efficient Script Yielding</td><td class="low">N/A</td><td class="low">Early draft</td><td>[http://w3c-test.org/webperf/specs/setImmediate/ Regularly updated]</td><td class="low setimmediate">Very limited</td><td class="low">None</td></tr><br />
<tr><th>Page Visibility detection</th><td><cite>[http://www.w3.org/TR/page-visibility/ Page visibility API]</cite><td class="high maturity">Candidate Recommendation</td><td class="high">Stable</td><td>[http://www.w3c-test.org/webperf/specs/PageVisibility/ Regularly updated]</td><td class="low visibilitychange">Very limited</td><td class="low">[https://dvcs.w3.org/hg/webperf/file/tip/tests Started]</td></tr><br />
<tr><th>Animation optimization</th><td><cite>[http://www.w3.org/TR/animation-timing/ Timing control for script-based animations]</cite><td class="medium maturity">Last Call Working Draft</td><td class="medium">Stabilizing</td><td>[http://w3c-test.org/webperf/specs/RequestAnimationFrame/ Regularly updated]</td><td class="low animation-timing">Very limited</td><td class="low">[https://dvcs.w3.org/hg/webperf/file/tip/tests Started]</td></tr><br />
<tr><th>Threading</th><td><cite>[http://www.w3.org/TR/workers/ Web Workers]</cite></td><td>[http://www.w3.org/2008/webapps/ Web Applications Working Group]</td><td class="high maturity">Candidate Recommendation</td><td class="high">Stable</td><td>[http://dev.w3.org/html5/workers/ Regularly updated]</td><td class="medium webworkers">Growing</td><td class="low">[http://w3c-test.org/webapps/Workers/tests/ Started]</td></tr><br />
<tr><th>Battery Status</th><td><cite>[http://www.w3.org/TR/battery-status/ Battery Status Events]</cite></td><td>[http://www.w3.org/2009/dap/ Device APIs Working Group]</td><td class="high maturity">Candidate Recommendation</td><td class="high">Stable</td><td>[http://dev.w3.org/2009/dap/system-info/battery-status.html Updated regularly]</td><td class="low battery">Very limited</td><td class="low">None</td></tr><br />
<tr><th>Optimization Best Practices</th><td><cite>[http://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices]</cite></td><td>[http://www.w3.org/2005/MWI/BPWG/ Mobile Web Best Practices Working Group] (now closed)</td><td class="high maturity">Recommendation</td><td class="high">Finished</td><td>N/A</td><td>N/A</td><td>N/A</td></tr><br />
<br />
</table></div>Hoschkahttps://www.w3.org/wiki/index.php?title=Web_and_Automotive&diff=60933Web and Automotive2012-09-20T10:04:03Z<p>Hoschka: </p>
<hr />
<div>'''The below is historic material'''<br />
<br />
'''Please check out [http://www.w3.org/2012/08/web-and-automotive/ W3C Web and Automotive Workshop page] for most news on this topic'''<br />
<br />
<br />
----<br />
<br />
<br />
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''<br />
<br />
This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive mailing list].<br />
<br />
== Web Applications in the Car ==<br />
<br />
The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.<br />
<br />
Web technologies have a significant edge over proprietary application development technologies.<br />
<br />
== Advantages of Web Applications ==<br />
<br />
* It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.<br />
* There is huge knowledge base already available on Web technologies.<br />
* In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.<br />
<br />
== Challenges to adopt Web Technology in the Car ==<br />
<br />
There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.<br />
<br />
<ul><br />
<li>Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.</li><br />
<li>Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs</li><br />
</ul><br />
<br />
=== Road map ===<br />
<br />
Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.<br />
<br />
We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.<br />
<br />
== How to get involved ==<br />
<br />
Please subscribe to the public mailing list [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive@w3.org]. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the [http://www.w3.org/Help/Account/ account request form].<br />
<br />
In case of further questions, please contact the following:<br />
<br />
* Dave Raggett <dsr@w3.org><br />
* Bernard Gidon <bgidon@w3.org><br />
<br />
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy].<br />
<br />
== Recent meetings ==<br />
<br />
* [[EIT-ICT Labs - 2012-04-23]]<br />
* [[GENIVI All Members meeting - 2012-04-26]]<br />
<br />
== Some relevant topics ==<br />
<br />
This is probably incomplete, and we welcome your comments and suggestions.<br />
<br />
=== Use Cases and Ecosystems ===<br />
<br />
Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.<br />
<br />
==== Example Applications ====<br />
<br />
This is a sampling of some of the applications we may expect:<br />
<br />
* Media player for local and streamed media<br />
* News and weather -- local, national, international, sports, business, arts, ...<br />
* SatNav with live traffic data and parking information<br />
* Location based search and advertising<br />
* Games -- for passengers<br />
* Social network apps -- tweets, posts, photos, location, ...<br />
* Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...<br />
* Custom enterprise apps<br />
* Car status -- fuel efficiency, servicing info, ...<br />
<br />
=== HTML5 ===<br />
<br />
With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?<br />
<br />
=== Application Packaging ===<br />
<br />
The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.<br />
<br />
=== Foreground Applications and Background Services ===<br />
<br />
In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of [http://dev.w3.org/html5/workers/ Web Workers] that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by [http://nodejs.org/ node.js] where services are defined in terms of event driven JavaScript modules and libraries of APIs. <br />
A related challenge is what is the most effective way for users to switch between applications?<br />
<br />
=== Multi-Device Applications ===<br />
<br />
In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?<br />
<br />
=== User input controls ===<br />
<br />
Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?<br />
<br />
=== Vocal and multimodal interfaces ===<br />
<br />
Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services? <br />
<br />
Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?<br />
<br />
=== Context Awareness ===<br />
<br />
How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.<br />
<br />
We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.<br />
<br />
=== Notifications ===<br />
<br />
How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's [http://www.w3.org/2010/web-notifications/ Web Notification Working Group].<br />
<br />
The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.<br />
<br />
=== Automotive Specific APIs ===<br />
<br />
What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?<br />
<br />
=== Security, Privacy and Trust ===<br />
<br />
The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.<br />
<br />
Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?<br />
<br />
One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.<br />
<br />
=== User Preferences ===<br />
<br />
Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.<br />
<br />
=== Advertising ===<br />
<br />
What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.<br />
<br />
=== Payments ===<br />
<br />
There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the [http://www.w3.org/wiki/Payments_Task_Force W3C Payments Task Force wiki].<br />
<br />
== Web and Automotive Workshop ==<br />
<br />
* [http://www.w3.org/2005/10/Process-20051014/events.html Process requirements for W3C Workshops]<br />
<br />
W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.<br />
<br />
At this time, the workshop is now expected to be during the '''2nd half of November 2012''', but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.<br />
<br />
=== Program Committee Members ===<br />
<br />
* James Ausmus, Intel<br />
* Diana Cheng, Vodafone<br />
* Virginie Galindo, Gemalto<br />
* Matthias Goebl, BMW<br />
* Andy Gryc, QNX<br />
* Wolfgang Haberl, BMW<br />
* Christopher Hilton, Harman<br />
* Nobuhide Kotsuka, KDDI<br />
* Roger C. Lanctot, Strategy Analytics<br />
* Håkon Lie, Opera Software<br />
* James McGinley, Intel<br />
* Maximilian Michel, BMW<br />
* Christian Müller, DFKI<br />
* Scott Pennock, QNX<br />
* Youngsun Ryu, Samsung<br />
* Ryuji Wakikawa, Toyota ITC</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Web_and_Automotive&diff=60917Web and Automotive2012-09-19T15:52:24Z<p>Hoschka: </p>
<hr />
<div>'''The below is historic material'''<br />
<br />
'''Please check out [http://www.w3.org/2012/08/web-and-automotive/link W3C Web and Automotive Workshop page] for most news on this topic'''<br />
<br />
<br />
----<br />
<br />
<br />
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''<br />
<br />
This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive mailing list].<br />
<br />
== Web Applications in the Car ==<br />
<br />
The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.<br />
<br />
Web technologies have a significant edge over proprietary application development technologies.<br />
<br />
== Advantages of Web Applications ==<br />
<br />
* It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.<br />
* There is huge knowledge base already available on Web technologies.<br />
* In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.<br />
<br />
== Challenges to adopt Web Technology in the Car ==<br />
<br />
There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.<br />
<br />
<ul><br />
<li>Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.</li><br />
<li>Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs</li><br />
</ul><br />
<br />
=== Road map ===<br />
<br />
Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.<br />
<br />
We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.<br />
<br />
== How to get involved ==<br />
<br />
Please subscribe to the public mailing list [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive@w3.org]. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the [http://www.w3.org/Help/Account/ account request form].<br />
<br />
In case of further questions, please contact the following:<br />
<br />
* Dave Raggett <dsr@w3.org><br />
* Bernard Gidon <bgidon@w3.org><br />
<br />
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy].<br />
<br />
== Recent meetings ==<br />
<br />
* [[EIT-ICT Labs - 2012-04-23]]<br />
* [[GENIVI All Members meeting - 2012-04-26]]<br />
<br />
== Some relevant topics ==<br />
<br />
This is probably incomplete, and we welcome your comments and suggestions.<br />
<br />
=== Use Cases and Ecosystems ===<br />
<br />
Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.<br />
<br />
==== Example Applications ====<br />
<br />
This is a sampling of some of the applications we may expect:<br />
<br />
* Media player for local and streamed media<br />
* News and weather -- local, national, international, sports, business, arts, ...<br />
* SatNav with live traffic data and parking information<br />
* Location based search and advertising<br />
* Games -- for passengers<br />
* Social network apps -- tweets, posts, photos, location, ...<br />
* Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...<br />
* Custom enterprise apps<br />
* Car status -- fuel efficiency, servicing info, ...<br />
<br />
=== HTML5 ===<br />
<br />
With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?<br />
<br />
=== Application Packaging ===<br />
<br />
The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.<br />
<br />
=== Foreground Applications and Background Services ===<br />
<br />
In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of [http://dev.w3.org/html5/workers/ Web Workers] that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by [http://nodejs.org/ node.js] where services are defined in terms of event driven JavaScript modules and libraries of APIs. <br />
A related challenge is what is the most effective way for users to switch between applications?<br />
<br />
=== Multi-Device Applications ===<br />
<br />
In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?<br />
<br />
=== User input controls ===<br />
<br />
Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?<br />
<br />
=== Vocal and multimodal interfaces ===<br />
<br />
Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services? <br />
<br />
Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?<br />
<br />
=== Context Awareness ===<br />
<br />
How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.<br />
<br />
We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.<br />
<br />
=== Notifications ===<br />
<br />
How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's [http://www.w3.org/2010/web-notifications/ Web Notification Working Group].<br />
<br />
The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.<br />
<br />
=== Automotive Specific APIs ===<br />
<br />
What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?<br />
<br />
=== Security, Privacy and Trust ===<br />
<br />
The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.<br />
<br />
Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?<br />
<br />
One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.<br />
<br />
=== User Preferences ===<br />
<br />
Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.<br />
<br />
=== Advertising ===<br />
<br />
What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.<br />
<br />
=== Payments ===<br />
<br />
There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the [http://www.w3.org/wiki/Payments_Task_Force W3C Payments Task Force wiki].<br />
<br />
== Web and Automotive Workshop ==<br />
<br />
* [http://www.w3.org/2005/10/Process-20051014/events.html Process requirements for W3C Workshops]<br />
<br />
W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.<br />
<br />
At this time, the workshop is now expected to be during the '''2nd half of November 2012''', but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.<br />
<br />
=== Program Committee Members ===<br />
<br />
* James Ausmus, Intel<br />
* Diana Cheng, Vodafone<br />
* Virginie Galindo, Gemalto<br />
* Matthias Goebl, BMW<br />
* Andy Gryc, QNX<br />
* Wolfgang Haberl, BMW<br />
* Christopher Hilton, Harman<br />
* Nobuhide Kotsuka, KDDI<br />
* Roger C. Lanctot, Strategy Analytics<br />
* Håkon Lie, Opera Software<br />
* James McGinley, Intel<br />
* Maximilian Michel, BMW<br />
* Christian Müller, DFKI<br />
* Scott Pennock, QNX<br />
* Youngsun Ryu, Samsung<br />
* Ryuji Wakikawa, Toyota ITC</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Web_and_Automotive&diff=60916Web and Automotive2012-09-19T15:51:27Z<p>Hoschka: </p>
<hr />
<div>'''Historic material'''<br />
<br />
'''Please check out [http://www.w3.org/2012/08/web-and-automotive/link W3C Web and Automotive Workshop page] for most news on this topic'''<br />
<br />
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''<br />
<br />
This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive mailing list].<br />
<br />
== Web Applications in the Car ==<br />
<br />
The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.<br />
<br />
Web technologies have a significant edge over proprietary application development technologies.<br />
<br />
== Advantages of Web Applications ==<br />
<br />
* It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.<br />
* There is huge knowledge base already available on Web technologies.<br />
* In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.<br />
<br />
== Challenges to adopt Web Technology in the Car ==<br />
<br />
There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.<br />
<br />
<ul><br />
<li>Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.</li><br />
<li>Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs</li><br />
</ul><br />
<br />
=== Road map ===<br />
<br />
Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.<br />
<br />
We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.<br />
<br />
== How to get involved ==<br />
<br />
Please subscribe to the public mailing list [http://lists.w3.org/Archives/Public/public-automotive/ public-automotive@w3.org]. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the [http://www.w3.org/Help/Account/ account request form].<br />
<br />
In case of further questions, please contact the following:<br />
<br />
* Dave Raggett <dsr@w3.org><br />
* Bernard Gidon <bgidon@w3.org><br />
<br />
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy].<br />
<br />
== Recent meetings ==<br />
<br />
* [[EIT-ICT Labs - 2012-04-23]]<br />
* [[GENIVI All Members meeting - 2012-04-26]]<br />
<br />
== Some relevant topics ==<br />
<br />
This is probably incomplete, and we welcome your comments and suggestions.<br />
<br />
=== Use Cases and Ecosystems ===<br />
<br />
Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.<br />
<br />
==== Example Applications ====<br />
<br />
This is a sampling of some of the applications we may expect:<br />
<br />
* Media player for local and streamed media<br />
* News and weather -- local, national, international, sports, business, arts, ...<br />
* SatNav with live traffic data and parking information<br />
* Location based search and advertising<br />
* Games -- for passengers<br />
* Social network apps -- tweets, posts, photos, location, ...<br />
* Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...<br />
* Custom enterprise apps<br />
* Car status -- fuel efficiency, servicing info, ...<br />
<br />
=== HTML5 ===<br />
<br />
With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?<br />
<br />
=== Application Packaging ===<br />
<br />
The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.<br />
<br />
=== Foreground Applications and Background Services ===<br />
<br />
In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of [http://dev.w3.org/html5/workers/ Web Workers] that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by [http://nodejs.org/ node.js] where services are defined in terms of event driven JavaScript modules and libraries of APIs. <br />
A related challenge is what is the most effective way for users to switch between applications?<br />
<br />
=== Multi-Device Applications ===<br />
<br />
In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?<br />
<br />
=== User input controls ===<br />
<br />
Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?<br />
<br />
=== Vocal and multimodal interfaces ===<br />
<br />
Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services? <br />
<br />
Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?<br />
<br />
=== Context Awareness ===<br />
<br />
How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.<br />
<br />
We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.<br />
<br />
=== Notifications ===<br />
<br />
How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's [http://www.w3.org/2010/web-notifications/ Web Notification Working Group].<br />
<br />
The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.<br />
<br />
=== Automotive Specific APIs ===<br />
<br />
What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?<br />
<br />
=== Security, Privacy and Trust ===<br />
<br />
The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.<br />
<br />
Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?<br />
<br />
One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.<br />
<br />
=== User Preferences ===<br />
<br />
Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.<br />
<br />
=== Advertising ===<br />
<br />
What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.<br />
<br />
=== Payments ===<br />
<br />
There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the [http://www.w3.org/wiki/Payments_Task_Force W3C Payments Task Force wiki].<br />
<br />
== Web and Automotive Workshop ==<br />
<br />
* [http://www.w3.org/2005/10/Process-20051014/events.html Process requirements for W3C Workshops]<br />
<br />
W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.<br />
<br />
At this time, the workshop is now expected to be during the '''2nd half of November 2012''', but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.<br />
<br />
=== Program Committee Members ===<br />
<br />
* James Ausmus, Intel<br />
* Diana Cheng, Vodafone<br />
* Virginie Galindo, Gemalto<br />
* Matthias Goebl, BMW<br />
* Andy Gryc, QNX<br />
* Wolfgang Haberl, BMW<br />
* Christopher Hilton, Harman<br />
* Nobuhide Kotsuka, KDDI<br />
* Roger C. Lanctot, Strategy Analytics<br />
* Håkon Lie, Opera Software<br />
* James McGinley, Intel<br />
* Maximilian Michel, BMW<br />
* Christian Müller, DFKI<br />
* Scott Pennock, QNX<br />
* Youngsun Ryu, Samsung<br />
* Ryuji Wakikawa, Toyota ITC</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=59576Network-Friendly-WebApps2012-06-11T11:33:26Z<p>Hoschka: /* Background Material on Issue to Solve */</p>
<hr />
<div><br />
=Network-Friendly WebApps Headlights Project: Introduction=<br />
<br />
'''Led by Philipp Hoschka <ph@w3.org>'''<br />
<br />
In February 2012, as part of GSMA's [http://http://gsma.com/smarterapp Smarter Applications] Technical project, the GSMA has published guidelines entitled "[http://www.gsma.com/technicalprojects/wp-content/uploads/2012/04/gsmasmarterappsforsmarterphones0112v.0.14.pdf Smarter Apps for Smarter Phones!]" for mobile applications in general, initially focusing on native applications. The document aims to "enable improvements across a number of areas including application connectivity, power consumption, network reliability and security." To enhance the document's relevance, a W3C community group on "[http://www.w3.org/community/networkfriendly/ Network-Friendly App and WebApp Best Practices]" was created to gather input from the Web community for the document's update to be released by end of 2012.<br />
<br />
With the rising importance of mobile Web applications, it is worth to look at whether W3C should work on guidelines specifically focusing on mobile Web applications, based on and complementing the existing GSMA guidelines for native applications.<br />
<br />
This could take the form of an update of or companion to the W3C "[http://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices]" standard, published in December 2010.<br />
<br />
The GSMA and others are currently also pursuing other technical approaches to improve the "network friendliness" of mobile applications, some of which could also be candidate for W3C standardization.<br />
<br />
=Input Contributions=<br />
<br />
AT&T input: [[File:ac2012-Network-Friendly-Webapps.pdf]]<br />
<br />
=Background Material on Issue to Solve=<br />
<br />
[http://mobile.bloomberg.com/news/2012-06-05/french-open-date-demands-spur-network-congestion-fix?category=%2F French Open Data Demand Spurs Network Congestion Fix]<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch What's really causing the capacity crunch?]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
<br />
<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09<br />
* "While data traffic is also growing, by many accounts, signaling traffic is outpacing actual mobile data traffic by 30 percent to 50 percent, if not higher, Thelander said. For instance, a Yahoo IM user may send a message but then wait a couple of seconds between messages. To preserve battery life, the smartphone moves into idle mode. When the user pushes another message seconds later, the device has to set up a signaling path again.<br />
"Smartphones are causing a problem, but it isn't data usage," Thelander said. "The base station controller is spending a lot of its resources trying to process the signaling so it can't do other things like allocate additional resources for data. You'll see dropped calls and data service degradation."<br />
Read more: What's really causing the capacity crunch? - FierceWireless http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch#ixzz1uhMaqBsH<br />
<br />
=Technical work beyond Best Practices=<br />
<br />
*[http://ddpsdk.net/tm/w3c/eventsource-push.html EventSource API Connectionless Push Extension (Proposal)]</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58948Network-Friendly-WebApps2012-05-13T20:18:45Z<p>Hoschka: /* Background Material */</p>
<hr />
<div><br />
=Network-Friendly WebApps Headlights Project: Introduction=<br />
<br />
'''Led by Philipp Hoschka <ph@w3.org>'''<br />
<br />
In February 2012, as part of GSMA's [http://http://gsma.com/smarterapp Smarter Applications] Technical project, the GSMA has published guidelines entitled "[http://www.gsma.com/technicalprojects/wp-content/uploads/2012/04/gsmasmarterappsforsmarterphones0112v.0.14.pdf Smarter Apps for Smarter Phones!]" for mobile applications in general, initially focusing on native applications. The document aims to "enable improvements across a number of areas including application connectivity, power consumption, network reliability and security." To enhance the document's relevance, a W3C community group on "[http://www.w3.org/community/networkfriendly/ Network-Friendly App and WebApp Best Practices]" was created to gather input from the Web community for the document's update to be released by end of 2012.<br />
<br />
With the rising importance of mobile Web applications, it is worth to look at whether W3C should work on guidelines specifically focusing on mobile Web applications, based on and complementing the existing GSMA guidelines for native applications.<br />
<br />
This could take the form of an update of or companion to the W3C "[http://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices]" standard, published in December 2010.<br />
<br />
The GSMA and others are currently also pursuing other technical approaches to improve the "network friendliness" of mobile applications, some of which could also be candidate for W3C standardization.<br />
<br />
=Input Contributions=<br />
<br />
AT&T input: [[File:ac2012-Network-Friendly-Webapps.pdf]]<br />
<br />
=Background Material on Issue to Solve=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch What's really causing the capacity crunch?]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
<br />
<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09<br />
* "While data traffic is also growing, by many accounts, signaling traffic is outpacing actual mobile data traffic by 30 percent to 50 percent, if not higher, Thelander said. For instance, a Yahoo IM user may send a message but then wait a couple of seconds between messages. To preserve battery life, the smartphone moves into idle mode. When the user pushes another message seconds later, the device has to set up a signaling path again.<br />
"Smartphones are causing a problem, but it isn't data usage," Thelander said. "The base station controller is spending a lot of its resources trying to process the signaling so it can't do other things like allocate additional resources for data. You'll see dropped calls and data service degradation."<br />
Read more: What's really causing the capacity crunch? - FierceWireless http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch#ixzz1uhMaqBsH<br />
<br />
=Technical work beyond Best Practices=<br />
<br />
*[http://ddpsdk.net/tm/w3c/eventsource-push.html EventSource API Connectionless Push Extension (Proposal)]</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58947Network-Friendly-WebApps2012-05-13T20:14:16Z<p>Hoschka: /* Background Material (incomplete) */</p>
<hr />
<div><br />
=Network-Friendly WebApps Headlights Project: Introduction=<br />
<br />
'''Led by Philipp Hoschka <ph@w3.org>'''<br />
<br />
In February 2012, as part of GSMA's [http://http://gsma.com/smarterapp Smarter Applications] Technical project, the GSMA has published guidelines entitled "[http://www.gsma.com/technicalprojects/wp-content/uploads/2012/04/gsmasmarterappsforsmarterphones0112v.0.14.pdf Smarter Apps for Smarter Phones!]" for mobile applications in general, initially focusing on native applications. The document aims to "enable improvements across a number of areas including application connectivity, power consumption, network reliability and security." To enhance the document's relevance, a W3C community group on "[http://www.w3.org/community/networkfriendly/ Network-Friendly App and WebApp Best Practices]" was created to gather input from the Web community for the document's update to be released by end of 2012.<br />
<br />
With the rising importance of mobile Web applications, it is worth to look at whether W3C should work on guidelines specifically focusing on mobile Web applications, based on and complementing the existing GSMA guidelines for native applications.<br />
<br />
This could take the form of an update of or companion to the W3C "[http://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices]" standard, published in December 2010.<br />
<br />
The GSMA and others are currently also pursuing other technical approaches to improve the "network friendliness" of mobile applications, some of which could also be candidate for W3C standardization.<br />
<br />
=Input Contributions=<br />
<br />
AT&T input: [[File:ac2012-Network-Friendly-Webapps.pdf]]<br />
<br />
=Background Material=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch What's really causing the capacity crunch?]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
<br />
<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09<br />
* "While data traffic is also growing, by many accounts, signaling traffic is outpacing actual mobile data traffic by 30 percent to 50 percent, if not higher, Thelander said. For instance, a Yahoo IM user may send a message but then wait a couple of seconds between messages. To preserve battery life, the smartphone moves into idle mode. When the user pushes another message seconds later, the device has to set up a signaling path again.<br />
"Smartphones are causing a problem, but it isn't data usage," Thelander said. "The base station controller is spending a lot of its resources trying to process the signaling so it can't do other things like allocate additional resources for data. You'll see dropped calls and data service degradation."<br />
Read more: What's really causing the capacity crunch? - FierceWireless http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch#ixzz1uhMaqBsH<br />
<br />
=Technical work beyond Best Practices=<br />
<br />
*[http://ddpsdk.net/tm/w3c/eventsource-push.html EventSource API Connectionless Push Extension (Proposal)]</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58946Network-Friendly-WebApps2012-05-13T20:12:56Z<p>Hoschka: /* Input Contributions */</p>
<hr />
<div><br />
=Network-Friendly WebApps Headlights Project: Introduction=<br />
<br />
'''Led by Philipp Hoschka <ph@w3.org>'''<br />
<br />
In February 2012, as part of GSMA's [http://http://gsma.com/smarterapp Smarter Applications] Technical project, the GSMA has published guidelines entitled "[http://www.gsma.com/technicalprojects/wp-content/uploads/2012/04/gsmasmarterappsforsmarterphones0112v.0.14.pdf Smarter Apps for Smarter Phones!]" for mobile applications in general, initially focusing on native applications. The document aims to "enable improvements across a number of areas including application connectivity, power consumption, network reliability and security." To enhance the document's relevance, a W3C community group on "[http://www.w3.org/community/networkfriendly/ Network-Friendly App and WebApp Best Practices]" was created to gather input from the Web community for the document's update to be released by end of 2012.<br />
<br />
With the rising importance of mobile Web applications, it is worth to look at whether W3C should work on guidelines specifically focusing on mobile Web applications, based on and complementing the existing GSMA guidelines for native applications.<br />
<br />
This could take the form of an update of or companion to the W3C "[http://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices]" standard, published in December 2010.<br />
<br />
The GSMA and others are currently also pursuing other technical approaches to improve the "network friendliness" of mobile applications, some of which could also be candidate for W3C standardization.<br />
<br />
=Input Contributions=<br />
<br />
AT&T input: [[File:ac2012-Network-Friendly-Webapps.pdf]]<br />
<br />
=Background Material (incomplete)=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch What's really causing the capacity crunch?]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
<br />
<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09<br />
* "While data traffic is also growing, by many accounts, signaling traffic is outpacing actual mobile data traffic by 30 percent to 50 percent, if not higher, Thelander said. For instance, a Yahoo IM user may send a message but then wait a couple of seconds between messages. To preserve battery life, the smartphone moves into idle mode. When the user pushes another message seconds later, the device has to set up a signaling path again.<br />
"Smartphones are causing a problem, but it isn't data usage," Thelander said. "The base station controller is spending a lot of its resources trying to process the signaling so it can't do other things like allocate additional resources for data. You'll see dropped calls and data service degradation."<br />
Read more: What's really causing the capacity crunch? - FierceWireless http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch#ixzz1uhMaqBsH<br />
<br />
=Technical work beyond Best Practices=<br />
<br />
*[http://ddpsdk.net/tm/w3c/eventsource-push.html EventSource API Connectionless Push Extension (Proposal)]</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58944Network-Friendly-WebApps2012-05-13T15:47:35Z<p>Hoschka: /* Technical work beyond Best Practices */</p>
<hr />
<div><br />
=Input Contributions=<br />
<br />
AT&T input: [[File:ac2012-Network-Friendly-Webapps.pdf]]<br />
<br />
=Background Material (incomplete)=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch What's really causing the capacity crunch?]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
<br />
<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09<br />
* "While data traffic is also growing, by many accounts, signaling traffic is outpacing actual mobile data traffic by 30 percent to 50 percent, if not higher, Thelander said. For instance, a Yahoo IM user may send a message but then wait a couple of seconds between messages. To preserve battery life, the smartphone moves into idle mode. When the user pushes another message seconds later, the device has to set up a signaling path again.<br />
"Smartphones are causing a problem, but it isn't data usage," Thelander said. "The base station controller is spending a lot of its resources trying to process the signaling so it can't do other things like allocate additional resources for data. You'll see dropped calls and data service degradation."<br />
Read more: What's really causing the capacity crunch? - FierceWireless http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch#ixzz1uhMaqBsH<br />
<br />
=Technical work beyond Best Practices=<br />
<br />
*[http://ddpsdk.net/tm/w3c/eventsource-push.html EventSource API Connectionless Push Extension (Proposal)]</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58943Network-Friendly-WebApps2012-05-13T15:47:10Z<p>Hoschka: /* Impressive Case Studies */</p>
<hr />
<div><br />
=Input Contributions=<br />
<br />
AT&T input: [[File:ac2012-Network-Friendly-Webapps.pdf]]<br />
<br />
=Background Material (incomplete)=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch What's really causing the capacity crunch?]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
<br />
=Technical work beyond Best Practices=<br />
<br />
*[http://ddpsdk.net/tm/w3c/eventsource-push.html EventSource API Connectionless Push Extension (Proposal)]<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09<br />
* "While data traffic is also growing, by many accounts, signaling traffic is outpacing actual mobile data traffic by 30 percent to 50 percent, if not higher, Thelander said. For instance, a Yahoo IM user may send a message but then wait a couple of seconds between messages. To preserve battery life, the smartphone moves into idle mode. When the user pushes another message seconds later, the device has to set up a signaling path again.<br />
"Smartphones are causing a problem, but it isn't data usage," Thelander said. "The base station controller is spending a lot of its resources trying to process the signaling so it can't do other things like allocate additional resources for data. You'll see dropped calls and data service degradation."<br />
Read more: What's really causing the capacity crunch? - FierceWireless http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch#ixzz1uhMaqBsH</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58940Network-Friendly-WebApps2012-05-13T07:46:17Z<p>Hoschka: /* Background Material (incomplete) */</p>
<hr />
<div><br />
=Input Contributions=<br />
<br />
AT&T input: [[File:ac2012-Network-Friendly-Webapps.pdf]]<br />
<br />
=Background Material (incomplete)=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch What's really causing the capacity crunch?]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09<br />
* "While data traffic is also growing, by many accounts, signaling traffic is outpacing actual mobile data traffic by 30 percent to 50 percent, if not higher, Thelander said. For instance, a Yahoo IM user may send a message but then wait a couple of seconds between messages. To preserve battery life, the smartphone moves into idle mode. When the user pushes another message seconds later, the device has to set up a signaling path again.<br />
"Smartphones are causing a problem, but it isn't data usage," Thelander said. "The base station controller is spending a lot of its resources trying to process the signaling so it can't do other things like allocate additional resources for data. You'll see dropped calls and data service degradation."<br />
Read more: What's really causing the capacity crunch? - FierceWireless http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch#ixzz1uhMaqBsH</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Headlights2012&diff=58939Headlights20122012-05-13T07:42:52Z<p>Hoschka: /* Network-Friendly WebApps */</p>
<hr />
<div>In early 2012 W3C staff identified some potential directions for W3C. Some relate to the technical agenda, others to organizational development, and others to community-building or business development. In February W3C management launched eleven task forces to develop proposals with community participation. This page lists the eleven proposals the task forces are developing between March and mid-May. The W3C Membership will discuss them in May, then the task forces will further refine them in June. In July, W3M will prioritize mature proposals and allocate resources to pursuing them.<br />
<br />
Please note that <b>these topics are in development; W3C has not allocated resources to them other than to develop proposals</b>.<br />
<br />
=Technical Agenda=<br />
<br />
==Social networking standards==<br />
<br />
'''Led by Jeff Jaffe <jeff@w3.org>'''<br />
<br />
Social networking is a dominant activity on the Web. There are activities at W3C in this space (Federated Social Web Community Group, Social Business Jam in 2011 and now Community Group, PubSubHubbub Community Group, OStatus Community Group, Core Mobile Web Platform Community Group). The architecture of social networking needs to be more tightly integrated into the Web architecture. Both for consumers and within the enterprise, the Web architecture must be enhanced to better support social networking.<br />
<br />
[http://www.w3.org/wiki/SocialWebHeadlightsTaskForce Social Networking task force home]<br />
<br />
==Cloud computing standards==<br />
<br />
'''Led by Jeff Jaffe <jeff@w3.org>'''<br />
<br />
Cloud computing has emerged as an important business strategy. However, for common services, cloud providers do not interoperate (in terms of APIs, security, management services, etc.). Some industry leaders have called for a W3C-like organization to provide standards for the cloud.<br />
<br />
See the [http://www.w3.org/wiki/CloudComputingReport Cloud Computing Report]<br />
<br />
==Digital publishing standards==<br />
<br />
'''Led by Ivan Herman <ivan@w3.org> and Doug Schepers <schepers@w3.org>'''<br />
<br />
The growth of the tablet and eReader market, and changes in scholarly publishing, have shown the accelerating impact of the Open Web Platform on digital publishing. For example, ePUB 3.0 no longer subsets W3C standards like HTML5, CSS, SVG, MathML, and Javascript APIs, but uses them in full. It also extends them to cover the various needs of digital publishing. These extensions, and continuing fragmentation among devices, formats, publishers, and distribution networks, suggest an opportunity for W3C to address publishing industry use cases, from novels and prose through to scientific and scholarly publishing, medical and legal publishing, interactive children's books, magazines and more.<br />
<br />
Work on this project is taking place in the [http://www.w3.org/community/digipub/ Digital Publishing Community Group].<br />
<br />
==Payment standards==<br />
<br />
'''Led by Alan Bird <abird@w3.org>'''<br />
<br />
Industry has embraced the Open Web Platform as the future platform for apps, including mobile apps. However, because the Web does not have interoperable payment systems, monetization of Web apps is more complex than for native apps. W3C has some work going on in this area (Web Payments Community Group) and long ago did work on micropayments.<br />
<br />
See the [http://www.w3.org/wiki/Payments_Task_Force payments task force wiki]<br />
<br />
==Digital marketing on the Web==<br />
<br />
'''Led by Karen Myers <karen@w3.org>'''<br />
<br />
Increasingly, digital marketing firms are moving from proprietary approaches to technical standards for the frameworks that are common across the industry. Typical topic areas relate to data collection, security, additional interactive capabilities, and stewardship. Some relevant work is performed within the advertising industry itself. As the Open Web Platform evolves more rapidly at W3C, there is no natural home for work that encompasses the broad set of advertising networks, agencies, publishers, and other Web platform stakeholders. W3C should be that home.<br />
<br />
==Network-Friendly WebApps==<br />
<br />
'''Led by Philipp Hoschka <ph@w3.org>'''<br />
<br />
In February 2012, as part of GSMA's [http://http://gsma.com/smarterapp Smarter Applications] Technical project, the GSMA has published guidelines entitled "[http://www.gsma.com/technicalprojects/wp-content/uploads/2012/04/gsmasmarterappsforsmarterphones0112v.0.14.pdf Smarter Apps for Smarter Phones!]" for mobile applications in general, initially focusing on native applications. The document aims to "enable improvements across a number of areas including application connectivity, power consumption, network reliability and security." To enhance the document's relevance, a W3C community group on "[http://www.w3.org/community/networkfriendly/ Network-Friendly App and WebApp Best Practices]" was created to gather input from the Web community for the document's update to be released by end of 2012.<br />
<br />
With the rising importance of mobile Web applications, it is worth to look at whether W3C should work on guidelines specifically focusing on mobile Web applications, based on and complementing the existing GSMA guidelines for native applications.<br />
<br />
This could take the form of an update of or companion to the W3C "[http://www.w3.org/TR/mwabp/ Mobile Web Application Best Practices]" standard, published in December 2010.<br />
<br />
The GSMA and others are currently also pursuing other technical approaches to improve the "network friendliness" of mobile applications, some of which could also be candidate for W3C standardization.<br />
<br />
For more info and background see [[Network-Friendly-WebApps|Network-Friendly WebApps Wiki page]].<br />
<br />
=Developer Outreach=<br />
<br />
==Strategic developer relations==<br />
<br />
'''Led by Doug Schepers <schepers@w3.org>'''<br />
<br />
Developers and designers form an important audience for W3C standards, but the standards process itself is not an ideal way to engage with them. W3C has made strides in terms of developer relations in recent years, through W3Conf, Web Education XG and CG, easy access to W3C through community groups, more documentation, and online training. More can be done to reach more people and better reflect their interests in W3C.<br />
<br />
Work on this project is taking place in the [http://www.w3.org/community/devrel/ W3C Developer Relations Community Group]. Read [http://www.w3.org/community/devrel/2012/03/22/devrel-and-webed-cg/ a full blog post on this proposal] by Doug Schepers.<br />
<br />
==Developer certification==<br />
<br />
'''Led by Alan Bird <abird@w3.org>'''<br />
<br />
Certifying that people (developers, designers) have skills to develop for the Web is essential given:<br />
<br />
* the rapid pace of technological change<br />
* the increased dependency of society on the Web; especially government services<br />
* societal benefits from standards-aware design: security, privacy, accessibility, multilingual, mobile, etc.<br />
<br />
The proposal is to create a developer certification program backed by a W3C trademark.<br />
<br />
==[[Mobile_checker|Updated mobileOK checker]]==<br />
<br />
'''Led by Dominique Hazaël-Massieux <dom@w3.org>'''<br />
<br />
The current W3C mobileOK checker is based on the [http://www.w3.org/TR/mobileOK-basic10-tests/ mobileOK basic tests specification] from 2008, before the latest generation of smartphones and tablets hit the market. The tool follows the specification, but a much more useful tool could be developed today to match the new capabilities and requirements for modern mobile Web development.<br />
<br />
Work on this is done in the [http://lists.w3.org/Archives/Public/public-mobileok-checker/ public-mobileok-checker mailing list], and on the [[Mobile_checker|related W3C Wiki page]].<br />
<br />
=Organizational Growth=<br />
<br />
==Working Group infrastructure==<br />
<br />
'''Led by Ted Guild <ted@w3.org>'''<br />
<br />
Driven by the need for scalability around Community and Business Group infrastructure, the W3C Systems Team has made some improvements in tool creation that would also be useful to Working Groups. It should be easier to launch the infrastructure for a new Working Group. It is also worth looking at Working Group work flow generally and provide streamlined interfaces.<br />
<br />
==W3C Twentieth Anniversary in 2014==<br />
<br />
'''Led by Marilyn Siderwicz <msiderwicz@w3.org>'''<br />
<br />
W3C turns 20 in 2014. We would like to start planning now for a celebration. We would create a corresponding campaign to raise awareness about the evolution of the Web and of W3C.</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58935Network-Friendly-WebApps2012-05-12T22:47:54Z<p>Hoschka: /* Impressive Case Studies */</p>
<hr />
<div><br />
=Background Material (incomplete)=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[What's really causing the capacity crunch? http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09<br />
* "While data traffic is also growing, by many accounts, signaling traffic is outpacing actual mobile data traffic by 30 percent to 50 percent, if not higher, Thelander said. For instance, a Yahoo IM user may send a message but then wait a couple of seconds between messages. To preserve battery life, the smartphone moves into idle mode. When the user pushes another message seconds later, the device has to set up a signaling path again.<br />
"Smartphones are causing a problem, but it isn't data usage," Thelander said. "The base station controller is spending a lot of its resources trying to process the signaling so it can't do other things like allocate additional resources for data. You'll see dropped calls and data service degradation."<br />
Read more: What's really causing the capacity crunch? - FierceWireless http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch#ixzz1uhMaqBsH</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58934Network-Friendly-WebApps2012-05-12T22:46:12Z<p>Hoschka: /* Background Material (incomplete) */</p>
<hr />
<div><br />
=Background Material (incomplete)=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[What's really causing the capacity crunch? http://www.fiercewireless.com/nextgenspotlight/story/whats-really-causing-capacity-crunch]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09</div>Hoschkahttps://www.w3.org/wiki/index.php?title=Network-Friendly-WebApps&diff=58933Network-Friendly-WebApps2012-05-12T22:42:23Z<p>Hoschka: /* Background Material (incomplete) */</p>
<hr />
<div><br />
=Background Material (incomplete)=<br />
<br />
[http://www.gsma.com/newsroom/wp-content/uploads/2012/03/fastdormancybestpractices.pdf GSMA Network Efficiency Task Force Fast Dormancy Best Practices]<br />
<br />
[http://www.computerworld.com/s/article/9191759/Fast_dormancy_to_improve_smartphone_networking_and_battery_performance_ Fast dormancy to improve smartphone networking and battery performance (Computer World)]<br />
<br />
[http://arstechnica.com/gadgets/2010/02/how-smartphones-are-bogging-down-some-wireless-carriers/ How smartphones are bogging down some wireless carriers (Ars Technica)]<br />
<br />
[http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA AT&T Application Resource Optimizer (ARO) - For energy-efficient apps]<br />
<br />
[http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA A Call for More Energy-Efficient Apps (ATT Research)]<br />
<br />
[http://conferences.sigcomm.org/imc/2010/papers/p137.pdf Characterizing Radio Resource Allocation for 3G Networks (ATT, Sigcomm 2010)]<br />
<br />
[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CIYBEBYwAA&url=http%3A%2F%2Fwww.nokiasiemensnetworks.com%2Fsites%2Fdefault%2Ffiles%2Fdocument%2FSmart_Lab_WhitePaper_27012011_low-res.pdf&ei=rd2uT-vGM6PS0QWzr5GUCQ&usg=AFQjCNErWrjgW5AiiiSEeJwmjKaWHcKgtQ Nokia Siemens Networks Smart Labs- Understanding Smartphone Behavior in the Network]<br />
<br />
[http://www.fiercemobilecontent.com/story/seybolds-take-apps-should-not-overtax-networks-signaling-system/2011-06-22 Seybold's Take: Apps should not overtax the network's signaling system]<br />
<br />
[http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09 Operators cry out for solution to network signaling congestion]<br />
<br />
[http://www.fiercewireless.com/europe/story/smartphones-causing-network-data-overload-claims-o2/2009-10-16 Smartphones causing network data overload, claims O2]<br />
<br />
=Impressive Case Studies=<br />
<br />
* Clustering periodic transfers in a popular streaming app can achieve energy savings of 46% <br />
* Prefetching thumbnails in a popular news app would achieve an energy savings of 18%.<br />
* Using caching on the device effectively as per HTTP standards would reduce the data traffic for a popular gaming app by 45%.<br />
* http://www.research.att.com/projects/ARO/index.html?fbid=mNaSQgfn2hA <br />
*Pandora<br />
**46% battery energy consumed on less than .2% of the data transmitted.<br />
**40% energy savings by bundling packets into single transmission<br />
**http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient?fbid=mNaSQgfn2hA<br />
*T-Mobile Network issue<br />
"T-Mobile network service was temporarily degraded recently when an independent application developer <br />
released an Android-based instant messaging application that was designed to refresh its network <br />
connection with substantial frequency. The frequent refresh feature did not create problems <br />
during the testing the developer did via the WiFi to wireline broadband environment, but in the <br />
wireless environment, it caused severe overload in certain densely populated network nodes, <br />
because it massively increased signaling—especially once it became more popular and more <br />
T-Mobile users began downloading it to their smartphones. One study showed that network <br />
utilization of one device increased by 1,200% from this one application alone. These signaling <br />
problems not only caused network overload problems that affected all T-Mobile broadband users <br />
in the area; it also ended up forcing T-Mobile’s UMTS radio vendors to reevaluate the <br />
architecture of their Radio Network Controllers to address this never-before-seen signaling issue. <br />
Ult imately, this was solved in the short term by reaching out to the developer directly to work <br />
out a means of better coding the application."<br />
Source: http://apps.fcc.gov/ecfs/document/view?id=7020377809 p. 4<br />
*"signaling from a third-party application took the voice-call success rate down to 10 percent on KT's network" <br />
http://www.fiercebroadbandwireless.com/story/operators-cry-out-solution-network-signaling-congestion/2011-06-09</div>Hoschka