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
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
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 a
RE: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs
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
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
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
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
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
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