The ambient light sensor can now be accessed from a web page through the Ambient Light API.

I was able to access the ambient light sensor on a couple of my android devices from a web page through the new “devicelight” event listener. At the time of this post, only FireFox Mobile 15.0.1 supports this API.  I tested this on iOS 6 Safari, Opera 12.0.4, Chrome 18.0.1025308, and Browser 4.1.1-398337 as well.  None of them called the event.

My tests were successful on both my Google Galaxy Nexus (Samsung) and my Google Nexus 7 (Asus).  The values that the devices returned were significantly different for similar lighting conditions. This may make it difficult to build software that responds to certain light conditions. The polling interval is also inconsistent between devices.

My Galaxy Nexus gets values that range from 4 to over 50,000. The lowest value: 4 is achieved by covering up the ambient light sensor. On the Galaxy Nexus (and on most phones) it is located close to the ear speaker. Here is a list of values and the conditions in which I receive them:

On the Galaxy Nexus, the event listener is called only when the value changes. If the ambient light is constantly changing, the listener will be called every 200 milliseconds. If the light doesn’t change the event does not get called.

On the Nexus 7, the event listener is called every 69-70 milliseconds. The light value changes constantly. There are times when it takes up to 450 milliseconds between event listener calls, but I attribute this to garbage collection or background processing. The reported light values ar constantly changing.

The good part is that the code couldn’t be easier. Here is mine:

window.addEventListener('devicelight', function(event) {
  console.log(event.value);
});


Angus Croll published a classic article on JavaScript’s this Keyword. I created a quick impress.js presentation to help communicate this to engineers. Check out the presentation or the code on github.

What is a cookieless domain? A cookieless domain is a domain like any other. It is used to serve assets that will not use cookies. It is common to serve images, styles, and scripts from a cookieless domain.

Setting up a cookieless domain is simple. For a site located at www.mydomain.com one might consider registering www.mydomainassets.com as a cookieless domain. The name of the new domain is not important. The new cookieless domain may be configured to resolve to the same place as the original domain. All of the static files that will not use cookies may then be served from the new cookieless domain by simply changing the source location of that asset.

The value of a cookieless domain may seem small. All of the cookies for a single site are typically less than 10 kilobytes combined. So why go through the work for such a small gain? Because the cookies are sent with every request for every asset. A quick look at popular online news outlets showed an average of 150 requests were made to load the home page. One of the sites, http://msnbc.com, made 265 asset requests in order to load the main page. If 10 kilobytes of cookies were sent with every one of those requests, user’s browsers would be uploading more than 2.5 megabytes of cookies to request assets that would never use those cookies.

Uploading data that will never be used is particularly bad because client requests are not compressed like client responses. Server responses can be compressed to an average 25% of their original size. And many users have asymmetrical internet connections that provide download speeds that are up to 20 times greater than upload speeds. When these circumstances are stacked, 150 kilobyes of upload can take longer than 5 megabytes of response data.

The HTML 1.1 specification limits the number of connections that a browser can establish to a single domain to two connections. Most current browsers disregard this limit and allow for between four and eight connections per domain. Cookieless domains allow browsers to download twice the number of assets simultaneously by adding the extra domain.

Its cheap, easy, and improves the site performance. Win, win win.

I was trying to come up with a presentation demo that would show off the iOS gyroscope api.  At first the best that I could come up with was a scrolling marquee.  I thought that it would be cooler than it actually was.  You know those spinning LED toys that you pick up at county fairs, amusement parks and sporting events.  Something like that.  The plan was to show text far larger than could fit on the screen.  As the screen moved the text would essentially stay in place.  So waving a device back and forth should show the entire message.  Problem: sliding horizontally does not register on the gyroscope.

My second plan was a little better.   I could use the device as a remote control for a web bowling game.  The iOS gyroscope and accelerometer data together could provide a pretty decent bowling controller.  It would not be as accurate as a Wii or PS3 controller because those controllers have the benefit of an external camera that tracks their location.  But I could calculate a swing, rotation, and twist.  So I did it.  And it works.  The swing calculations could use some tweaking for sure, but here is the gyroscope and accelerometer code:


var ballGrab = function(e) {
  e.preventDefault();
  e.stopPropagation();
  playr.orient = [];

I have left out some bits of code here. The trimSwing() function goes backward through the orientation data to dump all except the data for the last forward swing. Then the calcSwing() turns the swing data into four basic values: power, acceleration, rotation, and twist.

The values are sent via socket.io to a Box2Djs front end that throws the ball into the pins. Box2Djs is equally cool. I will save that for another post. If you would like the complete code, you can find it on .

A couple of recent blog articles on different ways to improve site performance led me to go dig up some less recent studies on the impacts of performance (or the lack thereof).  I threw some of the data into some graphs.  When the data is brought together it is compelling.

Greg Linden presented some Amazon.com data stating that 100 milliseconds of site delay cost 1% in loss of sales in his presentation entitled Make Data Useful.

Eric Schurman of Amazon and Jake Brutlag of Google presented the following data from bing.com.  It demonstrated drops in distinct queries, query refinement, revenue per user, any clicks, and satisfaction.

Schurman and Brutlag also showed that increased site delay caused an increased user interaction delay.

They showed that Google experienced reduced site traffic even with very small site delays.

The impact of the site delays grew worse over time.  After six weeks of slower performance the damage had doubled.

Even after removing the artificial delay, searches per user did not return to original levels.

A summary of a Aberdeen Group study entitled “The Performance of Web Applications: Customers are Won or Lost in One Second” claimed that Web Applications experienced similar user response from slow performance.  The summary alleged that a one second increase in load time resulted in:

• 11% fewer page views
• 16% decrease in customer satisfaction
• 7% loss in conversions

Many other web performance related resources can be found at the strangeloop web performance optimization hub.