Re: [sensors] the near/far event names

On 13/05/2012 21:46, Doug Turner wrote:
> I requested that we have this be optional since Firefox has already shipped without this attribute.
In WebIDL, you can't have an optional attribute… it's either defined in 
the interface or it is not (though the attribute could always return null).
> I am pretty sure that this attribute is going to be troublesome and it is one of those things we can bike shed all day on.   Hence, i think we should just punt and look at this issue after we have something wildly deployed and have reported problems with the API.
I would agree we were bike-shedding if we were talking about names or 
similar; but here we are trying to figure out the fundamental design of 
the API and what the use cases are. At the moment, the arguments that 
being presented seems to be:

  1. it's already implemented and shipping (as an experimental thing).
  2. because we have that data (i.e., in Android), we can return it and 
let devs figure it out.
  3. talking about use cases/requirement wastes time (and doesn't help 
the Web)... 0_o.

I'll note that we risk making the same mistakes that were made with the 
Orientation API where it's extremely confusing to work with (alpha, 
beta, gamma is are extremely confusing to developers - and just outright 
bad design on the part of the Geolocation WG). See the following for 
instance (fast forward to 25:00):
http://www.infoq.com/presentations/Hybrid-Mobile-Applications-using-PhoneGap 


We've also experience problems in the W3C Tech course on Advanced Mobile 
Development getting developers to grok alpha, beta, gamma. I worry that 
we are repeating those mistakes again by dumping complexity on 
developers unnecessarily.

And as has also been pointed out, on iOS, this proximity is just either 
close or near… for example:
http://mobiledevelopertips.com/device/using-the-proximity-sensor.html

It's for this reason that I would encourage you to consider the more 
limited approach of far and near. If people come back and say "look, we 
really need to know the min, max, value for this really important use 
case: …. ." Then we are cooking. I'm really worried that everyone will 
just get confused and we will just end up with code like this:

if(e.value > e.min && e.value < e.max){
    //value was random fluctuation :/
}

Or:
//Max sometimes happens to be +Infinity, as allowed by the spec
var percent = e.value / e.max;
if(percent < .8){
    //oh, they must be pretty close
}

> However, if we do want to continue with this attribute, I think that we need to have normalized language around this def. or interopt is not going to happen.

Proposal:
   Near: "Sensing the presence of a physical object with a 
UA/OS/sensor-specific degree of confidence."
   Far:   "Not sensing the presence of a physical object with 
UA/OS/sensor-specific degree of
   confidence."

Another approach would be to scope this further to the use case and just 
say its a: "UserProximityEvent".

So, the my personal ideal API would work like this:

if(navigator.userProximity){
    //enables proximity sensing
    navigator.userProximity.addEventLister("proximity", proximityCheck);

    //event is "UserProximityEvent"
    function ProxityCheck(event){
        if(e.near === true){
           doNearStuff();
           return;
        }
        //otherwise, user is far…
        doFarStuff();
    }

   //later... stop sensing:
   navigator.userProximity.removeEventLister("proximity", proximityCheck)
}

And I still have a nagging feeling that one would will need:
navigator.userProximity.near;

--
Marcos Caceres
http://datadriven.com.au

Received on Monday, 14 May 2012 14:35:23 UTC