On use cases, was Re: WebP, anyone using it?

On Monday, 15 October 2012 at 18:48, Peter Gasston wrote:
> Oh, also Android ICS+ devices support WebP (in native browser & Chrome, at least)
>  

Ok good to know who implements also - that's kinda like the icing on the cake.

<rant>
Building a strong set of use cases is predicated on the inconvenience, or "suffering", to a set of users caused by current technology (in our case, the img element) - and, conversely, how much better these users would be with a *standardized* solution that addresses the use cases. These users are:

 1. End-users (this includes everyone here)  
 2. Developers/content producers (includes probably everyone here)
 3. Potential implementers (includes a subset of people here, and some that are not here)

In formulating the use cases, direct or circumstantial evidence needs to be presented that conclusively shows that the current technology is negatively impacting each of those groups - this is critical, because otherwise, we just have an unhelpful "wish list".  

Consider: because developers are using <div> elements instead of <img>, users who rely on screen readers my not be getting the right set of cues from markup to allow them to experience the page effectively (i.e., from the exclusion if img@alt attribute). Do we have any evidence to support this claim?   

For other end-users, they incur an unnecessary monetary and temporal cost in having to download additional javascript code to experience a responsive design (bytes and additional HTTP requests). This one we can prove easily by looking at polyfills, but how many sites are using a polyfill and how many users have been affected to date?   

End-users are also negatively impacted by current technology in that without a responsive images solution, images will sometimes fail to meet their communicative, functional, and/or aesthetic goals (as demonstrated by the art direction use case - and this is a particular inconvenience to those that surf the web with javascript disabled for whatever reason). What percentage of the Web surfs without javascript enabled? Of those, have they really been affected by this?  
  
For developers, it is an inconvenience to have to require an additional Javascript library and/or rely on server side technology to use responsive images. It also makes code hard to maintain and puts a dependency on Javascript or server-side technology to achieve the desired result. This one is also easy to prove.  

For browser vendors, not having a standardised solution means that new formats (e.g., WebP or JPEG-XR) won't get used as much as they could - because developers have no easy way to include support for these formats without browser detection (or having developers depend on a service like Torbit). This again impacts on end-users because they could be getting a much better user experience by receiving content in these more modern formats.  

In the above, for example, we have two sources claiming WebP can compress images by up to 30% more than other formats on the Web (Google, and Torbit). Scientifically speaking, the validity of the claims are a bit dubious because they cannot be independently verified and come from biased sources (the owners of the technology and an entity with an commercial interest in claiming it works) - but are admissible into our use case document as hearsay. However, the claims have been disputed by at least one other source (as cited by David Baron) … and I see another one on Wikipedia… who is right needs to be determined.  

Furthermore, tool support of these formats needs to be considered (along with implementation support in browsers, like with ICS). Is tool support sufficiently in the hands of developers to make a difference? For instance, JPEG-XR is supported in Microsoft Expression Design, but how many developers use that tool (or the other tools that support it)? There is a photoshop plugin also, but how many people have it installed it and have produced JPEG-XR images?  

The assertions above, along with other strong arguments backed by data, is the corpus of information we need to build up to convince people to take this effort seriously. Primarily, we need to show that end-users are the ones that are suffering the most because of the current way the img element is specified.

But, having conclusive evidence may or may not help our case, as we are not the ones having to spend money specifying, implementing, testing, and maintaining a given feature (these significant costs, which can be in the hundreds of thousands of dollars, if not millions, fall on browser vendors, which is why they may be weary of implementing anything and will need to be convinced … or browser makers will let others take the lead, and see how things turn out for them - as appears to be happening with img@srcset).  

If someone asks you to make a significant temporal and monetary investment, as we are doing to browser vendors, you want to be darn sure that whatever is created is actually going to get used. Therefore, none of our use cases can be based on "it would be nice to have" - they have to be shown as: "we need X because, as the evidence clearly shows, not having X is adversely affecting user group Y right now - and by having solution A, all users will be orders of magnitude better off".

We don't need to have all the evidence now, but we should be systematically working towards acquiring it as needed. What gaps remain in our research will be exposed once we present our use cases to browser vendors and the HTMLWG in the coming weeks.  
</rant>  

Kind regards,
Marcos  

--  
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 16 October 2012 08:44:58 UTC