It feels early given that we haven't quite agreed on what it means to be "installed" (seems like the wrong word, since you can already use the site). There's also no cross-platform implementation of that idea in Firefox.

It feels early given that we haven't quite agreed on what it means to be "installed"

Depends on who "we" is above.

The folks working on the spec do have pretty good agreement, and they leave "install" up to the OS - it's fairly clear what this looks like in iOS and Android, at least (indistinguishable from a native application in every and all respects). I think it's similar in Windows from what I've read, but I've honestly not checked.

When "we" is Mozilla, then correct - we don't have agreement. We should get agreement, as we risk getting left out of the discussion by all the supporting implementations (and whatever Firefox on mobile ends up doing).

If "we" is WHATWG/HTML, then also correct I guess.

The spec defines "installed" as:

A common use case of a manifest is for a user agent to install a web application; whereby the user agent provides the end-user with a means of instantiating a new top-level browsing context that has the manifest's members applied to it. That is, the manifest's members, or their defaults, are in effect on the top-level browsing context. This distinguishes an installed web application from a traditional bookmark, as opening a web page from a traditional bookmark will not have the manifest's properties applied to it.

There's also no cross-platform implementation of that idea in Firefox.

Correct. That's part of the discussion. I'm not sure how much we want to discuss products (I'm all for having that discussion tho) - but I'm more interested in "is this good for the web" right now.

@annevk I think it would be a step backward to do not define it as install.

@firtman Also is advocating for a install button
https://twitter.com/firt/status/983848689251901440

I agree it should depend on how the OS consider the web app.
Right now on Android when you want to remove a PWA from Android it say uninstall app and it does not say remove from homescreen, the existent behaviour is inconsistent.

From every single partner I work with the one thing I hear every single time is that they want predictability and control over when the prompt would be shown.

It's interesting that we have in some ways come full circle, in that the mozApps API had install() and checkInstalled() methods.

The main intended use case for that install function was actually for third party app stores to be able to install web apps from the store's web interface, as opposed to apps installing themselves. It was combined with an installs_allowed_from member of the app manifest which defined which app stores were allowed to install the app (anyone by default). In the end we didn't really see third party app stores emerge because many APIs required apps to be packaged and signed by Mozilla which resulted in centralisation around the Firefox Marketplace. Probably for that same reason, and the fact this was a vendor prefixed API only supported in Firefox, we didn't really see install buttons pop up all over the web either. However, I can see that being a real risk for a cross-browser implementation and it could easily result in a lot of irritating app-specific install banners and prompts, as evidenced by the widespread use of prompts to install native apps.

I'm personally not convinced that the UI design space for user agents taking responsibility for this install flow has been entirely explored. I suspect that a combination of "ambient badging" and a careful use of prompts to direct users' attention could still solve this problem in a consistent and unobtrusive way, without having to hand the responsibility off to app developers.

For example, I once proposed using an app icon in the URL bar for ambient badging in Firefox whereby the app could be installed from the Control Centre, with occasional prompts to point users towards this function. It could be that this app icon appears much more predictably as app developers would like (e.g. just based on the presence of a manifest link relation in the page), and that prompts to draw attention to the icon are displayed based on browser-specific quality and usage metrics, and can be disabled by the user.

On balance I would personally suggest that the risks of exposing an install() method to apps currently outweigh the benefits and that we should allow more time for browsers to explore different solutions before resorting to that approach.

@benfrancis
Maybe a better name for install() is the following
Install.requestPermission().then(()=> {});

I think browser will be able to solve 50% of the problem but not fully because most of the users do not know how to use the browser fully and that's why we still need to create custom banner for various feature of the browser. I think in the end developer and browser eng will need meet half way to solve this problem properly.

It would be great to be able to install (add to home screen) PWAs without visiting them (install by web app URL).

Motivation:

• PWA stores (catalogs): https://outweb.io and https://pwa-directory.appspot.com.
• Enterprise apps, which needs to be installed to thousands of devices. More info: https://stackoverflow.com/q/49328396.

Chrome already supports custom install buttons. See https://www.chromestatus.com and https://airhorner.com in Chrome for Android.

More info: https://paul.kinlan.me/onappinstalled/

@FluorescentHallucinogen yes you can trigger the install but you can't have the button always. For instance if you uninstall the app you will not get the install event ever again.

1. It feels too soon. Chrome and others are still experimenting with the UI/UX. PWAs on iOS have just shipped and are still limited. I think it makes sense to be defensive and wait at least until the end of the year before introducing new APIs.

2. The beforeinstallprompt pattern seems good. The browser decides when the install banner can be shown, and the app is allowed to prevent it and show it manually on user interaction. Are there really any substantial issues with this approach?

@benfrancis wrote:

I'm personally not convinced that the UI design space for user agents taking responsibility for this install flow has been entirely explored. I suspect that a combination of "ambient badging" and a careful use of prompts to direct users' attention could still solve this problem in a consistent and unobtrusive way, without having to hand the responsibility off to app developers.

I think that's valid. And I'm inclined to push for a "worth prototyping" position from Mozilla with beforeinstallprompt, ambient badging, etc.

@simevidas, wrote:

It feels too soon. Chrome and others are still experimenting with the UI/UX. PWAs on iOS have just shipped and are still limited. I think it makes sense to be defensive and wait at least until the end of the year before introducing new APIs.

Another year or more of experimentation is fine, and I tend to concur that Safari on iOS will likely have a significant impact on how this will unfold for the Web. Right now, they don't seem to do anything different from pre iOS 11.3.

Generally speaking, please note that this thread is seeking a Mozilla position - not a general public position. The two should not be conflated.

The beforeinstallprompt pattern seems good.

I outlined the issues above... it's just that developers never know when the event is going to fire, and if it's just going to fire on every page load just after onload (I think that's what Chrome has ended up with), then what's the point of having such a complex API? This is basically what we are trying to balance out.

As I said above, I think we should exhaust beforeinstallprompt by prototyping it - along with things @benfrancis mentioned.

@marcoscaceres wrote:

I outlined the issues above... it's just that developers never know when the event is going to fire, and if it's just going to fire on every page load just after onload (I think that's what Chrome has ended up with), then what's the point of having such a complex API? This is basically what we are trying to balance out.

As I said above, I think we should exhaust beforeinstallprompt by prototyping it - along with things @benfrancis mentioned.

For what it's worth, I've always found the beforeinstallprompt approach a bit strange. It feels like a workaround to the problem that app developers found Chrome's installability criteria unpredictable but Google doesn't want to give app developers full control, so we ended up with a bit of an odd compromise.

If there was some kind of unobtrusive "add to homescreen" UI element which appeared more predictably based on simpler and less strict criteria, and then the option for user agents to add additional hints or prompts based on browser-specific quality and usage metrics to incentivise certain requirements, then perhaps neither beforeinstallprompt or install() would be necessary.

Just a thought.

If there was some kind of unobtrusive "add to homescreen" UI element which appeared more predictably based on simpler and less strict criteria, and then the option for user agents to add additional hints or prompts based on browser-specific quality and usage metrics to incentivise certain requirements, then perhaps neither beforeinstallprompt or install() would be necessary.

You might be right, but at the same time, any UA getting it wrong basically spoils it for the rest (or for themselves). Opinions will vary here, but, for instance, Apple's "Add to Homescreen" being buried away might never change, leading to web applications having to UA sniff AND possible absolutely position helpful instructions depending on device (iPhone on top, iPad below):

So, unless all browsers have a standardized mechanism, the web suffers. This is not an iOS problem either, like with FlipKart and ambient badging:

(in the example above, you have to sniff basically browser, possibly browser version, and Android version... that ain't gonna scale).

In any case, interested to see what our (Mozilla) UX/UI folks come out with over the next year or two.

Original: https://twitter.com/burkeholland/status/989051650718486529 😜

Chrome is considering moving to something that is equivalent to the proposed "Install API". (I say equivalent because at a low level, "developers must listen for the beforeinstallprompt event, and call prompt() on it with a user gesture to show a modal add to home screen prompt" (source)--but these details could be abstracted away into a method called showAddToHomescreen().)

We will work this out in the spec itself. Don't require a position.

Hello,

It would be helpful to hear if Mozilla does have an official position on this API at this point. Due to recent developments (see w3c/manifest#835) we now have a situation where the API could get removed from the spec without interest from Mozilla.

If that's the case, so be it, but as far as I can tell, Mozilla never explicitly expressed a signal on this either way. If you want it, please indicate so.

Sure, with regards to BeforeInstallPrompt, Mozilla's position is that it's "non-harmful": Mozilla does not see this specification as harmful, but is not convinced that it is a good approach or worth working on."

With regards to installation and Web Manifest in general, Mozilla's position is that it is "worth prototyping" - Mozilla sees this specification as conceptually good, and worth prototyping, getting feedback on its value, and iterating. We are prototyping support in Firefox Preview and we've added support for Web Manifest in Firefox Desktop's Dev Tools.

Hi @marcoscaceres .

Thanks for clarifying Mozilla's position.

Sure, with regards to BeforeInstallPrompt, Mozilla's position is that it's "non-harmful": Mozilla does not see this specification as harmful, but is not convinced that it is a good approach or worth working on."

I see...

😂

The WG concluded to remove beforeinstallprompt from the spec.