Re: detecting connection speed

These are good use cases.

How do you suggest we collaborate, with DAP's Network Information API?
Can we start documenting our use cases in a shared doc?

Cheers,
Puneet




From: Marcos Caceres <w3c@marcosc.com<mailto:w3c@marcosc.com>>
Date: Monday, December 9, 2013 7:20 AM
To: public-web-perf <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: detecting connection speed
Resent-From: <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Monday, December 9, 2013 7:21 AM

Sorry for top posting, but since we are talking use cases, here is a related document the Web Mob IG is working on:

“Use case and requirements for network information"

https://github.com/w3c-webmob/netinfo

Would be great to collaborate with people in this group on it. We are trying to find concrete cases and document them to inform the standardization process both in this group and for DAP’s Network Information API (which is also struggling to come up with anything remotely valid for bandwidth info).

--
Marcos Caceres


On Monday, December 9, 2013 at 11:46 AM, Marcos Caceres wrote:




On Friday, December 6, 2013 at 11:35 PM, Ivan Kotov wrote:

> Hello, everyone!
> I'm just want to point some concrete use cases for the connection information feature.
> a) Suppose an organization have a simple page with contacts, which includes a map as well. So, in poor network conditions (PNC), it's reasonable to initiate the map on demand, and to paint button for this purpose by default.
> b) There are many portfolio sites, with picture galleries. In the case PNC, I would choose do not load gallery script etc., so we avoid all kind of click events on picture, and only A tag works (sure, with its href attribute).
> c) There is one popular visual component, so called 'carousel'. It is usually horizontal block with 3, 4 or 5 square blocks inside it. These square block represent pictures or even market items (on commerce sites). So, the point is, that a carousel has also arrows, which load new square blocks, so we have some kind of 'discrete scrolling'. And, when PNC, this pattern is obviously do not work. And as a solution, I would propose go to page with all necessary items on arrow click.
> d) We all use social networks. They have 'walls'. Walls usually have previews of some kind of links. These previews are redundant in PNC case, in my opinion. (I should mention, that almost all resources for social network site are usually in browser cache already.)
> e) Search engine case. Suppose we are searching by pictures. We are in PNC. It would be very nice, if pics will have the smallest weight. As small as possible. Maybe servers would send small resolution image versions (and browsers would scale it), maybe images would be concatenated in sprites, additionally.



These are still all theoretical cases - not concrete. It would be good to have concrete cases of people trying to do this in the wild. See James’ email. To be concrete use cases, each of the above should start with a *real* web site - not a “suppose an organization” or other strawman.

Also, the image cases are already covered by responsive images solutions like <picture> and client hints, AFAICT. The deficiencies with trying to solve responsive images use cases with an imperative API are already well-documented and understood [1].

[1] http://www.w3.org/TR/respimg-usecases/#limitations-of-current-techniques


--
Marcos Caceres