Environmental Design with the Device API

by Tim Wright

17 Reader Comments

Back to the Article
  1. Great read, thank you. This information was new to me, the problems this has the potential of solving are not. Brilliant stuff.
    Copy & paste the code below to embed this comment.
  2. Your discussion of proximity sensing is incorrect because proximity is not about NFC; rather, it’s about sensing physical proximity. One of the main use cases for it is if the user lifts the phone close to their face, the device can detect that and do things based on this fact. NFC isn’t mentioned anywhere in the W3C spec.
    Copy & paste the code below to embed this comment.
  3. Great article, thanks!
    A few comments:
    * The responsive images effort does not directly relate to bandwidth.  It does not rely on the assumption that “small screen == narrow bandwidth”. Basically, we want to send out smaller images to smaller screens because that is all that is necessary.
    * The “Network information API” is in great flux. It is not really implemented anywhere, and the “bandwidth measurement” part is not actually defined, and it’s not clear if, when & how browser vendors will actually implement it. Developers should not rely on that API, at least not in the near future.
    * Many people,  me included, would argue that due to its variability, available bandwidth is not something designers can nor should take into account in their designs, due to the simple fact that you cannot predict the future. Measurements of past bandwidth, even if they were implemented in browsers, would not provide any guaranty regarding the bandwidth a few hundred milliseconds from now.
    Copy & paste the code below to embed this comment.
  4. Sounds interesting for sophisticated web apps. But as a designer of simple sites, I’d like to present the user-agent with high and low assets, and let it decide which to use and how.
    Copy & paste the code below to embed this comment.
  5. Very interesting article.  Had no idea there were APIs for all those different indicators.  These will probably be standard for web development in couple of years seeing how fast the technology is evolving.
    Copy & paste the code below to embed this comment.
  6. Great read, is there any information on when this is going to be available to us and which browser will be the first to implement these APIs?
    Copy & paste the code below to embed this comment.
  7. Thank you Tim. The Device API is definitely the future and will have a profound impact in a relatively short period of time.
    Copy & paste the code below to embed this comment.
  8. Thanks for the feedback all! @Marcel there’s some information on the Boot2Gecko wiki https://wiki.mozilla.org/WebAPI - They call it the “WebAPI” but it’s pretty much the same thing. Items that have (W3C) next to them have made it over to the DeviceAPI
    Copy & paste the code below to embed this comment.
  9. is the .killer-logo big heading meant to be half underneath the main navigation, or is that a problem with the CSS for the new layout? 
    I’m using Ubuntu Linux Precise Pangolin and Chrome Version 24.0.1312.57
    Copy & paste the code below to embed this comment.
  10. Without discussing the merits of the overall idea, I think it’s worth correcting a number of factual inaccuracies in this article: It’s not clear to me what “the Device API” is supposed to be. The link in the article points to the Device APIs group (aka DAP). Each of the various APIs mentioned in the article are intended to be a device API, and there is no claim made by DAP that it is covering all of the device APIs in the world (it isn’t) or that there is one big Device API To Rule Them All. The work on device APIs started well before 2011. The group started in 2009, and it was built atop previous input. Mozilla wasn’t contributing at the time, though there did later bring some parts of the B2G APIs to the table. To be fair though, most of B2G concerns System APIs (SysApps). It’s a different set of functionality, not meant for the browser but rather for installed applications, and handled in another group. I would be very wary about relying on the Network Information API. I am not aware of anyone being able to implement it useful (or describe a developer-useful alternate approach). As a result it has been close to being culled for a while, only save by the fact that someone regularly shows up claiming that they have a new idea. Also note that using the Battery API to estimate how long the battery might last (as is suggested) is very likely to be wrong (battery consumption patterns are rarely if ever linear). It’s hardly a limitation of the ambient light sensor API that it needs an ambient light sensor to work… I’m also not sure why it would be weird that it would use lumen values rather than a CSS size unit. It’s also not imprecise because it’s cutting edge, but because there’s huge variance in sensors. Proximity has nothing whatsoever to do with NFC. As its name indicates, NFC is about communication, using a field, that’s near. The point of the Proximity Sensor API is to know if there’s something close. The typical use case is knowing if your phone is close to your face so you don’t hang up with your ear. The vast majority of smartphones support this. There will be an NFC API, but it won’t bear any relationship whatsoever to this.
    Copy & paste the code below to embed this comment.
  11. I see a lot of dissension in response to this post.  I am tempted to be equally dismissive, however, are there practical demonstrations of this capability that you could provide? Things like adjusting background color according to lumens I find quite off putting.  It strikes me that the relative perceived brightness of a screen should be something managed by the user’s preferences and manual interference, not my assumptions. Also, @Dominic Wormald, I see that .killer-logo overlap too on Mac Chrome and, regardless of intent, it’s weirding me out.
    Copy & paste the code below to embed this comment.
  12. Good article Tim, appreciated.
    Copy & paste the code below to embed this comment.
  13. @Elizabeth There is no doubt that a developer can do the wrong thing in adapting a design based on lumens. Like any functionality, it can be used wrongly. But it can also be used properly in order to provide enhancements that the underlying platform cannot because it can at best guess at the best changes.
    Copy & paste the code below to embed this comment.
  14. This is really a nice article. Thank you very much..
    Copy & paste the code below to embed this comment.
  15. One thing we need to remember, real life data is very noisy. You almost always have to do some kind of post-processing to remove outliers and identify central tendencies. Only then can we start making design decisions based on them. I wonder if such kind of post-processing is already done by the devices today, or is it up to developers to code it up themselves.
    Copy & paste the code below to embed this comment.
  16. Most phones have a proximity sensor, actually. It is used to detect if the phone is held to the ear or not. The proximity sensor is therefor usually located near the front speaker. The question is, does the Proximity API use this when available, or does it only want to use NFC?
    Copy & paste the code below to embed this comment.
  17. Robin Berjon makes one good point abount bandwidth. I was thinking to use this in the future for adaptive images (given browser vendors don’t come up with a proper solution), but it makes very little sense when you think about it. When on a 3G-like connection and on the move, the available bandwidth may vary quickly enough to make its status at page-load too inaccurate to rely on. This goes for public Wi-Fi as well, because public Wi-Fi may well be hooked up to a 3G-connection: in trains and planes this is certainly the case, as is for Wi-Fi tethering. In fact, the bandwidth of any public (or otherwise heavily shared) connection is inherently unstable and unreliable, be it a wired or wireless connection. And with all that taken into consideration, it’s saying nothing about latency yet. One might have heaps of bandwidth at horrible latency. Satellite connections may provide latencies of a few seconds even, but so would 2G internet connections. A fiberoptics user may be doing some heavy P2P traffic, increasing the latency while keeping most of the bandwidth.
    Copy & paste the code below to embed this comment.