W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

Re: [sensors] the near/far event names

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Mon, 14 May 2012 13:48:55 +0000
To: Marcos Caceres <w3c@marcosc.com>
CC: "Tran, Dzung D" <dzung.d.tran@intel.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <535D8A76-B116-41ED-A150-D087C28A67DF@att.com>
I was echoing the use case pointed out by Dzung, ie the user is using a laptop, and the very close proximity assumptions of a mobile phone don't apply (unless you wanted to use the proximity sensor to know that a laptop has been closed). In the user proximity case the developer may want to know specifically how far the user is, if such is supported by sensors.

Thanks,
Bryan Sullivan

On May 14, 2012, at 1:24 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:

> 
> 
> On Monday, 14 May 2012 at 04:39, SULLIVAN, BRYAN L wrote:
> 
>> Thanks, Dzung. For the PC/laptop use case it does make more sense for the API to provide an actual number.
> 
> Bryan, can you please explain to me how it makes sense? I don't see the relationship to the min, max, value? It sounds like you are assuming that the proximity sensor has an infinite/really-long range (or there is some "sweet spot" where you want the user to be that is somewhere between min and max).  
> 
> For the most common use case presented (phone next to head/person in front of computer), I'm arguing that there is no "sweet spot": there is only "near" (something is sensed by the sensor) or "far" (nothing is sensed by the sensor).  
> 
> The only concrete piece of evidence to the contrary were as follows:  
> 
> 1. experimental/artistic pieces:
> http://www.youtube.com/watch?v=h5n0rw8wo14
> http://www.youtube.com/watch?v=vzWEgOt3xsM  
> 
> 2. Automotive parking sensors (which work as array of sensors, so the current API design might not be suitable here):
> http://en.wikipedia.org/wiki/Parking_sensors
> 
> 3. The other was hearsay of upcoming laptop products, but we don't have any details about how they work exactly:
> http://www.pcworld.com/article/200042/windows_8_rumored_features_your_pc_your_way.html
> 
> 4. potentially industrial proximity sensors (though I don't know if we have any representatives from that sector in the WG to provide any guidance as to wether the API would meet their use cases):
> http://www.ia.omron.com/product/48.html
> 
> 
> I don't know if the above 4 are in scope for this work or not - IMO, they should not be for at least this initial round of standardisation.    
>> I was not thinking of that use case.
> 
> Again, what is the use case for knowing if you are "N value" close to the laptop? Also, you are not detecting people here… the kinds of proximity sensors we are talking about detect anything in front of the sensor within their limited (assuming range from millimetres to a couple of feet) detection rage  - so you can't say with certainty that it's the user; could be a cat.   
> 
> For a laptop that turns on when the user is near, you would need to couple that with some other sensor (e.g., the camera) to detect if it actually is the user. Also, a user may simply have rotated their laptop to show a friend who is standing a meter away something funny on the screen.
> 
> 
> Sorry I'm starting to sound like a broken record - so I'll probably bow out at this point… but I'm personally not seeing concrete use cases and only anecdotal evidence of for the need for max, min, value, when it comes to proximity sensors and the (limited) use cases that have been identified.   
> 
> 
> 
> Kind regards,
> Marcos  
> --  
> Marcos Caceres
> http://datadriven.com.au
> 
> 
Received on Monday, 14 May 2012 13:50:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 May 2012 13:50:13 GMT