I wanted to refer to the thread "Proposed changes to manifest" from February 7 2012, but it was another one of those threads that happened before the archives were fixed. For the purpose of the archives I'll make a crude copy here (and a couple messages not copied here did get into the archives: https://groups.google.com/d/topic/mozilla.dev.webapps/8O-yYTRJGUk/discussion)
---------------------------------------- Anant Narayanan [email protected] Feb 7 to dev-webapps We've been kicking around some ideas for some new entries in the manifest. Myk, Ragavan & I had an ad-hoc chat about them yesterday, and here I sum up the proposal we came up with: 1. An app should be able to specify what screen sizes / form factors they explicitly support (i.e. look good on) 2. An app should be able to specify what features it needs to run. This has two categories, required features (those without which the app won't run at all) and desired features (those which add some extra functionality) to the app. 3. An app should be able to specify what permissions the app needs to run. Permissions are distinguishable from features in that features are more about what a device *can* do, and permissions deal with whether the user has *allowed* the app to do something To clarify the difference between (2) and (3), for eg.: WebGL is a feature, not a permission, as not all devices support it, but we require no special permission to use on devices that do. Conversely, every device has filesystem access but such access requires granting explicit permission to the app. We decided to defer discussion on permissions in the manifest for now because of the complex implications of doing so. We would, however, like to support the first two (screen size & features) as soon as possible. A rough proposal to do both follows: * Form factors: We adopt a model similar to android where we let an application specify a minimum width and maximum width in 'dp' (density-independent pixels). * Features: We adopt the list of features that the Modernizr library currently supports (http://www.modernizr.com/docs/#s2) The changes to manifest proposed: { … "screen_size": { "smallest_width": <N>dp, "largest_width": <N>dp }, "required_features": ["feature1", "feature2", ...] … } The array elements of the required properties can only be one of a pre-defined list (that we will borrow from Modernizr), examples include: fontface, flexbox, opacity, csstransforms, canvas, applicationcache, audio, video, indexeddb, websockets, webworkers, localstorage, touch (and so on…). The property is named "required_features" to keep the door open to a property named "desired_features" if there is a concrete use case that comes up later. If there are no major objections to the proposal, we can make these changes to the manifest and figure out an implementation path! Regards, -Anant ---------------------------------------- Ian Bicking [email protected] Feb 7 to Anant, dev-webapps On Tue, Feb 7, 2012 at 11:24 AM, Anant Narayanan <[email protected]> wrote: > > We've been kicking around some ideas for some new entries in the manifest. > Myk, Ragavan & I had an ad-hoc chat about them yesterday, and here I sum up > the proposal we came up with: > > 1. An app should be able to specify what screen sizes / form factors they > explicitly support (i.e. look good on) > > 2. An app should be able to specify what features it needs to run. This has > two categories, required features (those without which the app won't run at > all) and desired features (those which add some extra functionality) to the > app. > > 3. An app should be able to specify what permissions the app needs to run. > Permissions are distinguishable from features in that features are more about > what a device *can* do, and permissions deal with whether the user has > *allowed* the app to do something > > To clarify the difference between (2) and (3), for eg.: WebGL is a feature, > not a permission, as not all devices support it, but we require no special > permission to use on devices that do. Conversely, every device has filesystem > access but such access requires granting explicit permission to the app. > > We decided to defer discussion on permissions in the manifest for now because > of the complex implications of doing so. We would, however, like to support > the first two (screen size & features) as soon as possible. A rough proposal > to do both follows: > > > * Form factors: We adopt a model similar to android where we let an > application specify a minimum width and maximum width in 'dp' > (density-independent pixels). Maximum width seems peculiar. Would an app not launch without the maximum width, or would it launch in a smaller window? A more general thing we could use is CSS Media Queries. It's a bit more general than quite makes sense, but has for instance a notion of "handheld" vs. "screen", different kinds of size restrictions and color restrictions, -moz-touch-enabled. Has operators and such too, and will presumably keep growing in the future without our intervention. > > * Features: We adopt the list of features that the Modernizr library > currently supports (http://www.modernizr.com/docs/#s2) Naming is always a bit of a pain in the butt. It would be nice if, when applicable, it was mapped exactly to Javascript names (e.g., "localStorage", not "localstorage"). Also I would assume that operators would be required as well, for instance "indexdb or websql" or "filesystem or indexdb" and so on - cutting edge or transitional technologies often result in this sort of thing, when something experimental addresses a use case but then something more standardized comes along, and both are acceptable but neither represents a complete superset of the other's devices. Unfortunately this doesn't allow things like performance checks, which could be important for games. Storage requirements also seem useful, but don't really fit a simple list model (e.g., IndexDB>=5mb). ---------------------------------------- Harald Kirschner [email protected] Feb 7 to Ian, Anant, dev-webapps 1. An app should be able to specify what screen sizes / form factors they explicitly support (i.e. look good on) The Android manifest allows to define target screen factors for apps, which is a pretty exhaustive list (size, density, orientation, aspect ratio). http://developer.android.com/guide/topics/manifest/supports-screens-element.html Would be interesting to translate it to cross-platform. 2. An app should be able to specify what features it needs to run. This has two categories, required features (those without which the app won't run at all) and desired features (those which add some extra functionality) to the app. I believe that the most reliable way to determine if requirements are met on a specific device (specially on a fragmented market like tablets/mobiles) is a included HTML file that could run those feature, performance and quirks tests. With WebGL I could imagine very well that an app tests for card-specific shader bugs or performance. It could return some kind of score (similar to the Microsoft game store). On Android its easier, as new 3D-intensive games just allow ICS, which only works on high-end devices anyways. But we don't have target SDKs that give an insight on the device performance. I think the split of features and permissions is pretty clear. Though its more than Modernizr currently provides, like camera, audio, SMS, microphone, accelerometer, multitouch (inspiration: http://developer.android.com/guide/topics/manifest/uses-feature-element.html#hw-features) --- Harald Kirschner | Mozillian Software Engineer | [email protected] ---------------------------------------- David Chan [email protected] Feb 7 to Ian, dev-webapps, Anant Operators seem beneficial for grouping similar types of features. In that case, could we use a meta-category (e.g. storage) and allow the app to specify it's preferred storage. Ex storage(IndexDB, WebSQL) This would signify that an app wants storage, preferring IndexDB, then WebSQL. We could throw in storage requirements as Ian mentions. However we probably want a storage layer if there are meta-categories. Ian Bicking [email protected] Feb 7 to Harald, Anant, dev-webapps On Tue, Feb 7, 2012 at 12:44 PM, Harald Kirschner <[email protected]> wrote: > > 1. An app should be able to specify what screen sizes / form factors they > explicitly support (i.e. look good on) > > The Android manifest allows to define target screen factors for apps, which > is a pretty exhaustive list (size, density, orientation, aspect ratio). > > http://developer.android.com/guide/topics/manifest/supports-screens-element.html > > Would be interesting to translate it to cross-platform. > > 2. An app should be able to specify what features it needs to run. This > has two categories, required features (those without which the app won't > run at all) and desired features (those which add some extra functionality) > to the app. > > I believe that the most reliable way to determine if requirements are met on > a specific device (specially on a fragmented market like tablets/mobiles) is > a included HTML file that could run those feature, performance and quirks > tests. With WebGL I could imagine very well that an app tests for > card-specific shader bugs or performance. It could return some kind of > score (similar to the Microsoft game store). > > On Android its easier, as new 3D-intensive games just allow ICS, which only > works on high-end devices anyways. But we don't have target SDKs that give an > insight on the device performance. > > I think the split of features and permissions is pretty clear. Though its > more than Modernizr currently provides, like camera, audio, SMS, > microphone, accelerometer, multitouch > (inspiration: http://developer.android.com/guide/topics/manifest/uses-feature-element.html#hw-features) > Of course one of the nice things about our apps is that we can run small bits of arbitrary code from them with no more overhead than opening a web page. So it seems less important generally to have a declarative approach to compatibility. That said, we've yet to determine a way to communicate to apps, besides completely ad hoc postMessage protocols. I feel like this missing feature is keeping us from doing some things the Right Way. One problem with a page running code is you couldn't check for available storage, nor could you do anything that might be blocked by a permission request. That could be required in order, for example, to check if IndexDB had the features you needed - since you couldn't get a database without a permission request you couldn't look at the features on the database you get back. Similarly it would not really be reasonable to try to write 5mb to a database to test if such a thing could be done. ---------------------------------------- Myk Melez [email protected] Feb 7 to Ian, Anant, dev-webapps On 2012-02-07 10:17 , Ian Bicking wrote: > > Maximum width seems peculiar. Would an app not launch without the maximum > width, or would it launch in a smaller window? The maximum width value would be used by the Marketplace to alert users that an app is not designed to look good on their device. An example is the Android app WeatherBug, some of whose users have complained that it looks bad on tablets because it was designed to fit phone screens. > A more general thing we could use is CSS Media Queries. It's a bit more > general than quite makes sense, but has for instance a notion of "handheld" > vs. "screen", different kinds of size restrictions and color restrictions, > -moz-touch-enabled. Has operators and such too, and will presumably keep > growing in the future without our intervention. I'm not very familiar with Media Queries, but it seems like in addition to being more general and complex they also try to solve a somewhat different problem, and it isn't clear what their reuse gets us. However, it's certainly worth looking at the syntax to see if it (or some derivation thereof) would be preferable and can be made to feel natural when reflected into JSON. > Naming is always a bit of a pain in the butt. There is only one Computer Science problem equally hard, and we have to figure out that one too! ;-) > It would be nice if, when > applicable, it was mapped exactly to Javascript names (e.g., > "localStorage", not "localstorage"). That makes sense to me too, but Modernizr has already blazed this particular trail, so I'd lean toward paving the cow path (to mix metaphors shamelessly) by reusing the names they have defined. We could, however, be lenient about letter case, which would address many common cases of developer typos, including the one you cite. > Also I would assume that operators would be required as well, for instance > "indexdb or websql" or "filesystem or indexdb" and so on - cutting edge or > transitional technologies often result in this sort of thing, when > something experimental addresses a use case but then something more > standardized comes along, and both are acceptable but neither represents a > complete superset of the other's devices. I don't currently know of a concrete prioritized use case for OR operators, and I'm loathe to add such functionality without one. But in any case Anant's proposal would accommodate adding such functionality in the future, should we choose to do so: "required_features": ["foo", "bar", "baz"] --> foo AND bar AND baz "required_features": ["foo", "bar", ["baz", "qux"]] --> foo AND bar AND (baz OR qux) > Unfortunately this doesn't allow things like performance checks, which > could be important for games. > > Storage requirements also seem useful, but don't really fit a simple list > model (e.g., IndexDB>=5mb). Indeed! This list doesn't address all potential ways of identifying app requirements. But it does solve the concrete prioritized use case of enabling an app to specify that it requires WebGL, and it provides some extensibility to additional specification of required features in the future, which seems worthwhile enough. And I can imagine extending the list to accommodate these checks, if we decided that it made sense to do so: "required_features": ["foo", "bar", { "min_storage": "5000" }] "required_features": ["foo", "bar", { "min_perf": "30" }] Or simply employing separate fields for the purpose: "required_features": ["foo", "bar", "baz"], "min_storage": "5000", "min_perf": "30" ---------------------------------------- Mounir Lamouri [email protected] via mozilla.com Feb 8 to Jonas, dev-webapps On 02/07/2012 06:24 PM, Anant Narayanan wrote: > We've been kicking around some ideas for some new entries in the manifest. > Myk, Ragavan & I had an ad-hoc chat about them yesterday, and here I sum up > the proposal we came up with: > > 1. An app should be able to specify what screen sizes / form factors they > explicitly support (i.e. look good on) I do not understand why that would be needed for the web platform? We have CSS Media Queries to show a different content depending on those values. > 2. An app should be able to specify what features it needs to run. This has > two categories, required features (those without which the app won't run at > all) and desired features (those which add some extra functionality) to the > app. That seems to be a good point. I believe that's another use case for a Device Capabilities API. Jonas, what do you think of that? Cheers, -- Mounir ---------------------------------------- Kumar McMillan [email protected] Feb 8 to Mounir, dev-webapps, Jonas On Feb 8, 2012, at 6:25 AM, Mounir Lamouri wrote: > On 02/07/2012 06:24 PM, Anant Narayanan wrote: >> We've been kicking around some ideas for some new entries in the manifest. >> Myk, Ragavan & I had an ad-hoc chat about them yesterday, and here I sum up >> the proposal we came up with: >> >> 1. An app should be able to specify what screen sizes / form factors they >> explicitly support (i.e. look good on) > > I do not understand why that would be needed for the web platform? We > have CSS Media Queries to show a different content depending on those > values. One reason that it's well suited for the manifest is so the marketplace could tell you if the app will work on your device before you install it. It would also be useful for filtering in the marketplace, e.g., to look for the best phone sized app to track your city's train schedules. The marketplace could maybe spider media queries from the app itself for this but that's still guesswork. By placing this in the manifest, the developer is saying "yep, my app officially supports this resolution." Also, I think a lot of apps will consciously support small phone screens in a responsive way which would be hard to infer from their CSS alone. ---------------------------------------- Ben Francis [email protected] via mozilla.com Feb 8 to dev-webapps On Wed, Feb 8, 2012 at 12:25 PM, Mounir Lamouri <[email protected]> wrote: > On 02/07/2012 06:24 PM, Anant Narayanan wrote: > > We've been kicking around some ideas for some new entries in the > manifest. Myk, Ragavan & I had an ad-hoc chat about them yesterday, and > here I sum up the proposal we came up with: > > > > 1. An app should be able to specify what screen sizes / form factors > they explicitly support (i.e. look good on) > > I do not understand why that would be needed for the web platform? We > have CSS Media Queries to show a different content depending on those > values. > I agree, ideally a web app should be able to adapt to work on different form factors using media queries etc. Including this in the app manifest could encourage separate apps for different form factors which I think is undesirable. If developers want users to know that their app works particularly well on a particular form factor, they could always state this in the app description. > > 2. An app should be able to specify what features it needs to run. This > has two categories, required features (those without which the app won't > run at all) and desired features (those which add some extra functionality) > to the app. > > That seems to be a good point. I believe that's another use case for a > Device Capabilities API. I think that optional features can be detected at run-time (e.g. with a Device Capabilities API), but it would be useful for users to know up-front about features they're lacking that will stop the app from working altogether. This could be a bit difficult to express in the manifest though because it could be something very granular like "storing binary blobs in IndexedDB" or a specific feature of WebGL. ---------------------------------------- Anant Narayanan [email protected] Feb 8 to dev-webapps On Feb 8, 2012, at 7:37 AM, Ben Francis wrote: > On Wed, Feb 8, 2012 at 12:25 PM, Mounir Lamouri <[email protected]> wrote: >> >> I do not understand why that would be needed for the web platform? We >> have CSS Media Queries to show a different content depending on those >> values. > I agree, ideally a web app should be able to adapt to work on different > form factors using media queries etc. Including this in the app manifest > could encourage separate apps for different form factors which I think is > undesirable. If developers want users to know that their app works > particularly well on a particular form factor, they could always state this > in the app description. The main goal of this option is to avoid users from using an app that was explicitly designed for mobile phones on the desktop. A lot of mobile-only apps don't scale well on desktop sizes, and the developer may want protect their reputation (and prevent bad reviews) by restricting usage only on screen sizes for which they were intended. I don't think it encourages multiple apps for different form factors, the developers should just update the manifest when their supports new form factors. Applications that use media queries & responsive design from the start can just omit this from the manifest altogether. >>> 2. An app should be able to specify what features it needs to run. This >> has two categories, required features (those without which the app won't >> run at all) and desired features (those which add some extra functionality) >> to the app. >> >> That seems to be a good point. I believe that's another use case for a >> Device Capabilities API. > > I think that optional features can be detected at run-time (e.g. with a > Device Capabilities API), but it would be useful for users to know up-front > about features they're lacking that will stop the app from working > altogether. This could be a bit difficult to express in the manifest though > because it could be something very granular like "storing binary blobs in > IndexedDB" or a specific feature of WebGL. I would love to learn more about the Device Capabilities API, is that part of the WebAPI group? I think we still need a declarative way for apps to let the marketplace know what minimum (and optional) capabilities it needs, in addition to runtime detection. Cheers, -Anant ---------------------------------------- Ian Bicking [email protected] Feb 8 to Myk, Anant, dev-webapps On Tue, Feb 7, 2012 at 7:15 PM, Myk Melez <[email protected]> wrote: > > On 2012-02-07 10:17 , Ian Bicking wrote: >> >> Maximum width seems peculiar. Would an app not launch without the maximum >> width, or would it launch in a smaller window? > > The maximum width value would be used by the Marketplace to alert users that > an app is not designed to look good on their device. An example is the > Android app WeatherBug, some of whose users have complained that it looks bad > on tablets because it was designed to fit phone screens. Max width in particular seems a bit weird; while there are occasional cases, it's one of the more obscure restrictions. And if we only support two kinds of restrictions (max and min size) it seems odd for max size to be one of them. > > >> A more general thing we could use is CSS Media Queries. It's a bit more >> general than quite makes sense, but has for instance a notion of "handheld" >> vs. "screen", different kinds of size restrictions and color restrictions, >> -moz-touch-enabled. Has operators and such too, and will presumably keep >> growing in the future without our intervention. > > I'm not very familiar with Media Queries, but it seems like in addition to > being more general and complex they also try to solve a somewhat different > problem, and it isn't clear what their reuse gets us. However, it's certainly > worth looking at the syntax to see if it (or some derivation thereof) would > be preferable and can be made to feel natural when reflected into JSON. Media queries are declarative boolean expressions that are based on attributes of a device/user agent, so it seems fairly applicable - even if no application is going to be compatible with only print (though it tickles me to consider such an application). Touch is much more likely an issue than max size, for instance -- if you use hover in any important way then your app won't really work with touch. In JSON the media queries would be strings (in HTML they just go in attributes: https://developer.mozilla.org/en/CSS/Media_queries) > >> Naming is always a bit of a pain in the butt. > > There is only one Computer Science problem equally hard, and we have to > figure out that one too! ;-) > > >> It would be nice if, when >> applicable, it was mapped exactly to Javascript names (e.g., >> "localStorage", not "localstorage"). > > That makes sense to me too, but Modernizr has already blazed this particular > trail, so I'd lean toward paving the cow path (to mix metaphors shamelessly) > by reusing the names they have defined. We could, however, be lenient about > letter case, which would address many common cases of developer typos, > including the one you cite. It's not a cow path until more than one cow has gone down it ;) > >> Also I would assume that operators would be required as well, for instance >> "indexdb or websql" or "filesystem or indexdb" and so on - cutting edge or >> transitional technologies often result in this sort of thing, when >> something experimental addresses a use case but then something more >> standardized comes along, and both are acceptable but neither represents a >> complete superset of the other's devices. > > I don't currently know of a concrete prioritized use case for OR operators, > and I'm loathe to add such functionality without one. But in any case Anant's > proposal would accommodate adding such functionality in the future, should we > choose to do so: > > "required_features": ["foo", "bar", "baz"] --> foo AND bar AND baz > "required_features": ["foo", "bar", ["baz", "qux"]] --> foo AND bar AND > (baz OR qux) "IndexDB or WebSQL" is a concrete and present use case for OR operators, as is "IndexDB or FileSystem". Both of these are typical for current offline-capable apps. Just slightly related, I thought I'd note Chrome Store Apps specifically have an attribute in their manifest to indicate if they can be used offline. ---------------------------------------- Fabrice Desré [email protected] Feb 8 to dev-webapps Globally that looks reasonable to me, especially since we keep the default to be "run everywhere". Note that this will also have impact on two implementation parts: - syncing apps : when "installing" an app through sync, the synced-to device must check that it can run the application with the given manifest. If it can't, does it fake having the app installed to not get it back at the next sync? - updating manifests : removing or adding constraints (like asking for more storage space) can lead to apps previously supported to not be anymore, and vice versa when using sync and devices with different capabilities. Nothing impossible, but that will need some good UX to not be confusing for the user ("My app that I paid $99 disappeared!") Ian Bicking [email protected] Feb 8 to Fabrice, dev-webapps On Wed, Feb 8, 2012 at 12:00 PM, Fabrice Desré <[email protected]> wrote: > > Globally that looks reasonable to me, especially since we keep the default > to be "run everywhere". > > Note that this will also have impact on two implementation parts: > > - syncing apps : when "installing" an app through sync, the synced-to device > must check that it can run the application with the given manifest. If it > can't, does it fake having the app installed to not get it back at the next > sync? > > - updating manifests : removing or adding constraints (like asking for more > storage space) can lead to apps previously supported to not be anymore, and > vice versa when using sync and devices with different capabilities. Nothing > impossible, but that will need some good UX to not be confusing for the user > ("My app that I paid $99 disappeared!") I believe we should sync everything for these sorts of reasons, and do the filtering at the UI level. Maybe it would mean adding a .supported() method or attribute to app objects? Another weird affect, for instance, is a case where you install an app on your desktop, it doesn't "work" on your tablet, and then the developer fixes that and updates the app; it seems like the tablet should be able to see that update and start to have a working app. But if we don't sync the unsupported app down to the tablet, then the only way for the tablet to ever see the update is for the desktop to do the update and sync the new item up. That's awkward. ---------------------------------------- Mounir Lamouri [email protected] via mozilla.com Feb 8 to dev-webapps On 02/08/2012 06:36 PM, Anant Narayanan wrote: > On Feb 8, 2012, at 7:37 AM, Ben Francis wrote: >> On Wed, Feb 8, 2012 at 12:25 PM, Mounir Lamouri <[email protected]> wrote: >>> >>> I do not understand why that would be needed for the web platform? We >>> have CSS Media Queries to show a different content depending on those >>> values. >> I agree, ideally a web app should be able to adapt to work on different >> form factors using media queries etc. Including this in the app manifest >> could encourage separate apps for different form factors which I think is >> undesirable. If developers want users to know that their app works >> particularly well on a particular form factor, they could always state this >> in the app description. > > The main goal of this option is to avoid users from using an app that was > explicitly designed for mobile phones on the desktop. A lot of mobile-only > apps don't scale well on desktop sizes, and the developer may want protect > their reputation (and prevent bad reviews) by restricting usage only on > screen sizes for which they were intended. This is exactly my point: the web platforms give very simple tools to allow the same application to work very nicely on mobile, tablet and desktop using CSS Media Queries (aka responsive design). Allowing developers to block some screen sizes would allow them to take the lazy way. If they care about their reputation, they should make sure an app work just as fine on all kind of screens. -- Mounir ---------------------------------------- Ragavan Srinivasan [email protected] Feb 9 to dev-webapps, dev-webapps Hi, Mounir Lamouri wrote: > This is exactly my point: the web platforms give very simple tools to > allow the same application to work very nicely on mobile, tablet and > desktop using CSS Media Queries (aka responsive design). Allowing > developers to block some screen sizes would allow them to take the lazy > way. If they care about their reputation, they should make sure an app > work just as fine on all kind of screens. While that's a noble goal, we should provide users enough information as to whether an app is going to work on their device(s). If an app developer has not designed their app to be responsive, then we should make sure a user is aware of that so they can make an informed choice. I also think it is OK for a developer to support additional breakpoints via iterative updates to their app instead of having to do it all at once. We shouldn't punish them for that. Regards, Ragavan ---------------------------------------- Myk Melez [email protected] Feb 9 to Harald, Ian, dev-webapps, Anant On 2012-02-07 10:44 , Harald Kirschner wrote: > > The Android manifest allows to define target screen factors for apps, which > is a pretty exhaustive list (size, density, orientation, aspect ratio). > > http://developer.android.com/guide/topics/manifest/supports-screens-element.html > > Would be interesting to translate it to cross-platform. There are indeed a bunch of options, but the docs seem to dissuade developers from using most of them. `resizeable` is deprecated, `anyDensity` is recommended only for an edge case, and the three *Width*Dp attributes are recommended over the four *Screens attributes, even though the latter are not yet deprecated. My reading of those docs is that the only cases considered common by that implementation are the two we've identified along with a third in which a larger screen results in functionality bustage. But that last case doesn't seem like one that will be common for web apps. ---------------------------------------- Myk Melez [email protected] Feb 9 to Ian, Fabrice, dev-webapps On 2012-02-08 10:08 , Ian Bicking wrote: > > I believe we should sync everything for these sorts of reasons, and do the > filtering at the UI level. Maybe it would mean adding a .supported() > method or attribute to app objects? Syncing unconditionally makes sense to me too, as a simpler model that is easier to get right and that gives us the opportunity to let expert users participate in making compatibility decisions (in the event our compatibility analysis and reporting is imperfect, or when it's a question of optimality over which expert users would like to exert control). Also note that apps can become compatible via runtime updates in addition to app updates. ---------------------------------------- Myk Melez [email protected] Feb 9 to Ian, Anant, dev-webapps On 2012-02-08 09:38 , Ian Bicking wrote: Max width in particular seems a bit weird; while there are occasional cases, it's one of the more obscure restrictions. And if we only support two kinds of restrictions (max and min size) it seems odd for max size to be one of them. I've only recently been digging into the problem space, but my understanding is that it is actually a relatively common problem, as many apps that were originally designed for small screens are being deployed to larger ones. However, it's possible that HTML is better able to deal with larger screens, and app developers are now aware of screen diversity, so this is less of a problem. Media queries are declarative boolean expressions that are based on attributes of a device/user agent, so it seems fairly applicable - even if no application is going to be compatible with only print (though it tickles me to consider such an application). Touch is much more likely an issue than max size, for instance -- if you use hover in any important way then your app won't really work with touch. Media queries do identify attributes of the environment, but their purpose is to specify how to support them, not whether or not they are supported. We could nevertheless reuse the syntax, but it still seems more complex and general than we need to satisfy the use cases we've identified. It's not a cow path until more than one cow has gone down it ;) We are the second cow, paving as we go! Mooooooo. "IndexDB or WebSQL" is a concrete and present use case for OR operators, as is "IndexDB or FileSystem". Both of these are typical for current offline-capable apps. Hmm, interesting. In that case maybe this should be a prioritized use case. Just slightly related, I thought I'd note Chrome Store Apps specifically have an attribute in their manifest to indicate if they can be used offline. Indeed, we might want to do the same. ---------------------------------------- Myk Melez [email protected] via mozilla.com Feb 9 to Ben, dev-webapps On 2012-02-08 07:37 , Ben Francis wrote: > > I agree, ideally a web app should be able to adapt to work on different > form factors using media queries etc. I think we're all in agreement on this point. > Including this in the app manifest > could encourage separate apps for different form factors which I think is > undesirable. The Android app market provides such flags, and it doesn't seem to have encouraged such a development. > If developers want users to know that their app works > particularly well on a particular form factor, they could always state this > in the app description. Yes, but specifying it explicitly enables marketplaces to do a better job providing that information to users evaluating apps. ---------------------------------------- Myk Melez [email protected] via mozilla.com Feb 9 to Mounir, dev-webapps On 2012-02-08 11:44 , Mounir Lamouri wrote: > > This is exactly my point: the web platforms give very simple tools to > allow the same application to work very nicely on mobile, tablet and > desktop using CSS Media Queries (aka responsive design). Allowing > developers to block some screen sizes would allow them to take the lazy > way. No one is suggesting we allow developers to block screen sizes. Nor is this about letting developers be "lazy." Rather, it acknowledges that productive developers nevertheless sometimes make apps that don't look good or work well on all screen sizes because of limited resources, both in development time and testing devices/environments. Harald Kirschner [email protected] Feb 9 to Myk, dev-webapps, Mounir A good showcase for this, look at how many apps in the marketplace preview work on mobile. Responsive design for apps that work across mobile, tablets and desktops is just starting. And just responsive layout does not make a great mobile app experience (think Sencha Touch or jQuery Mobile). Complex apps might still rather go for separate pages. It will be a hurdle for a while, and developers should not hold off their app submission just because their app does not work on mobile; though be able to inform potential users. We should help and push developers in the right direction. --- Harald Kirschner | Mozillian Software Engineer | [email protected] (mailto:[email protected]) > [email protected] (mailto:[email protected]) > https://lists.mozilla.org/listinfo/dev-webapps ---------------------------------------- Ian Bicking [email protected] Feb 9 to Myk, Ben, dev-webapps On Thu, Feb 9, 2012 at 12:34 PM, Myk Melez <[email protected]> wrote: > > >> Including this in the app manifest >> could encourage separate apps for different form factors which I think is >> undesirable. > > The Android app market provides such flags, and it doesn't seem to have > encouraged such a development. I have personally encountered one app (a backup app) that had an unjustifiable "tablet version" that required separate purchase. It seemed like a pretty bald-faced attempt to do a per-device charge. It's less obvious that this is the case when games have tablet and non-tablet versions, but I can't imagine economics don't play a large part of form factor declarations there too. That said, if we support apps with multiple product types/levels (which we do at the receipt level, but not currently in the Marketplace) we are letting apps create their own restrictions and ongoing monetization without forcing them to use device restrictions as a hacky kind of DRM. ---------------------------------------- Myk Melez [email protected] via mozilla.com Feb 9 to Ian, Ben, dev-webapps On 2012-02-09 12:44 , Ian Bicking wrote: > > I have personally encountered one app (a backup app) that had an > unjustifiable "tablet version" that required separate purchase. It seemed > like a pretty bald-faced attempt to do a per-device charge. Oof, that's terrible! > That said, if we support apps with multiple product types/levels (which we do > at the receipt level, but not currently in the Marketplace) we are letting > apps create their own restrictions and ongoing monetization without forcing > them to use device restrictions as a hacky kind of DRM. Indeed. Also, as I understand it, we aren't going to prevent app installation on devices that don't meet the criteria. Rather, we'll use this information to guide users to apps that work best with their devices and inform users about the potential problems with nonconforming apps they decide to install anyway. ---------------------------------------- Ragavan Srinivasan [email protected] Feb 9 to dev-webapps Myk Melez wrote: > Syncing unconditionally makes sense to me too, as a simpler model that > is easier to get right and that gives us the opportunity to let expert > users participate in making compatibility decisions (in the event our > compatibility analysis and reporting is imperfect, or when it's a > question of optimality over which expert users would like to exert > control). > > Also note that apps can become compatible via runtime updates in > addition to app updates. I suspect we are mixing sync policy with UX. We should get one of the designers to chime in on the UX, but here's what Amazon does for the Kindle Fire which works pretty well. 1. You purchase an App on Device A (say, Android phone) from Amazon App store. 2. You get a notification on Device B (say, Kindle Fire) that a new App is available for install. 3. If you choose to not install at that moment on B, you can always visit your Apps Dashboard at any time and decide to install. That works pretty well for most users. We can build additional UX in case an App isn't compatible on B during step #2 above or if it becomes compatible at a later stage. Thoughts? ---------------------------------------- Ian Bicking Feb 9 to Ragavan, dev-webapps On Feb 9, 2012 7:05 PM, "Ragavan Srinivasan" <[email protected]> wrote: > Myk Melez wrote: > >> Syncing unconditionally makes sense to me too, as a simpler model that >> is easier to get right and that gives us the opportunity to let expert >> users participate in making compatibility decisions (in the event our >> compatibility analysis and reporting is imperfect, or when it's a >> question of optimality over which expert users would like to exert >> control). >> >> Also note that apps can become compatible via runtime updates in >> addition to app updates. > > > I suspect we are mixing sync policy with UX. We should get one of the > designers to chime in on the UX, but here's what Amazon does for the Kindle > Fire which works pretty well. > > 1. You purchase an App on Device A (say, Android phone) from Amazon App store. > > 2. You get a notification on Device B (say, Kindle Fire) that a new App is > available for install. > > 3. If you choose to not install at that moment on B, you can always visit > your Apps Dashboard at any time and decide to install. > > That works pretty well for most users. We can build additional UX in case an > App isn't compatible on B during step #2 above or if it becomes compatible at > a later stage. That's not necessarily unlike a "sync everything" policy. In fact the Kindle gives an index of everything you have, and that index is sync'd (kept locally, and periodically compared to the server; you can tell it's a sync because you can "refresh" the list). That index is basically metadata (title and cover), which is also all that's really in an app record (and similarly they are both pretty small). When you download something to the Kindle you are getting the actual text, which has some notable size, and moving the item to your Home page (though I think the Archive can include downloaded things that aren't on your Home page?) The equivalent of actually downloading an App would be to fill its appcache (if it even has one). The equivalent of the Home screen is, I guess, the native launcher. _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
