Re: detecting connection speed

TL;DR: We shouldn't focus on stopping people doing dumb things that aren't  
harmful, we should focus on enabling people to do smart things that are  
useful.

On Wed, 11 Dec 2013 13:40:07 +0400, Marcos Caceres <w3c@marcosc.com> wrote:

> On Wednesday, December 11, 2013 at 6:47 PM, Jake Archibald wrote:
>
>> I'm not keen on use-cases that boil down to "if connection is <  
>> something, serve degraded experience".
>
> Agree. That would totally suck.

Yes, BUT…

We are not the tasteful design jury, our job is to enable developers to do  
the things they feel they need to do, unless those cause actual problems  
for users. (A lesson that should have been learned from the debacle of not  
providing for rounded corners in the first decade of CSS).

>> My mobile provider uses a compression proxy and I hate it, I'd rather  
>> wait longer to avoid a sub-standard experience. If you've got users  
>> with slow connections, make your site faster for them by making your  
>> site faster for everyone. If that means loading in low res content then  
>> high res content to get to first render faster, this benefits everyone.
>
> Exactly.

Not exactly. My browser also uses a compression proxy, and I love it. This  
is a choice we should let people make, rather than forcing a decision on  
them about what we think is a good or bad experience.

I am not arguing against improving performance by making sensible  
decisions about content. But one solution won't necessarily fit everyone.

Some sites think it is very important to provide hi-res images, and may  
load both a low-res and hi-res version. Other sites think it is important  
to conserve the user's bandwidth - even in the first-world countries I  
live and work, many people pay for the amount of data they use. Different  
strategies will appeal to different users, who are generally free to  
choose.

>> Avoiding video autoplay on 3g, or warning about data use - this is  
>> valid but something the browser/os could do, especially as the user may  
>> have set data limits. This avoids every site having to implement the  
>> same messaging, and the user can "don't tell me again" these kind of  
>> messages at the browser/os level rather than per site.
>
> That would be nice. I don’t think anyone does this (either OS level or  
> Web browser) - but it could be handled at the <video> or <audio> level  
> for sure.

Those are the common cases for high-bandwidth, but there are many more.

My webmail interface offers two versions, one of which is optimised for  
low bandwidth. It isn't a question of a single element, but rather how  
much data is requested in how many requests, and only the app developer is  
likely to know how to make those decisions.

Since it is made by the same people who did a good job of deciding when to  
turn my compression proxy on and off, I'd probably trust them to make the  
right decisions for mail, too. There are other sites I would stop using if  
they made the decision, as I have walked away from some services that make  
awful cut-down mobile versions in favour of their competitors, while in  
other cases I have really appreciated the trimming that developers have  
done and become a bigger fan of their service.

>> Adapting during streaming of something - yeah, these are great, we need  
>> to enable this.
>
> This is a video/audio streaming protocol problem, me thinks. Not in  
> scope for this group.

Protocols themselves aren't, but in principle I would have thought  
something like adaptive streaming is. Although in practice it is being  
done in the HTML-WG, and they are currently looking to publish a Candidate  
Reommendation [1].

>> Basically, if websites start offering a poor experience because of  
>> navigator.connectionType, then devices will lie so they get the better  
>> experience. See media="handheld" and user agent strings.
>
> Agree.

To a certain extent. To a certain extent this is a First World problem -  
in the third world (or at least where there is a poor and expensive  
network) people either look for new services (there are any number of  
*tube.* sites designed to allow people to save on the cost of using  
YouTube, and many big providers quietly offer a different version of their  
services adapted to "typical local infrastructure") or new  
devices/browsers (Opera Mini is still pretty popular in global terms), or  
are stuck paying relatively enormous fractions of their salary to use  
services that people in the first world generally take for granted.

> Note that I also don’t want web apps to try to be clever using this API  
> (which they will undoubtedly f’up, as history teaches us) - but to  
> provide *options* for the user to have some control over what is going  
> on when it comes to large content downloads (particularly wrt how large  
> amounts of data are handled).

Yeah, agreed. But apps *will* try to do clever things - and some will, and  
most will do stupid things and deservedly disappear into obscurity. That's  
OK.

[...]
> If we don’t feel we can trust developers to do the right thing with this  
> information (even if it’s just navigator.connectionType = “wifi” or  
> “cellular"), then I think it’s ok to discontinue this work. Then we can  
> just leave it to browsers and OSs to try to do the right thing (e.g.,  
> through the video/audio and other media related tags).

If we don't think developers can do good with this, then it is not worth  
doing. But whatever we do, some people will use to do stupid things that  
we don't want - and other things that we don't want which turn out to be  
good for people who are not us.

> I’m hopeful that we can expose something - but maybe it’s too early to  
> standardize this stuff in the form of an API. Or maybe there is just too  
> much potential for people to do the wrong thing.

There is a lot of potential to do the wrong thing. But that's a feature of  
almost anything that is generally useful, and limiting it in an attempt to  
force apps to be the way we want seems like a bad idea (and as history  
teaches us, we will usually !@#$ it up in any case).

IMHO. Your mileage may vary…

cheers

chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Wednesday, 11 December 2013 12:40:21 UTC