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

2012-06-19 Thread Charles McCathieNevile

On Wed, 06 Jun 2012 14:39:35 +0200, Henri Sivonen hsivo...@iki.fi wrote:

On Sun, May 27, 2012 at 7:45 PM, Anant Narayanan an...@mozilla.com  
wrote:
Well, we haven't received this request from developers explicitly yet,  
but one can imagine a situation in which a developer makes an app only

for mobile phones (Instagram?) and doesn't want users to use it on
desktops.
Even though it'll technically work, it might look ugly due to scaling.


Shouldn't it be up to the user to refrain from using ugly apps instead
of the developer preventing them?


I agree with Henri.

I certainly don't support this use case where it doesn't have any real
requests to back it up.

There are cases where a user chooses for some important reason (e.g.
accessibility) to use the wrong app on their device, and not supporting
*that* use case would be a serious change from how the Web is generally
expected to work. In the tradition of the Web, authors are given
information to help them propose, but it is users who dispose - decide
what it is they will actually use.



--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan
noen
norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com



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

2012-06-06 Thread Henri Sivonen
On Sun, May 27, 2012 at 7:45 PM, Anant Narayanan an...@mozilla.com wrote:
 Well, we haven't received this request from developers explicitly yet, but
 one can imagine a situation in which a developer makes an app only for
 mobile phones (Instagram?) and doesn't want users to use it on desktops.
 Even though it'll technically work, it might look ugly due to scaling.

Shouldn't it be up to the user to refrain from using ugly apps instead
of the developer preventing them?

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/



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

2012-05-28 Thread Anant Narayanan

On 05/27/2012 12:53 PM, Scott Wilson wrote:

On 27 May 2012, at 17:49, Anant Narayanan wrote:

On 05/27/2012 05:11 AM, Marcos Caceres wrote:

Sure, but doesn't that lead to the original complaint that certain
developers don't want their application to install at all for PR reasons?


In combination with installs_allowed_from, some apps can choose to publish only 
on certain stores with which they have an agreement that users won't be allowed 
to install apps on devices they weren't designed for. Sure, it would be easy to 
bypass this since there is no UA enforcement, but this would be limited to a 
fairly small technical crowd.


Two objections:

- If its metadata intended for web app *stores* wouldn't it make more sense as 
part of the metadata for store submission, rather than an API for browser-type 
UAs? (Once more I'm CCing the web app stores CG...)


I think it is useful for UAs to have this information. Even if we don't 
make it mandatory for UAs to enforce the size restrictions in the 
spec, some might choose to.



- If its easy to bypass, why bother with it?  (I once wrote a greasemonkey 
script that let the Chrome Store work on Firefox :)


A large majority of users will never bother bypassing the restriction, 
either due to lack of skill or time. Even if UAs did enforce it, it 
would be possible to bypass (in Firefox at-least, via an add-on). I 
don't anticipate that to be a huge issue, as long as we cover 90% or 
more users having a good experience for apps on any device.


-Anant



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

2012-05-28 Thread Guilherme Vieira
On Mon, May 28, 2012 at 5:20 AM, Scott Wilson 
scott.bradley.wil...@gmail.com wrote:

 I understand the intention, which is to give web app developers some means
 of steering users away if they are using a device they don't think will
 work well for them using the app.

 On the other hand, this is the web we're talking about. Everything should
 work in any browser. And if it isn't quite as beautiful when scaled up, and
 is a bit cramped when scaled down, thats still far better than nothing at
 all.

 I'm also not sure how this idea is meant to work for users using screen
 readers or other adaptive technologies.


I see... Not a simple matter at all.

-- 
Atenciosamente / Sincerely,
Guilherme Prá Vieira (a.k.a. n2liquid)

*STOP ACTA/CISPA: www.youtube.com/watch?v=WJIuYgIvKsc*

http://www.linkedin.com/in/n2liquid
 http://www.linkedin.com/in/n2liquid


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

2012-05-27 Thread Marcos Caceres


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 forinsert 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. 




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

2012-05-27 Thread SULLIVAN, BRYAN L
Re 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?: When 
browsing apps, the server can easily access the screen and window DOM 
attributes. When installing apps, the installer (browser, app manager, etc) can 
provide a warning to the user that the app is designed for use on larger 
screens, and may not work properly on this device.

Thanks,
Bryan Sullivan 

-Original Message-
From: Marcos Caceres [mailto:w...@marcosc.com] 
Sent: Sunday, May 27, 2012 1:35 AM
To: Anant Narayanan
Cc: SULLIVAN, BRYAN L; public-webapps@w3.org
Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
Format and Management APIs



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 forinsert 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. 



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

2012-05-27 Thread Marcos Caceres

On 27/05/2012 12:36, SULLIVAN, BRYAN L wrote:

Re 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?: When browsing 
apps, the server can easily access the screen and window DOM attributes.
Right, but that requires some communication that is implicit in the 
spec. I'm trying to figure out what data is leaving my device and going 
to the server, and why (i.e., what is the expected life cycle model). 
There is all sorts of things that are implied going on behind the scenes 
that this spec eludes to (e.g., installation management/sync across 
devices), and it's good to get a sense of how it all comes together. If 
it's not clear in the spec, then I have a hard time seeing how multiple 
user agents will be able behave in an interoperable manner.

  When installing apps, the installer (browser, app manager, etc) can provide a 
warning to the user that the app is designed for use on larger screens, and may 
not work properly on this device.
Sure, but doesn't that lead to the original complaint that certain 
developers don't want their application to install at all for PR reasons?


Ps: Bryan, can I kindly ask that you please stop top-posting on W3C 
mailing lists. It makes it hard to keep threads together. Please see:

http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F


Thanks,
Bryan Sullivan

-Original Message-
From: Marcos Caceres [mailto:w...@marcosc.com]
Sent: Sunday, May 27, 2012 1:35 AM
To: Anant Narayanan
Cc: SULLIVAN, BRYAN L; public-webapps@w3.org
Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
Format and Management APIs



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 forinsert 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

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

2012-05-27 Thread SULLIVAN, BRYAN L
OK, response inline. Below is a response to your request, unfortunately 
top-posted as I think this is an important procedural point and needs the 
visibility.

Re top-posting, I wasn't even aware of the practice or term. FYI for me it's 
the natural way to respond, easier to focus on what I want to respond to or 
what others have responded to (if they follow a similar practice). Its follows 
the natural flow of conversation, in which what the last person said (and the 
one before, etc...) does not have to be repeated by every person. Only the 
minimum necessary context should need be provided for the next comment.

To me, top-posting as you refer to it is easier than digging through emails 
with widely inconsistent methods of in-place responses (in which who said what 
can be very difficult to follow, unless you go back and reconstruct the whole 
thread, and even then it's not easy). 

If we want to mandate that all comments start with a commenter tag (e.g. 
bryan) and if breaking a previous paragraph also include a close tag 
(/bryan) then in-line commenting makes more sense to me.

I also note that the recommendation for inline commenting is a note on a WHATWG 
wiki, not a W3C convention. And even within itself seems contradictory... and 
my practice is consistent with what it recommends as Quote enough original 
text or provide an introduction yourself.

Thanks,
Bryan Sullivan 

-Original Message-
From: Marcos Caceres [mailto:w...@marcosc.com] 
Sent: Sunday, May 27, 2012 5:12 AM
To: SULLIVAN, BRYAN L
Cc: Anant Narayanan; public-webapps@w3.org
Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
Format and Management APIs

On 27/05/2012 12:36, SULLIVAN, BRYAN L wrote:
 Re 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?: 
 When browsing apps, the server can easily access the screen and window DOM 
 attributes.
Right, but that requires some communication that is implicit in the 
spec. I'm trying to figure out what data is leaving my device and going 
to the server, and why (i.e., what is the expected life cycle model). 
There is all sorts of things that are implied going on behind the scenes 
that this spec eludes to (e.g., installation management/sync across 
devices), and it's good to get a sense of how it all comes together. If 
it's not clear in the spec, then I have a hard time seeing how multiple 
user agents will be able behave in an interoperable manner.
   When installing apps, the installer (browser, app manager, etc) can provide 
 a warning to the user that the app is designed for use on larger screens, and 
 may not work properly on this device.
Sure, but doesn't that lead to the original complaint that certain 
developers don't want their application to install at all for PR reasons?
bryan That preference to prevent installation on incompatible devices is 
reasonable, but then they likely need to control distribution, e.g. use the 
metadata (and device info) at the appstore to prevent the app from being 
offered at all, and prevent side-loading as far as possible. User agents could 
also provide a don't install incompatible apps option for users. For the 
rest, a warning will at least focus the responsibility on the user; I think 
they will be less likely to complain if given fair warning.

Ps: Bryan, can I kindly ask that you please stop top-posting on W3C 
mailing lists. It makes it hard to keep threads together. Please see:
http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F

 Thanks,
 Bryan Sullivan

 -Original Message-
 From: Marcos Caceres [mailto:w...@marcosc.com]
 Sent: Sunday, May 27, 2012 1:35 AM
 To: Anant Narayanan
 Cc: SULLIVAN, BRYAN L; public-webapps@w3.org
 Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
 Format and Management APIs



 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

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

2012-05-27 Thread Anant Narayanan

On 05/27/2012 01:35 AM, Marcos Caceres wrote:

On 26 May 2012, at 18:32, Anant Narayananan...@mozilla.com  wrote:

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.


Well, we haven't received this request from developers explicitly yet, 
but one can imagine a situation in which a developer makes an app only 
for mobile phones (Instagram?) and doesn't want users to use it on 
desktops. Even though it'll technically work, it might look ugly due to 
scaling. In this case, we'll need a max_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?


The same way an app would find out, by feature sniffing. The app store 
is also presumably a web page or a native store, in either case, it 
should be able to know the characteristics of the current device using 
standard techniques.



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.


Serving as a warning is sufficient, I agree that we will always have 
some % of users ignore the warning and install it anyway.


-Anant





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

2012-05-27 Thread Anant Narayanan

On 05/27/2012 05:11 AM, Marcos Caceres wrote:

On 27/05/2012 12:36, SULLIVAN, BRYAN L wrote:

Re 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?: When browsing apps, the server can easily access the screen
and window DOM attributes.

Right, but that requires some communication that is implicit in the
spec. I'm trying to figure out what data is leaving my device and going
to the server, and why (i.e., what is the expected life cycle model).
There is all sorts of things that are implied going on behind the scenes
that this spec eludes to (e.g., installation management/sync across
devices), and it's good to get a sense of how it all comes together. If
it's not clear in the spec, then I have a hard time seeing how multiple
user agents will be able behave in an interoperable manner.


There is no extra data leaving your device. When you visit a store it 
will probe for your current device capabilities, and the store, at its 
discretion, can decide whether or not to let the user install an app. 
There is no enforcement by the User-Agent at install time.


Synchronization is an interesting problem that we haven't fully tackled 
head-on yet. So we might need to add some UA enforcement at sync time as 
opposed to install time.



When installing apps, the installer (browser, app manager, etc) can
provide a warning to the user that the app is designed for use on
larger screens, and may not work properly on this device.

Sure, but doesn't that lead to the original complaint that certain
developers don't want their application to install at all for PR reasons?


In combination with installs_allowed_from, some apps can choose to 
publish only on certain stores with which they have an agreement that 
users won't be allowed to install apps on devices they weren't designed 
for. Sure, it would be easy to bypass this since there is no UA 
enforcement, but this would be limited to a fairly small technical crowd.


-Anant



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

2012-05-27 Thread Scott Wilson
On 27 May 2012, at 17:45, Anant Narayanan wrote:

 On 05/27/2012 01:35 AM, Marcos Caceres wrote:
 On 26 May 2012, at 18:32, Anant Narayananan...@mozilla.com  wrote:
 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.
 
 Well, we haven't received this request from developers explicitly yet, but 
 one can imagine a situation in which a developer makes an app only for mobile 
 phones (Instagram?) and doesn't want users to use it on desktops. Even though 
 it'll technically work, it might look ugly due to scaling. In this case, 
 we'll need a max_screen_size.

However, it would work great on an interactive whiteboard for a purpose the 
original developer hadn't imagined... or could be used from a mobile phone 
projected into 3D space using a digital projector with pixel mapping... 

I think the intended functionality is something along the lines you see in 
Apple's App Store where you get a sense of which apps are designed for 
iphone/ipod and which are intended for the ipad, and which are fine with both. 
That works OK with a limited number of devices, but in a more heterogeneous 
world it breaks down quickly.

I don't know what the answer is, but fixating on screen sizes doesn't feel like 
quite right. Maybe its the best that can be done. 

(We already have some issues with what to do with the Widget width and 
height in Apache Rave we use it for min-width and min-height CSS attributes 
on the widget iFrame container. However on mobile we tend to ignore it and hope 
the widget includes a viewport tag)

 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?
 
 The same way an app would find out, by feature sniffing. The app store is 
 also presumably a web page or a native store, in either case, it should be 
 able to know the characteristics of the current device using standard 
 techniques.
 
 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.
 
 Serving as a warning is sufficient, I agree that we will always have some % 
 of users ignore the warning and install it anyway.
 
 -Anant
 
 
 




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

2012-05-27 Thread Scott Wilson

On 27 May 2012, at 17:49, Anant Narayanan wrote:

 On 05/27/2012 05:11 AM, Marcos Caceres wrote:
 On 27/05/2012 12:36, SULLIVAN, BRYAN L wrote:
 Re 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?: When browsing apps, the server can easily access the screen
 and window DOM attributes.
 Right, but that requires some communication that is implicit in the
 spec. I'm trying to figure out what data is leaving my device and going
 to the server, and why (i.e., what is the expected life cycle model).
 There is all sorts of things that are implied going on behind the scenes
 that this spec eludes to (e.g., installation management/sync across
 devices), and it's good to get a sense of how it all comes together. If
 it's not clear in the spec, then I have a hard time seeing how multiple
 user agents will be able behave in an interoperable manner.
 
 There is no extra data leaving your device. When you visit a store it will 
 probe for your current device capabilities, and the store, at its discretion, 
 can decide whether or not to let the user install an app. There is no 
 enforcement by the User-Agent at install time.
 
 Synchronization is an interesting problem that we haven't fully tackled 
 head-on yet. So we might need to add some UA enforcement at sync time as 
 opposed to install time.
 
 When installing apps, the installer (browser, app manager, etc) can
 provide a warning to the user that the app is designed for use on
 larger screens, and may not work properly on this device.
 Sure, but doesn't that lead to the original complaint that certain
 developers don't want their application to install at all for PR reasons?
 
 In combination with installs_allowed_from, some apps can choose to publish 
 only on certain stores with which they have an agreement that users won't be 
 allowed to install apps on devices they weren't designed for. Sure, it would 
 be easy to bypass this since there is no UA enforcement, but this would be 
 limited to a fairly small technical crowd.

Two objections:

- If its metadata intended for web app *stores* wouldn't it make more sense as 
part of the metadata for store submission, rather than an API for browser-type 
UAs? (Once more I'm CCing the web app stores CG...)

- If its easy to bypass, why bother with it?  (I once wrote a greasemonkey 
script that let the Chrome Store work on Firefox :)


 
 -Anant
 




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

2012-05-27 Thread Guilherme Vieira
On Sun, May 27, 2012 at 4:53 PM, Scott Wilson 
scott.bradley.wil...@gmail.com wrote:

 - If its easy to bypass, why bother with it?  (I once wrote a greasemonkey
 script that let the Chrome Store work on Firefox :)


What's the problem? If I understood correctly, the feature is important so
that users don't end up opening apps with improper devices simply because
it would not work fully (as in the case of the Chrome Store being opened on
Firefox), or because the app would look completely broken due to not being
designed for that screen size, etc. If you really want to open just for fun
on something else, to see if the app really does not work in a given
browser, and things like that... well, you're free to. But we shouldn't let
normal users end up in such a situation easily, right?

-- 
Atenciosamente / Sincerely,
Guilherme Prá Vieira (a.k.a. n2liquid)

*STOP ACTA/CISPA: www.youtube.com/watch?v=WJIuYgIvKsc*

http://www.linkedin.com/in/n2liquid
 http://www.linkedin.com/in/n2liquid


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

2012-05-26 Thread Anant Narayanan

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 forinsert 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




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

2012-05-25 Thread Marcos Caceres



On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:

   screen_size: This object may contain the min_height and min_width 
   properties that describe the minimum height and width (in pixels) the 
   application needs in order to render correctly. Interpretation of these 
   values is left up to the runtime and/or app store.
  
  
  
  How does this play with CSS and media queries in particular? What's the use 
  case?
 
 These values do not interfere with runtime detection via media queries.
 The use case for these values is two-fold:
 - An app store may prevent the user from installing an app on a device
 which doesn't meet this criteria
 - A UA may prevent the user from launching an app on a device which
 doesn't meet this criteria
 
 The primary goal in both cases is to let the developer declare what
 screen sizes their app is known to work correctly.

The above cases seems very anti-web IMHO. I thought we had stopped the whole 
designing for particular screen sizes, etc. a long time ago. I feel it would be 
a shame to codify this in a spec.

-- 
Marcos Caceres






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

2012-05-25 Thread SULLIVAN, BRYAN L
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.

Thanks,
Bryan Sullivan 

-Original Message-
From: Marcos Caceres [mailto:w...@marcosc.com] 
Sent: Friday, May 25, 2012 7:43 AM
To: Anant Narayanan
Cc: public-webapps@w3.org
Subject: [manifest] screen sizes, Re: Review of Web Application Manifest Format 
and Management APIs




On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:

   screen_size: This object may contain the min_height and min_width 
   properties that describe the minimum height and width (in pixels) the 
   application needs in order to render correctly. Interpretation of these 
   values is left up to the runtime and/or app store.
  
  
  
  How does this play with CSS and media queries in particular? What's the use 
  case?
 
 These values do not interfere with runtime detection via media queries.
 The use case for these values is two-fold:
 - An app store may prevent the user from installing an app on a device
 which doesn't meet this criteria
 - A UA may prevent the user from launching an app on a device which
 doesn't meet this criteria
 
 The primary goal in both cases is to let the developer declare what
 screen sizes their app is known to work correctly.

The above cases seems very anti-web IMHO. I thought we had stopped the whole 
designing for particular screen sizes, etc. a long time ago. I feel it would be 
a shame to codify this in a spec.

-- 
Marcos Caceres






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

2012-05-25 Thread Marcos Caceres


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.

--  
Marcos Caceres






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

2012-05-25 Thread Scott Wilson
On 25 May 2012, at 17:25, 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.

I think there is a problem here that we can get very mobile and tablet focussed 
- some of our widgets are also designed with interactive whiteboards and TVs in 
mind which may throw off selections based on things like screen size and pixel 
density. 

I can see users ending up doing the whole spoof the user-agent string again 
here, as when sites started showing your browser is not supported when you 
viewed them with something the developer hadn't considered. 

Perhaps at the store level it would be nice to have some assertions of 
platforms tested by the developer, but that would be something different really 
(perhaps something for the web app stores CG to look at).

 
 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.
 
 --  
 Marcos Caceres
 
 
 
 




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

2012-05-25 Thread SULLIVAN, BRYAN L
Perhaps this particular issue then (the need to convey information about 
intended usage of an app, or preferred device characteristics), especially 
designing for a diverse set of devices and screen characteristics (mobile 
phones up to building-side billboards), should be something that we encourage 
developer input on through the community group process. My sense is that it's a 
bigger problem than it seems, and that by just saying apps should work on any 
device or apps should not be tailored to specific device characteristics 
thus we don't need such metadata in manifests, we are doing developers a 
disservice. It's much more complicated than that, and I believe developers *do* 
commonly focus on particular device segments when designing Webapps.

Thanks,
Bryan Sullivan 

-Original Message-
From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] 
Sent: Friday, May 25, 2012 12:59 PM
To: Marcos Caceres
Cc: SULLIVAN, BRYAN L; Anant Narayanan; public-webapps WG; 
public-webappst...@w3.org
Subject: Re: [manifest] screen sizes, Re: Review of Web Application Manifest 
Format and Management APIs

On 25 May 2012, at 17:25, 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.

I think there is a problem here that we can get very mobile and tablet focussed 
- some of our widgets are also designed with interactive whiteboards and TVs in 
mind which may throw off selections based on things like screen size and pixel 
density. 

I can see users ending up doing the whole spoof the user-agent string again 
here, as when sites started showing your browser is not supported when you 
viewed them with something the developer hadn't considered. 

Perhaps at the store level it would be nice to have some assertions of 
platforms tested by the developer, but that would be something different really 
(perhaps something for the web app stores CG to look at).

 
 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.
 
 --  
 Marcos Caceres