Should we inform the user when they visit a web site which specifies an app manifest and can therefore be installed/bookmarked to the homescreen? Or should we just make use of this information when they actively bookmark a page, as a progressive enhancement?

We can bookmark any website to the homescreen, not sure what this adds?

I think I agree, and this isn't explicitly called out in the W3C spec. Let's close this and re-open if it's called for in a UX spec.

After prototyping Web Manifest features a bit more I've changed my mind on this (see discussion in bug 1003890). I do think "Add app to homescreen" is something different to "Add page to homescreen". "Add app to homescreen" can be offered as an additional option when a manifest link relation is detected (<link rel="manifest" href="...">). "Add app to homescreen" could use the app name/short_name, icon and start_url defined in the manifest and if the display mode is defined as one of "fullscreen", "standalone" or "minimal-ui" it could also install an app into the app registry using the Apps API (see bug 1075704) so that it will be launched in an app window, get its own data jar etc. If the display mode is "browser" it could still use the metadata from the manifest but add a bookmark to the homescreen so that it will be launched in a browser window. "Add page to homescreen" could add a bookmark to the homescreen using the document title, icon and current URL of the page. For example, if I was viewing a news article at http://www.bbc.co.uk/news/technology-27793464 then "Add page to homescreen" would add a bookmark to the news article with the article title and page icon, whereas "Add app to homescreen" would add an app launcher for the BBC News app at http://www.bbc.co.uk/news/ which could open separate from the browser. If both were added then the article bookmark could link directly to that article inside the app using App Scope. We could consider also prompting the user when: <meta name="application-name" content="BBC News"> <meta name="mobile-web-app-capable" content="yes"> ...are detected for backwards compatibility, although the latter was never standardised. With all of this in mind, it may actually be valuable to let the user know when they have navigated to a web app which can be installed on their device. This has been done in a non-standard way on iOS and Android for a long time, with web apps themselves prompting the user to install them in standalone mode. Implementing this feature would allow users to more easily organically discover and install web apps as they browse the web, rather than have to install them from an app store. I think it's really down to UX whether we want to show the user a door hanger style notification or just leave it to users to discover the option in the overflow menu though.

Attached is a UI mockup, just an example of what is possible when we detect a manifest link relation.

Comment on attachment 8507015 [details] UI mockup We need come come up with a nice set of criteria for when to display the door hanger automatically (if ever!). Like: 1. the user has visited the site x number of times in the last x number of days. 2. the site uses HTTPS. 3. and so on...

Comment on attachment 8507015 [details] UI mockup Hi Francis, what do you think about the idea of showing a doorhanger style notification to inform the user that the current page is part of a web app which can be installed? I think this is a great way of helping users organically discover apps as they browse around the web, and of teaching them that they can install an app directly from a page they browse to. Do you think the doorhanger is too intrusive? If so, perhaps we could show an icon somewhere to indicate that the current page provides a web manifest instead.

(In reply to Marcos Caceres [:marcosc] from comment #5) > We need come come up with a nice set of criteria for when to display the > door hanger automatically (if ever!). Like: > > 1. the user has visited the site x number of times in the last x number of > days. Gecko won't know this, but Gaia could probably figure it out from the places database. > 2. the site uses HTTPS. That seems a bit arbitrary. I would personally prefer to either always show the doorhanger or never show the doorhanger rather than trying to do something clever (and therefore unpredictable for the user).

Francis, note from comment 3 that this has been done in a non-standard way on iOS and Android for a long time, with web apps themselves prompting the user to install them in standalone mode. The idea here is for the browser itself to show a standard notification which only appears if the app isn't already installed and can be permanently dismissed by the user if they're not interested.

Please also don't assume that just because a site has a manifest it is necessarily "installable". Apps created for iOS tried this and it ended very very badly. Please see [1], in particular: "Despite these 1097 sites claiming they can be used as standalone, what we found was that the majority of web apps (90%, or 324 out of 360) can not be used as standalone. Only a tiny fraction (10%, or 36 out of 360) are able to run as standalone - and 28% of those had significant limitations (described below). There is, in fact, a greater percentage (12%) of desktop sites masquerading as installable web apps than there are actual standalone applications." The bar for "installability" needs to be set fairly high. A manifest is nowhere near enough - as it's as reliable as Apple's `apple-mobile-web-app-capable` signal (i.e., extremely unreliable). [1] https://github.com/w3c-webmob/installable-webapps/blob/gh-pages/ios_standalone/README.md

Marcos, I'm not sure what you're imagining an "installable" app would look like in Firefox OS. I suspect that by "installable" you might be assuming I mean "doesn't need any browser chrome" or is a "one page app" or "optimised for mobile" like on iOS, which isn't the case. From your research it sounds like a lot of web developers have added the proprietary "apple-mobile-web-app-capable" meta tag to their web pages without really understanding what it does. That isn't surprising because its name doesn't necessarily imply that it runs standalone separate from the browser and is restricted to only one web page, which is how iOS interprets it. I think manifests are different. Firstly, if a web developer links to a manifest from their web page which is described in the spec as a "Manifest for web applications" it's a pretty good indication they consider their content to be a web application. Even then, the default display mode for a manifest is "browser" which would open in a normal browser window in Firefox OS with full browser chrome. This doesn't require the web content to work in any special way. If the developer explicitly opts in to another display mode like "fullscreen", "minimal-ui" or "standalone" I think that's a pretty strong indication that they intend their content to work separately from the browser with a reduced set of browser chrome. As I've explained before, for Firefox OS the conclusion I have reached is that "installing" an app is like slicing off that part of the web to be used separately from the browser. That doesn't mean that the app is restricted to one web page or has no navigation chrome, and if the developer hasn't specified how much chrome they want in the manifest then the failsafe is to default to the "browser" display mode which just opens in a browser window anyway. I don't think the " bar for 'installability' needs to be set fairly high", I think the bar for "not showing browser chrome" or "opening separately from the browser" needs to be that the developer explicitly opts-in to that behaviour.

(In reply to Ben Francis [:benfrancis] from comment #10) > Marcos, I'm not sure what you're imagining an "installable" app would look > like in Firefox OS. I suspect that by "installable" you might be assuming I > mean "doesn't need any browser chrome" or is a "one page app" or "optimised > for mobile" like on iOS, which isn't the case. No, I've documented what I mean by them here (though this is a bit dated now, the core components are there): https://w3c-webmob.github.io/installable-webapps/ My view is generalized, not browser or OS specific. The data/examples I present are supposed to represent current practice of what we see in the wild irrespective of preconceived notions of what constitutes an "installable webapps". Remember that the selection is from the top 78,000 sites of the Web (according to Alexa), which presumably represent a significant bulk of what users access on the Web. > From your research it sounds like a lot of web developers have added the > proprietary "apple-mobile-web-app-capable" meta tag to their web pages > without really understanding what it does. That isn't surprising because its > name doesn't necessarily imply that it runs standalone separate from the > browser and is restricted to only one web page, which is how iOS interprets > it. Yes, but neither does <link rel="manifest"> > I think manifests are different. Firstly, if a web developer links to a > manifest from their web page which is described in the spec as a "Manifest > for web applications" it's a pretty good indication they consider their > content to be a web application. This is not a safe assumption to make. The whole concept of a web apps is totally nebulous. We've lowered the cost of adding a manifest to nearly 0. Imagine that the manifest format could ship with every wordpress blog - and aspects have already been included into HTML5 boilerplate. This means that a lot of the time authors won't even know their app includes a manifest. In the research, I showed that this was a problem because people didn't bother updating the defaults (or even know about them!). > Even then, the default display mode for a manifest is "browser" which would > open in a normal browser window in Firefox OS with full browser chrome. This > doesn't require the web content to work in any special way. Yep. However, some shared sites or templates may decide that "standalone" looks nice and include it as the default. We can't really control that. > If the developer explicitly opts in to another display mode like > "fullscreen", "minimal-ui" or "standalone" I think that's a pretty strong > indication that they intend their content to work separately from the > browser with a reduced set of browser chrome. As above. This is not a safe assumption. The research that I included showed that the majority of developers either lie, don't test their apps, or don't care. So, I don't buy that it's a strong indicator. We can also see this in FxOS's store. Devs add apps to the marketplace, but they do not behave or come close to anything resembling an app even though those are listed as apps. We could do a similar analysis to the iOS study on the FxOS marketplace to get a picture of reality. From my own experience, I find parallels to what happened with iOS. > As I've explained before, for Firefox OS the conclusion I have reached is > that "installing" an app is like slicing off that part of the web to be used > separately from the browser. I'll like to discuss this more in Portland, as I'm not really getting what you mean. Your recent blog post on the subject of installable apps seemed very closely aligned to my thinking about this topic - but I'm still not getting the whole "slice of the web" thing. > That doesn't mean that the app is restricted to > one web page or has no navigation chrome, and if the developer hasn't > specified how much chrome they want in the manifest then the failsafe is to > default to the "browser" display mode which just opens in a browser window > anyway. > > I don't think the " bar for 'installability' needs to be set fairly high", I > think the bar for "not showing browser chrome" or "opening separately from > the browser" needs to be that the developer explicitly opts-in to that > behaviour. Ok, let's got through a random selection of apps in Portland from the marketplace (say ~100). Presumably, those apps include a manifest (we can look for ones that are "fullscreen" as a proxy for display mode even), and see how they work. From my personal experience, I remain skeptical that not setting the bar high will yield quality applications - but I'm totally opened to be shown otherwise from looking at the marketplace.

(In reply to Marcos Caceres [:marcosc] from comment #11) > I remain skeptical that not > setting the bar high will yield quality applications - but I'm totally > opened to be shown otherwise from looking at the marketplace. I'm not sure how to respond to the argument that "if we make it too easy, too many developers will use it". The low barrier to entry is the web's biggest strength. Yes that results in a lot of low quality content, but I think that's something we have to solve through evangelism, curation and good search engines which cut through all the crap to get to the good stuff. IMO doing this analysis of our curated Marketplace would just be reflection of how stringent our review process is to allow apps into the Marketplace, not a reflection of Open Web App manifest design. All I'm proposing in this bug is that the user agent has a standard mechanism to offer to install a web app, rather than encouraging littering the web with install buttons or annoying app specific prompts which won't go away :) It might be that UX feel this is too intrusive, or they might think it's a useful hint to the user which is better than having to hunt for an "install app" button buried in a menu. Ubuntu desktop takes this approach for Unity Web Apps and it actually helped me discover a few web apps I didn't know I could install on my desktop and now I use them instead of native apps. I know you don't think that manifests are necessarily just for installing apps, but that's currently how every web platform is using them and something which is useful to standardise IMO. Very happy to discuss this some more in Portland :)

Please see the latest web manifest spec at: https://mozilla.box.com/s/vnrvul69t00l1nv8oq2l. For now, I've opted to not show any special notification to users if a web page has a manifest defined. But the user will have the option to save the associated web app if they choose to add the page to homescreen.

Comment on attachment 8507015 [details] UI mockup Please see latest web manifest spec at https://mozilla.box.com/s/vnrvul69t00l1nv8oq2l

Firefox OS is not being worked on