On 26 May 2012, at 18:32, Anant Narayanan <an...@mozilla.com> wrote:
> 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. To make this more clear, maybe call this min_screen_size. > > 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. At install time or when I am browsing apps, how does a server know my screen resolution? Or is this restriction imposed on by the user agent? > 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. I think that's fine, but as Scott pointed pointed out, user agents have a history of allowing users to bypass these kinds of restrictions (or users hack around them). I think this field can only really serve as a warning that the app might not work as expected.
