RE: Light sensor - strawman proposal

I have supported work on this sensor for some time, and still do. I think the use cases are mostly obvious and valuable.

Here are some use cases I have provided or commented on:
http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0009.html
http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0008.html

Thanks,
Bryan Sullivan
________________________________________
From: Marcos Caceres [marcosscaceres@gmail.com]
Sent: Thursday, July 12, 2012 8:24 AM
To: public-device-apis@w3.org
Cc: BALAJI NERELLA VENKATARAMANA
Subject: Light sensor - strawman proposal

Hi,
Balaji and I were wondering if the WG would be interested in standardising access to a device's the light sensor (if it's in scope for the WG … perhaps under the "generic sensor access" part of the charter)?

<use-case rant>
Light aware UI use cases are fairly common (and most modern phones, tablets, and laptops include a light sensor). For example, changing contrast of content based on how much light is hitting the phone can be really helpful when looking at content in bright outdoors or dark environments (independent of the phone's own attempts to automatically adjust the brightness, as many phones do today). My car's GPS supports such a feature, for example, where it completely inverts the colours on the screen for "night mode".

Furthermore, making sure content is be legible while a user is in full sunlight is becoming an increasingly common practice with developers: unfortunately, this currently results in UIs that are ultra bright and "contrasty" by default, instead of having UIs and content more dynamically suited for the lighting condition under which the app is being used.

Note: we are aware that actually having control over the brightness from within an app through an API would be extremely helpful here also - but we are leaving that out of scope for now as that probably more in scope of the System Applications WG. Use case for that: adjusting the brightness of the phone to create more contrast so that a QR code can be more easily scanned in full sunlight (the iPhone App "EventBrite" does this, for instance).
</use-case rant>

Here is a straw man proposal for discussion:

partial interface Navigator {
readonly attribute LightSensor lightSensor;
}



interface LightSensor : EventTarget {
readonly attribute double? max; //max sensor range
readonly attribute double? lux; //last known value
attribute EventHandler onchange;
}

interface LightChangeEvent : Event {
readonly attribute double newLux;
readonly attribute double oldLux;


}



And in action:
navigator.lightSensor.addEventListener("change", function(e){
if(e.newLux > 32000){
//full sun light! lets make the text a little bigger and darker
if(!document.body.classList.contains("sunny")){
 document.body.classList.add("sunny")
};
}
});

//generic handler
navigator.lightSensor.onchange = function(e){ … };

If this is something the group would want to standardise, Balaji and I would be happy to volunteer to edit the spec and create a test suite.

Kind regards,
Marcos

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

Received on Thursday, 12 July 2012 16:22:35 UTC