Re: Network Information API

On Tuesday, January 21, 2014 at 12:52 AM, Mats Wichmann wrote:

> On 01/20/2014 12:47 PM, Marcos Caceres wrote:
> 
> > When all you really wanted was "isCarrierNetwork"? There doesn't appear to be any value, at least in this application, in knowing if the connection is 2g, 3g, or 4g. 
> > 
> > It also shows how much cleaner this is with the new proposed API:
> > 
> > if (this.netInfo.connection === 'wifi') { return true; }
> 
> yes but even here we already have some cases where "it doesn't mean what
> you think it means" if we're assuming wifi = good quality, unrestricted
> usage is available: a mobile carrier-connected device is serving as a
> hotspot to another device, which then sees 'wifi'.

It's certainly not the assumption that is being made by the API (or, at least, it would be fairly unhelpful for a developer to assume that). The API just says "this is what connections you have" and "your connection changed from x to y" - that is all. 

As shown in the use cases document, the point is to give the user the choice to decide which connection is used to manage large uploads/downloads, and to help users make the right choice (see, in particular, the Audible example [1]).    

In other words, if I know, as a user, that my connection is faster on cellular, then I should be able to tell the app to use cellular instead of wifi. If I know, as a user, that my connection is expensive/limited on cellular, then I should be able to tell the app to use wifi over cellular. If I know that the sync kills my battery for this particular app, then I should be able to tell the app to only do it on wifi and when I'm charging.   

These choices cannot, in many cases, be made on behalf of the user by the user agent (because of the dynamic nature of the network connections and because of the different economic factors that have been mentioned in this list). It requires the user to have some degree of digital literacy. This then becomes more of a UX problem. 

Again, why is it good enough to give these options in native apps but not to Web users? We shouldn't treat web users as incapable of making informed choices. Or treat app developers as incapable of providing sensible options and defaults. Even though our sample is small, the apps shown in [1] show that the majority of the time, developers do provide sensible options and defaults. 

The proposed API overcomes much of the silliness shown in some of the native app examples (like making a distinction between "2g" and "3g" like it somehow matters).  
 
[1] https://github.com/w3c-webmob/netinfo/#audible

-- 
Marcos Caceres

Received on Tuesday, 21 January 2014 10:58:08 UTC