W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs

From: Anant Narayanan <anant@mozilla.com>
Date: Sat, 26 May 2012 10:32:34 -0700
Message-ID: <4FC113B2.8020704@mozilla.com>
To: Marcos Caceres <w3c@marcosc.com>
CC: "SULLIVAN, BRYAN L" <bs3131@att.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On 05/25/2012 09:25 AM, Marcos Caceres wrote:
>
>
> On Friday, May 25, 2012 at 4:34 PM, SULLIVAN, BRYAN L wrote:
>
>> Marcos,
>>
>> Re "I thought we had stopped the whole designing for particular screen sizes, etc. a long time ago.", that may be the still-closely-held goal, but the reality is that designing for multiple screen sizes (and pixel densities) is still far from simple. Even with all the tools that have been developed in CSS and Media Queries.
>>
>> So if developers want to claim that they have focused their design on specific form factors (and presumably tested it thoroughly on them), this seems like a good thing as it allows them to be more certain that their apps won't be distributed to users of devices on which they won't work well (which will negatively impact the developer's reputation, use of the app, appstore etc), or if distributed to such users, will be clearly identified as not being designed for those devices.
>>
>> Like many of the things we wanted to do in widget manifest structures in BONDI and WAC, if these get pulled from the plan the only fallback is developer ecosystem-specific app metadata, which in the end evaporates with the developer ecosystems, or never achieves widespread use or interoperability. So the problem is not solved for developers by leaving these things out of standards, where there is a strong use case.
>>
>
> Still sounds to me like "Made for<insert everyone's favorite 90's browser here>, and best viewed at 800x600"  and look how well that turned out. Even if we don't focus on mobile devices, it seems like a silly requirement as I can just adjust my browser window to whatever size I want (there is no reason to believe I won't be able to do that on future mobile devices). I.e., screen size and application display area are not the same thing and this metadata attribute seems to assume so.

The intent for the screen_size parameters is not to let the developer 
enforce a particular screen size or resolution, but rather specify the 
*minimum* width and height required by the app. This means that on a 
screen below the specified size, the app will not function at all.

I will also note that it is upto the app store to interpret this field 
however they'd like. If they do not want to disallow installs on devices 
that don't meet the developer-specified criteria, that's fine. However, 
we should still convey this information from the developer to the store 
via the manifest.

It is unrealistic to assume that all app developers will make a 
responsive design for all possible screen sizes. The tools aren't great 
and it costs time and money. We added this field after we received a 
request from the developer of a popular game that only worked on 
desktops, but not mobile phones (due to size). They wanted to make sure 
users weren't able to install them in places the app wasn't designed for 
and get a bad impression of the company. I think this is really important.

-Anant
Received on Saturday, 26 May 2012 17:33:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT