Re: [sensors] Use Cases and pros/cons Re: [sensors] Device Proximity

Thanks Marcos for summarizing.  Great stuff.

One point - These are not mutually exclusive proposals.

On the list we discussed immediately proceeding with exposing the min/max/value event -- this is shipping in at least one implementation.  We should just discuss the name of the near/far event, briefly discuss what near and far mean, and spec that.

There is no need for a long drawn out discussion about use cases.  It does nothing to further the web.

Doug  


On May 11, 2012, at 8:49 AM, Marcos Caceres wrote:

> Hi All,   
> I think we are reaching the point in the thread where we are starting to see circular discussions. Can we now capture more formally the use cases, requirements, and proposals.  
> 
> Please contribute a bit to the use cases and requirements below…   
> 
> Here is a summary from what I have gathered so far from the discussion.  
> 
> USE CASES
>  1. Detect when phone is next to ear, to, for example:   
>       * turn off the screen/stop unintended interaction.
>       * << add more here >>
> 
>  2. Detect when user is no longer at computer, to, for example:  
>      * stop doing intensive processing.  
>      * automatically log user out of Website.  
>      * << add more here >>
> 
> 
> 
> REQUIREMENTS:
> * Should not eat the battery?
> * Should not force the sensor to be on all the time?  
> 
> 
> 
> API Proposals are:   
> 
> ===  "Min, Max, Value"  ===
> This proposal allows developers to detect the presence of an object.   
> 
> Pros:  
>  * Gives developer control to detect presence of physical object (e.g., someone's head) with potentially a high degree of accuracy.  
>  * deals with a large number of future use cases, like detecting things at greater distance and with more accuracy.  
>  * << add more here >>
> 
> 
> 
> Cons:  
>  * could generate a high number of events (which may serve limited purpose).  
>  * could lead to finger printing.  
>  * could be difficult for developers to understand variation between values provided by hardware (which could lead to wrongly detecting if an object if really near).  
>  * << add more here >>
> 
> 
> 
> 
> ===   "Near/Far" ===
> The API only returns if a physical object is near the sensor or not.  
> 
> Pros
>  * Leaves it to the hardware/implementation to work out what is far near.
>  * Only two events are fired: when "far" and "near".  
>  * Makes it hard to use for fingerprinting.   
>  * << add more here >>
> 
> 
> 
> Cons:
> * Leaves it to the hardware/implementation to work out what is far near.  
> 
> 
> * Limited useful feedback/data is given to developers.  
> * << add more here >>
> 
> 
> 
> 
> I hope that helps.
> 
> --  
> Marcos Caceres
> 
> 
> On Friday, May 11, 2012 at 4:29 PM, Dave Raggett wrote:
> 
>> On 11/05/12 16:13, Doug Turner wrote:
>>> I love this kind of input. It is important to remember that
>>> fingerprinting is a concern. However, I think that you might be
>>> better off discussing fingerprinting at the w3 privacy wg.
>>> Fingerprinting can be done on many APIs, not just these Device APIs.
>>> Do you have a concrete proposal to address these concerns across the
>>> main APIs, or are you just waving the fingerprinting flag as a
>>> reminder to us all?
>> 
>> 
>> 
>> We were discussing the pros and cons of {min, max, value} events versus
>> near and far events for proximity. Finger printing is just one of the
>> factors to take into account.
>> 
>> I would like to better understand the use cases. Is it mostly about
>> sensing when a smart phone is against someone's ear? I don't really
>> understand that for web apps though, unless you are using the web app as
>> an audio player or a P2P voice call over Web RTC. Another use case is
>> disabling the display or otherwise reducing battery demands when someone
>> isn't near the device. In this case, we are presumably talking about
>> sensing someone further away from the device. What am I missing about
>> the use cases for proximity and web apps?
>> 
>> --  
>> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
> 
> 
> 
>

Received on Friday, 11 May 2012 16:11:40 UTC