Re: detecting connection speed

I'm not keen on use-cases that boil down to "if connection is < something,
serve degraded experience". 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.

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.

Adapting during streaming of something - yeah, these are great, we need to
enable this.

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.


On Mon, Dec 9, 2013 at 5:43 AM, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On Monday, December 9, 2013 at 2:53 PM, Puneet Mohan Sangal wrote:
>
> > These are good use cases.
> >
>
> Thanks!
>
> > How do you suggest we collaborate, with DAP's Network Information API?
>
> Right now, we are just interested in finding (web or native) applications
> that make use of network information explicitly - specially on the Web, if
> people are somehow hacking around it. We are not really at the stage to
> formulate any API related suggestions - though proposing some self-evident
> requirements doesn’t hurt - specially when they can be clearly seen from
> one or more of the documented examples.
>
> We just need to document a large enough corpus of applications that can
> serve as the use cases from which to make informed decisions (i.e., so we
> are not speculating and not doing “it would be cool if  the API allowed
> developers X” without actually showing that people really are trying to do
> "X").
>
> > Can we start documenting our use cases in a shared doc?
>
> Yes! absolutely. Right now we are using this document, which you can even
> edit online (requires a GH account):
> https://github.com/w3c-webmob/netinfo/blob/master/README.md
>
> Of course, pull requests are best - though filling bugs on Github also
> works fine (and we can refine the text). But we will take just about
> anything: if you know an application on a native platform, I’d be happy to
> download it, try it out, take the screen shots, etc. For paid apps,
> screenshots and a description are very helpful (saves me a few bucks on
> things I would otherwise not use :)).
>
> Kind regards,
> Marcos
>
>
>