Re: Network Information API

On Sunday, December 8, 2013 at 11:43 PM, Mounir Lamouri wrote:

> On Mon, Dec 9, 2013, at 0:21, Marcos Caceres wrote:
> > From the data we collected, the main cases appear to be:
> >  
> > * warn the user that this could cost them money (bbc website, only works
> > on Safari in iOS)
> > * give the user control as to whether large uploads/downloads should
> > happen over cellular.  
> > * Prevent accident data transfer over cellular, which could use up of the
> > user's download quota and/or cost them money.  
>  
>  
>  
> As I see it, UC does not mean "what people do" but "what people could do
> if they have that tool".


What you appear to be describing is a strawman [0] (a theoretical situation - rather than something people are actually using today in one form or another which we can see clear examples of in other platforms). The problem with strawmens is that they can be filled with red herrings - which is why they stink (see what I did there? ;) ). I think that explains, as you say below, why this has gone around in circles for so many months.

Please see also James Graham’s email - this discussion is basically happening in parallel in the Web Perf WG:  
http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0043.html

What we need to be looking for is evidence of people working around the problem, not theoretical situations. We can deal with the “it would be nice if we could do X too” stuff in the future - though again it would be better to survey the landscape and see what actually people are trying to do rather than speculate on what they *could* do; I believe that this is more in-line with the spirit of the extensible Web manifesto.    

> For the moment, it is fairly hard to guess the
> connection quality of your users so websites/apps will use the best tool
> they have: cellular vs wifi.

  
We know there is a good reason for this: Bandwidth quality is extremely dynamic - hence the bandwidth quality value is a poor data point on which to make decisions (particularly as those decisions pertain to content and adding things to the DOM). However, presumedly, the large majority of wifi plans are not capped (or allow users to consume much more data than cellular plans even when they are capped) - hence “wifi” or “cellular” may be a much better data point to make a decision on - specially if the user has a choice in the matter, as is evident from the handful of applications we’ve presented thus far in the document.  
  
> But as said multiple times, there is fast
> and uncapped cellular and slow and capped wifi.


Although that may be true, it seems like the exception, not the rule (at least in "the West"). Do we have data showing how many people are on capped wifi VS how many people are on capped cellular?  

Here is what I found from a quick search, I’ve not confirmed the validity of the research - and I’ve not been able to find the capped/uncapped data:

“According to new research from Strategy Analytics, around 439 million homes around the globe have a Wi-Fi base station installed, which is right around 25 percent of all homes in the world. Not surprisingly, South Korea has the highest Wi-Fi household penetration; that country also has the most amount of broadband users. The UK, France and Germany are also way up there; in those nations, over 70% of households have a Wi-Fi network. In America, around 61% of homes have a Wi-Fi network.

Looking forward a bit, the entity suggests that by 2016, the total worldwide number of Wi-Fi households will swell to around 800 million homes, reaching a penetration rate of around 42%. The report notes that most of that growth will come from China, who will add another 110 million Wi-Fi homes by 2016.” - April 2012, http://hothardware.com/News/Report-A-Quarter-Of-Global-Homes-Have-WiFi/

So, even if it’s true that the predominant way people will access the internet is over cellular (citing the WebIndex 2013 report here), the trend of people having a wifi connection does not appear to be one that is decreasing. Wifi will continue to be feature of many homes, work places, and even businesses people visit on a daily basis. Consider the following, related to how people access traditional TV content:  

“The second additional explanation, which may be a little shaky but still worthy of mention, is the proliferation of free Wi-Fi access. People can watch TV shows and other video at schools, business, restaurants, and so on. Also, dozens of cities have implemented city-wide free Wi-Fi, which reduces the need for broadband connections of any kind. Facebook and Cisco have even teamed up with various businesses to offer free Wi-Fi to anyone who checks in to Facebook from those businesses.”  

See: http://www.slashgear.com/mobile-broadband-free-wi-fi-tablets-killing-tv-statistics-show-24306647/

I’m sure lots of people seek out cafes and other businesses that provide free wifi, both when traveling and just for pleasure (e.g., Starbucks).    
> Why the iTunes store
> prevent users to do large downloads over their cellular connections?
> Likely because users might end up paying without knowing it and complain
> to Apple and also because the download might be so slow that it could
> affect the user experience.


It seems safe to assume so. But it seems safer to assume that it’s cost/quota related - but this is just speculation. The only thing we know if that the AppStore initially (2008) capped d/ls to 10Mb, then increased to, 20Mb, then 50Mb, and as of iOS7, now allows 100Mb. So, it seems its doubling every year (as is probably the size of applications thanks to the introduction of high-density displays). It is also notable that Apple doesn’t provide the ability to configure this - but it would be possible for them to do so, as other applications on iOS can.   

> I see UC for bandwidth. Basically, anything related to content quality
> negotiation:
> - default image quality: you visit Google+, Facebook or Flickr and
> depending on your device, you will see an image that will be fast enough
> to be downloaded (yes, this is intended to be solved by responsive
> images too);

  
Doing responsive images over an API is really bad - and it’s why we have <picture> and Client Hints. Using an API to do this kind of negotiation has been shown to be a footgun because you break the preload scanner (see limitations of current techniques [1]). We can happily rule out this use case for this API and should actively discourage such thing.  

> - default video quality: Netflix currently shows a low quality video
> and improve it until they reach a quality that match what the user can
> download. It would be better for the user perspective if the first
> video quality was closer to what they would expect;


This could be better set by the user. Adaptive video streaming is already a solved problem AFAIK.  
  
> - default texture in a game: a game might want to show LD quality
> because your system can't handle HD quality but also because downloading
> the assets would be too slow;

This is responsive images again.   
> - downloading the email bodies without monopolizing the bandwidth.


This could be a user preference (“don’t download big attachments") and, for the most part, can be handled by responsive images (for image attachments, particularly for previews).

GMail, for instance, won’t download images or attachments unless the user explicitly presses a button.  

So, the burden of proof here falls on the platforms that support a “bandwidth API” already: does anyone know of any email application on any platform that does what you describe above. If the answer is no, then this is not a valid use case until at least one example is found.  

> For what its worth, we are having this discussion every 6 months. Some
> UC are listed in the specification I believe and could definitely be
> found in the list archives.
>  

Sure, but what we are trying to show with the use cases document is that the bandwidth thing is not a useful data point (or it’s just too complicated) when looking at things that are “in the wild" (and should be dropped for now). As we find more applications on native platform, it’s becoming evident that developers could make a whole bunch of really interesting applications with only knowing the connection type (“wifi”, “cellular", “none”/airplane mode … and maybe “unknown” or “interactive” when switching) as well as getting a notification of change when the connection type changes from one to another.   

The evidence in the document we’ve put together, although very limited at the moment, is already starting to be indicative of the kinds of things people could actually do if they had just access to the connection type. We need more examples to be able to draw firm conclusions - hopeful we can find more examples.  
  

[0] http://en.wikipedia.org/wiki/Straw_man
[1] http://usecases.responsiveimages.org/#limitations-of-current-techniques

Received on Sunday, 8 December 2013 23:54:32 UTC