Allowing only site-triggered install prompt

[photopea]

Hi folks, do you really like this idea, that a user-agent will "analyze" a website somehow and decide, if it is appropriate to show an install prompt? It can be disturbing, if the "analysis" is wrong. I also hate the fact, that a browser makes such decissions (browser manufacturers can show the prompt more often for websites, which pay them, nobody will ever find out). I think that the browser should be as "invisible" as possible, and each action should come from the user, or from the website with a users permit.

I am using the following code to be able to trigger an install prompt.

window.addEventListener("beforeinstallprompt", function(e){  e.preventDefault();  myEvent=e;  });
if ("serviceWorker" in navigator)  navigator.serviceWorker.register("sw.js", { scope: "./" });  
//  I call myEvent.prompt();  later, when user clicks Install

The problem I have is, that if both the website and the user want the site to be installed, the user-agent itself becomes an obstacle (by not dispatching "beforeinstallprompt"). What about replacing it all with this:

navigator.install();

It can throw an exception, when installing is not appropriate. If you think there is a risk of "attack" by calling it too often, we can deal with it the same way we deal with alert(...). Imagine if alert(...); worked only on Mondays and only between 12th and 37th minute of each hour. That is how I see the current draft now.

[marcoscaceres]

Yeah, we've gone back an forth for years between the current model and the .install() model. The problem with the .install() model is that we will end up with "Install my App!" buttons all over the web, which we don't want.

Browser vendors are exploring alternatives (e.g., ambient badging)... there might be a middle ground for this, but we are still trying to figure out what it is as PWAs become a thing.

[photopea]

So you want give browsers the ability to limit such buttons with "Install my App"? The button would be hidden. And neither the website, neither the user would understand why.

I think your should not be afraid of such buttons "all over the web". Websites always adapt to users, and when e.g. less than 1% of users use such button on a specific website, it will disappear (or will be moved to some less visible place), because the space on the website is "expensive". It would be like having an add, which is not clicked by anybody (nobody wants such ad). So I believe, that at the end of the day, Install buttons would be only at places where it makes sense.

And even if you still want to have power to limit such buttons, giving this power to the browser and probably any other solution could make users very angry , and is a huge space for corruption (a black box oracle, which decides things for us).

[kenchris]

Google is toying with a new way of doing this.

Ie. they might stop prompting by default when the engagement threshold is triggered, but allow the site to do it after that point.

@mgiuca might be able to tell more.

[photopea]

I would like to let my users start my webapp from a home screen icon and without the browser controls around it. When will it be possible in a Chrome browser?

[marcoscaceres]

You should be able to set display: 'fullscreen': https://www.w3.org/TR/appmanifest/#display-member

[photopea]

But how can my users add the icon of my webapp to the homescreen? Can I create "Add to homescreen" button in my webapp somehow?

[madmoizo]

Firefox pattern seems good to me (a add to homescreen icon directly in the address bar and a android icon if the webapp is already installed). Chrome should provide the same kind of UX on every platform because on desktop, the add to desktop is a hidden features, hard to explain to the end user.

Install my webapp! buttons are a "risk" like enable push notification/geolocation! is one too. It's not necessarily a bad thing, it just needs some guidelines. There are already download for mac/linux/window buttons for installables software. There are already android app on google play and available on the appstore buttons for native app. Why a Install the webapp icon can't stand near these last for a single point of "get my product"? Today, it's easier to wrap a webapp url in a electron app which can be downloaded in one click rather than explain to the end user how to add the webapp to desktop.

it's ok if it's on the browser side, people trust browser more than websites. Webapp installation could be triggered like any others permissions, instead of an auto prompt with obscur rules which differ from a browser to another. Yes, it can be misused, like any other things on the internet (permission prompt on page load, i'm looking at you) but browsers should not concentrate on "what is the best moment to prompt the user to maximize their engagement", it's a developer's concern.

@photopea you can't, browsers decide when it is the appropriate time to show the prompt and provide a way to do it manually (three dots > add to homescreen on Chrome Android, three dots > more tools > add to desktop on Chrome desktop, add to homescreen icon in address bar on Firefox Android)

[photopea]

That is quite bad. I think webpages should have the ability to trigger the "installation" to a desktop. What kind of misuse do you mean? It is not a real installation, but more like a bookmark. It is till safe, "sandboxed" in a browser environment.

[photopea]

I implemented the current "way" to my webapp in the past, but it was hard to explain to users, that they have to wait until their browser "feels like" they may want an installation. And if they accidentally refused the installation, there was no way to trigger it again, it did not work even the next day. The rules are not clear, what does "the browser feels like" mean? (it was Chrome in my case)

[marcoscaceres]

@photopea, we understand your frustration - but please understand that it will take time to figure out the right solution here.

We (browser makers, developers, and End-users) know that we don't want "INSTALL MY FANCY APP" buttons all over the Web - but we also know that developers want user's to be able to easily install their web applications. We also know that we have all these "browser feels like" heuristics, that we can make use of... we just need to put them all together in a way that balances everything out.

The above will still take time to figure out, however. If we move too fast, we risk screwing things pretty seriously on the Web. We need to be disciplined in how we add these kinds of features.

[marcoscaceres]

@photopea, in case it helps, it might be good to read how we assume it works at the moment: https://www.w3.org/TR/appmanifest/#installable-web-applications

See in particular, the part about installability signals. Hope that helps you understand where we are at.

[photopea]

@marcoscaceres I see where the specification is at the moment. I think there are two key points, where I see problems.

• User agent should not be the "robot", who decides things for us. Decisions should be made either by user, or by a program developer. I can see of browsers becoming 20% larger (in terms of MB), because they will embed some AI libraries, to be able to claim, that their decissions are better than the decissions of other browsers. If you want to guarantee some level of "security", make strict rules (e.g. HTTPS + manifest + something else), that will work for all browsers. Don't make it up to browsers to decide. Web authors would have to test their product with many borwsers to make sure it works everywhere. We are getting the web back to 90s.

• "INSTALL APP" buttons all around a web is nonsense. The area of the webpage is "expensive", and when some button is not clicked, it is replaced by something else. Such buttons can be everywhere only for a couple of months, until authors see how effective they are, and most of them would remove these buttons. Just like we have Social media buttons now.

Please, think about it. Don't make browsers take decissions without specific rules. It may add a lot of headache to both web authors and visitors.

[marcoscaceres]

@photopea, thanks. Will definitely take your feedback into consideration.

[mgiuca]

Hi, sorry I've missed this discussion until today. This is something I think about all the time.

I do mostly agree with @photopea and I think the Google Chrome team has been gradually coming around to the position that developers should be in control of this, not the UA. We've gone from a relatively unpredictable engagement requirement (requiring heavy use of the site before the prompt can trigger) to an almost instantaneous one: we now deliver the BIP event after a few seconds of interactivity with a site. This means if the user immediately closes a site, they won't see it, but any normal usage will be able to show the prompt.

We should recognise two separate issues:

• the static issue of which sites are eligible (manifest, correct icon size, fetch handler, etc, etc), and
• the dynamic issue of under what circumstances do we allow the prompt (after the user has engaged with the site by a certain amount).

I am not concerned about the dynamic issue, because it doesn't present a compatibility risk. Different browsers can have different dynamic (engagement) requirements, and it doesn't "break" sites because the developer doesn't need to design differently. You just need to know that you may need to wait awhile before the prompt event comes up.

I am concerned about the static issue. I think it's a web compat problem if different user agents have different requirements for a site to be eligible to receive a prompt, because then, as you say, we're in the 90s world where developers need to test that they meet the criteria for each major browser. That harms us (the browser manufacturer) too, because then we can't change our policy in the future. (Just as in the 2000s, IE was ultimately harmed by being tied to its own de facto standards.)

User agent should not be the "robot", who decides things for us.

In some sense. The UA will always play a role in deciding things on behalf of the user. After all, they are the user agent (authorized by the user to act on their behalf in making certain decisions). That's why I am OK with requiring a minimum engagement, and with having a browser-specific policy on when you can re-show a prompt if it has been rejected by the user. As well as, of course, UA-specific UI for manually installing the site without a site-triggered prompt.

What's weird about this is that we allow sites to spam notification permission requests immediately (which arguably is requesting a more invasive capability than installation), but we're more conservative with showing the install prompt. I think we should be more consistent about this.

Web authors would have to test their product with many borwsers to make sure it works everywhere. We are getting the web back to 90s.

Yep, I definitely share this concern, as stated above.

Chrome has tried to make the "whether or not you are a PWA" check as transparent as possible, publishing the checklist and providing a tool to verify whether your site is eligible. But up until now, this has been a proprietary Chrome feature.

I definitely think we'll want to lock this in at the specification level at some point, so the Lighthouse tool can tell you definitively whether your site meets the specified requirement for installability in all browsers. However, I think at the moment we're still early on in the life cycle of this feature, and people are worried if we codify this, we won't be able to increase the requirements later (e.g., by enforcing that your fetch handler actually serves content).

[madmoizo]

Different browsers can have different dynamic (engagement) requirements

I don't agree, you will end up with the following on every website:

you should be prompted for installation automatically but: 
- if you are a X user: wait 5s
- if you are a Y user: click somewhere
- if you are a Z user: visit the site twice 

edit: I mean automatic engagement is fine if the developer can prevent it

What's weird about this is that we allow sites to spam notification permission requests immediately (which arguably is requesting a more invasive capability than installation), but we're more conservative with showing the install prompt. I think we should be more consistent about this.

Definitely. And educate developers is the way to go. Today, it's obvious that ask for a permission without context will lead to high rate of "block". It is not the UA role to show a prompt when it decides to. It's like automatically ask for geolocation permission if the GPS is active on the terminal. There is a requirement -> UA check the requirement -> requirement is satisfied -> UA allow the developer to prompt the enduser -> developer ask UA to prompt the user at the right time in his context

I think at the moment we're still early on in the life cycle of this feature, and people are worried if we codify this, we won't be able to increase the requirements later

Agree, but we are already in the "later" part Edge made a move with auto index PWA in the store depending of their own quality criteria and Chrome already gives guidelines in lighthouse. Edge considers service worker as an ehancement when it's big warning in lighthouse if it's missing.

check "quality signal of progressive webapp" part https://blogs.windows.com/msedgedev/2018/02/06/welcoming-progressive-web-apps-edge-windows-10/

[photopea]

Guys, I am horrified by your calling installation as "spamming". I can't see what would be more spamming in window.install() than in window.alert() ? Both would "pause" the webpage and require the user to interract, to be able to return back to the site.

Why we are not limiting the alert() in any way (e.g. the website would have to get a "permission" to alert)? Why we don't see 90% of webpages alerting messages right after you visit them? I think your idea of the effect of allowing "simple install" is absolutely misleading. What makes you think any website would want to fire install() at the user right after he visits it? That would be like a shop owner shouting at you right after you enter a shop. You would probably never go back to that shop. What you are suggesting is forbidding the shop owner to say a singe word during the first 10 minutes in the shop. So even if both the customer and the shop owner want to say something to each other, you are forbidding them to do so.

I am really shocked that you can not see it and I have to explain it to you in these terms.

[marcoscaceres]

Why we are not limiting the alert() in any way (e.g. the website would have to get a "permission" to alert)?

We do limit it. The browser only allows you to call it a few times at certain rate - then asks the user if they want to stop it from showing alerts.

I am really shocked that you can not see it and I have to explain it to you in these terms.

With all due respect, we’ve been at this a few years (~5 now). I’d encourage you to search through the closed issues around installation, install prompts, and install buttons. We’ve done extensive research into this problem and will still take a while to work out. It’s not as trivial as you make it sound.

[photopea]

The browsers may choose if they want to provide an option for restricting "Alert" calls by the webpage. So you do not limit it, but some browsers do. But you want to limit the installation "by design", directly in the standard specification. That is a completely different thing. Imagine, if each website had to go througn a complex process to obtain some permissions to call "alert". Web standards would be so much more complicated.

I have already seen many reasons in this thread, which I think summarize your thinking about this issue over the past. In general, I think you underestimate the power of "natural mechanisms". When a webpage is abusive in any way, visitors go away. No author wants his visitors to go away. So in practice, "abusive" behaviour (playing sound right after pageload, going Fullscreen without any user input, overriding the Ctrl+N shortcut) is used only when it is really needed (and when the user certainly expects it).

You may think you are limiting abusive webpages from harming the user, but in fact, you are limiting all webapps from getting closer to native apps.

[MatteoWebDeveloper]

Hi, I thought to share my opinion regarding this topic, I share a lot of points of @photopea. I appreciate @marcoscaceres replies, you gave me more insight about the problems spec/browser are having. I hope this post will help you and if there is anything I can do I am available to help.

I will start with the problems and then looking for some solutions.

All this points comes out when I started to integrate PWA myself, are problem I had to discuss with business and designers.

Problems

1. Unpredictable install action You have an event to listen when the banner comes up. You can even postpone the banner. If I have a page where I explain my service and I have a section where I place an install button, I need to create a design which takes into account when I can trigger the banner and when I cannot. One where you can click a button and it will open web app install banner and another one where you need to train the user to install the web app through the browser UI (setting -> add to homescreen). In the later case I would need to create at least 6 screens to explain how to do it because we have two main mobile browser and 4 desktop browsers.

2. When you uninstall you cannot install it again This problem I think is quite serious here. Website are visited and dismissed frequently so I guess is common the following case: you go to a website you think is a good service, you add to homescreen then after a some days you realise you are not using it that often and you remove it. But people change their needs and habit maybe in 4 months they will need that service again and they could change their mind and become a regular user. A product is never finish, you add new feature, improve, change products but next time they visit they will not have a way to install, you will have to train them how to use the browser and click on setting and find the menu item add to homescreen.

3. browser web app install inconsistency I already see we are going toward that direction. Any browser is using a different approach. Chrome have a banner, Edge use the window store, Safari you still need to use the share button, Firefox add to homescreen badge. It makes it hard for developer and it is even more problematic because we cannot feature detect these behaviours.

4. inconsistent permission UI. I consider add to homescreen a permission screen. It's hard for a user to keep track of all differences browser UI. We should be more consistent, even because user already think popup as virus or dangerous thing to close. If you give them a look which is similar they will be little bit less worry about them.

Possible solutions

1. block add to homescreen after two try in the same day I think add to homescreen popup should not display immediately by default. User can trigger the install permission only when they click on a UI element which is not on position fixed/absolute or even if that element has parent with those attributes. it should be a genuine user interaction. If the install permission is abused the domain should be punished and here is up to the browser decide to suspend for days/weeks/months or forever.

2. web app === app User should not bother about technical details. Browser should communicate correctly to user. For instance if a website have manifest which use display standalone should be consider an app if it does not should be consider a link because it opens with the browser shell. web app => open independently website => open within browser

3. badge increase noise It will sound contradictory here I kind of like ambient badges but I am worry we are going to confuse user even more:

   

   When I tested ambient badge with some users they thought it was going to add the website to the browser homescreen not the phone homescreen. Also we have two home icon very similar. I think google drive got this better.

   

   If we leave the website to explain why they need to add to homescreen they will do a more contextualised job than a browser fit all solution. I do not think ambient badges are something user will use often also. But if we cannot have better control on install action this is probably the best third option, only if its implemented consistently across browser.

4. app store windows took an interesting move when they added PWA in the window store. We trained user for years that apps are inside app store. It is intuitive for user to keep doing that. If you ask a user to install an app where they think they will go. I am sure they will search first on the app store. This solution would be my second best option for installing PWA but I guess Apple will never agree on this so probably better rely on a more consistent option.

I hope this post helps and happy to carry on participating on this topic. Thank you for listening.

[marcoscaceres]

Thanks @MatteoWebDesigner for the input. I share your concerns that there will be (or there is already) so much variance across browsers that helping uses will actually require UA sniffing (and showing help screens specifically for each to help users manage their PWA installations).

To reframe the constraints which would need to be in place for .install() (using some web spec jargon):

• Must be "SecureContext" (means basically HTTPS)
• Must be triggered by user activation (click).
• only possible on top-level browsing context (no iframe).
• Optional, time limited (like pop-up blocker rules).

I think some "installability signals" requirements might be too onerous (e.g., MUST have a service worker, MUST be mobile capable, etc.). We could simplify it to the above.

Then we just block away the beforeinstallprompt stuff. We get most of the benefits we (browser vendors) are after... and we make devs happy, because they have control over installation process.

@mgiuca, thoughts?

[photopea]

@marcoscaceres I still can not see, how is window.install() more dangerous or intruding than windows.alert() ? Why it can not be handled in the same manner and has to have so many restrictions? Even if the user installs the app without knowing "what it means", the app will still run in a browser sandbox, without getting any extra privileges. We are just talking about the more fancy bookmark. Browsers don't forbid you to make HTTP bookmarks.

[marcoscaceres]

@marcoscaceres I still can not see, how is window.install() more dangerous or intruding than windows.alert() ?

Let’s consider the inverse: we know alert() is terrible for users, why would we want to replicate it or anything that approximates it?

Why it can not be handled in the same manner and has to have so many restrictions?

As above. If we know something is harmful, why should we use it as precedent? Why would not try to come up with something that avoids legacy problems?

Browsers don't forbid you to make HTTP bookmarks.

You === user, sure. But websites cannot make the bookmark. That’s the core distinction here.

[MatteoWebDeveloper]

I agree with @marcoscaceres we should not carry on copy features which are a bad legacy we should try to make the ecosystem better. I think the restriction proposed are fair.

Especially if that's allow dev to have a consistent way to trigger install, I am happy for the trade off.

The iframe restriction is very good. You could even add same origin script. If possible another restriction where you can detach if the click is triggered on element which do not cover the entire screen. That's a very common strategy for adverts to be clicked automatically but I guess is hard to create a spec around something like that..

Thank you again @marcoscaceres

[firtman]

Today's situation: a broken user experience; on some devices users will see an "add" (they are afraid of using "install") prompt sometimes (based on beforeinstallprompt), on some other devices, there is no prompt. Designers are creating UA-dependant floating dialogs and screenshots or animations to show the user how to "install" the app based on the current browser and OS. Therefore, users might not understand what's going on, or how an app can be installed and we are back to techniques based on UA sniffing. I think this is a current issue for the Web App Manifest "installation".

What to expect: The experience should be more consistent between platforms and let the web content offer an install button is actually the good idea. Users don't have a "store" to install these web/apps, so the UA is the store. While we can't force UAs to use a consistent UI for a native installation, we can offer web developers an API to request that behavior from a consistent UI within the boundaries of the website's canvas, if they want to.

I agree that the installation dialog should only be available when some conditions are met, both from user interaction and requirements from the site. Also, following some ideas recently implemented for Web Push permission dialog, if the user rejects or dismisses the dialog, UA can remove support for the API for that origin for an amount of time to promote authors to use it with responsibility. Suggesting a non-modal dialog sounds like a good idea.

I'm not sure though if the install() method should also have some optional or mandatory checks that can be made to be sure the icon/app is not already installed. It might be an optional attribute, a different interface or a different API, such as in:

navigator.checkIfInstalled().then( installed => if (!installed) navigator.install() ); I'm not sure if there is currently a definition for a key value for an "installed webapp", such as the Manifest URL; Android is currently experimenting with this thanks to WebAPK installation, but it's a side effect of a different API, not something part of the Manifest spec.

[photopea]

I have seen the installation offer in mobile Firefox yesterday. The browser itself shows the install option over the whole screen, right after you visit the website. After you dismiss it, it adds the install button next to the site URL (in the browser UI, making the URL field smaller). And the site author can not do anything about it.

Please, remove these automatic "self-deduced by UA" offeres from the specification completely. The "installation" should be initiated only by the visitor = site author (I think about the author and the visitor as the same side, since the goal of the author is to satisfy the visitor).

I don't think the window.alert() is some legacy monster, which ruins the web experience of the whole humanity. Just because you let authors interrupt visitors, does not mean they will interrupt them all the time. You underestimate the "law of free market" - visitors avoid interrupting websites. So in the long run, the website is either visited a lot and not interrupting, or interrupting, but not visited by anybody.

[firtman]

@photopea you might be able to stop that banner preventing the default behavior on "beforeinstallprompt". But I agree that a banner sounds more legit if it's opt-in, not automatic. I'm not sure about the badge in the URL field though, that seems like a valid UX from a UA point of view. If your website is installable, offering an option within the UA user interface to install that sounds good to me.

[photopea]

"If your website is installable, offering an option within the UA user interface to install that sounds good to me." - I completely disagree. The page could be "buyable", so the UA would add the Buy button. Or the page could be "schedulable", so the UA would add "Schedule" button. Or the page could be "callable", so UA would add the "Call" button.

UA interface would get extremely messy (or extremely large, giving less area to the site content). The behavior would vary across UAs, so the author can never be sure, how many users are going to get angry on some minority UAs. All such things should be only allowed in the website content area, so site authors have control over them. If we give UAs so many chances to improvise, we only create the space for UA users to argue with UA authors in the future decades.

[firtman]

That already happened... what about bookmarking (for example, the star icon on Chrome URL bar)? Do you want browsers to stop allowing your website to be bookmarked? Same with "reader view" or similar stuff. UAs are already offering actions for your content. At least we have this spec, there is nothing available for bookmarking or 'reader mode view' unfortunately.

The web app manifest defines what options do we have for how to treat "installation", so if a browser supports the spec I don't see a problem with the "install" action offering within the UA user interface.

[MatteoWebDeveloper]

@photopea @firtman I also agree ambient badges could create more noise within the browser UI but I do not think they are a critical problem if we have a consistent way of installing with window.install().

I also think browser they adapt over time to have a more suitable UI experience, you can see some old version of Chrome and Firefox below.

For instance they knew bookmark was not a feature suitable for mobile and that's why they adapt to the new mobile model. PWA is a big experiment I think is good we are learning and trying new UX but I do think if Firefox/Samsung browser will realize ambient badge is terrible idea or they can use that space for something more important I am sure they will change it.

In any case the User Agent UI is something which goes beyond the spec and we cannot create rule for that, but is good we are letting know to browsers eng which are our preferences.

[marcoscaceres]

Thanks everyone for your input. Good point from @firtman about being able to check if the app is already installed - it's definitely a requirement.

I think we now want input from stake holders/implementers:

• @mgiuca and/or @slightlyoff (Alex originally proposed beforeinstallprompt, so I think his input would be really great here now that we've seen this play out over the last few years),
• @andreasbovens from Mozilla (who did a lot of the pioneering work on ambient badging at Opera) and @snorp (who is working on Firefox for Mobile and has opinions around this),
• and from the folks at Microsoft who are working on PWAs, like @patrickkettner and others.

If we get consensus that the current UX situation is not ideal, then we can start considering adding an API based on the requirements listed thus far:

• Must be "SecureContext".
• Must be triggered by user activation.
• By default, only exposed on top-level browsing context.
• Optional, time limited (like pop-up blocker rules or rate limited payment request).
• Must provide a means to check if app is already installed.
• For backwards compat, browsers can continue to use ambient badging, installability signals, etc.

Anything I've missed? Awaiting implementer interest before continuing.

[mgiuca]

I don't have a lot of time to reply in detail right now, but I chatted with @dominickng and will try to chat to @slightlyoff next week.

Dom and I have a rough consensus that we can make the requirements more predictable, and spec them. That should resolve the ongoing complaint that it's hard for developers to know when they'll be able to call this API (and differs across browsers and across time).

I think the specific shape of the API (beforeinstallprompt vs more ergonomic install method) is orthogonal to the changes being proposed. We can achieve all of the above rules without changing the API (though, perhaps it is good to have a clean break and change the API surface at the same time).

A request: can we stop using alert as an analogy for install prompts? Alert is widely regarded as a mistake, and we should not be using its existence as an excuse for designing similar APIs. I find a more helpful analogy is just the fact that sites can show their own internal HTML prompt or scrim on top of their own content. To me, that justifies an API that shows a prompt over the developer's own content.

[marcoscaceres]

Over on the Mozilla standards positions repo, I've written a summary of where I believe we are at on the Web with regards to PWA installation. I'm hopeful we will get some additional input from our privacy and security folks.

[kenchris]

Involving @kirupa and @boyofgreen (and @andreasbovens as Marcos spelled his github username wrong above)

[kenchris]

A bit of info from the new ambient badging in Chrome Canary.

If PWAs don't to anything and are considered PWAs, then depending on whether the PWA is installed or not, one of two mini panes will be shown

1) Add (install the PWA, if not installed) to Home screen 2) Open (the installed PWA instead of the site)

[MatteoWebDeveloper]

@kenchris they should allow to block this small banner. On instagram the prevent prompt does not work and now there are two banner :(

[kenchris]

As far as I understand, they can. if you intercept the beforepromptevent and block it, the ambient badge shouldn't show up. At least I understood from Twitter that that is how it works, but I haven't tested it myself

[MatteoWebDeveloper]

@kenchris because is canary is possible is a bug... I hope.

[dominickng]

@MatteoWebDesigner @kenchris we're still working on the details, but right now the ambient badge is deliberately decoupled from beforeinstallprompt, so it will always show up regardless of whether you capture the event or not. It will become more subtle in the future, but we're quite constrained UX-wise in Chrome for Android right now.

The intention is that sites like Instagram shouldn't need to show their own add to home screen UI, they should just use our beforeinstallprompt-driven flow, which now shows a modal.

The ambient badge is a lot more more intrusive than we'd like at the moment, but without it, we can't launch the new modal app install banner, which is more predictable for devs. It's a compromise we're pushing so that developers can stop working around the limitations of the existing banners. And hopefully soon it will become much less intrusive. UI is difficult...

[kenchris]

Maybe @adityapunjani knows and can test as he works on the Instagram PWA

[kenchris]

@dominickng do you have a screenshot of how the new modal looks? Using that will still show the ambient badge?

[kenchris]

Or do you just mean this modal that shows up when clicking on the ambient badge?

[photopea]

Guys, it is nice that you let authors prevent the "Install Modal" by listening to some event, but I think there may be some authors not even aware that some browsers show such modal for their web.

Again, not interrupting the visitor should be a default behaviour. Any such dialog should be initiated explicitly by the website at the moment, when the website finds it appropriate (e.g. when the visitor clicks some button).

[slightlyoff]

I don't understand why this thread continues to debate browser UI. The only thing a web standard can (or should) do with regards to privileged browser UI is to ensure that the full range of requested UI styles are possible. Beyond that, we aren't likely to ever come to full agreement and that's OK.

[MatteoWebDeveloper]

@slightlyoff that's true I rised a bug so the conversation can carry on over there. https://bugs.chromium.org/p/chromium/issues/detail?id=834017. If we exclude the ambient badge discussion I think people were coming to an agreement with the need of window.install() with restrictions.

[slightlyoff]

We will continue to restrict the situations in which any install method can be called. That's why onbeforeinstallprompt was invented. Replacing it with an inferior API will only cause churn and won't change the triggering behavior.

On Tue, Apr 17, 2018 at 1:31 PM, Matteo notifications@github.com wrote:

@slightlyoff https://github.com/slightlyoff that's true I rised a bug so the conversation can carry on over there. https://bugs.chromium.org/p/ chromium/issues/detail?id=834017. If we exclude the ambient badge discussion I think people were coming to an agreement with the need of window.install() with restrictions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/manifest/issues/627#issuecomment-382131946, or mute the thread https://github.com/notifications/unsubscribe-auth/AAF8M3hxq2HWV4WU3MElD52zGQm0alEQks5tplE0gaJpZM4QbdZ9 .

[ghost]

I propose a standard solution to the problem which solves all use cases and avoid spam. There should be six conditions and if any one of them are met, an app should be able to trigger install prompt.

1. 30s limit should be imposed when there is no interaction with the app.

2. If a user has clicked/touch the app once on a given page. If the user dismisses the prompt one more chance should be given to the site on next tap to ask. And even if that prompt, the permission should be snoozed for 24 hours.

3. If a user has already added website to bookmarks.

4. User has opened the app page directly.

5. The user arrived to the app's website from another installed app (native or web app). We could be advertising our app from Email or another app's ad.

6. The last condition is a bit tricky. A website should be able to allow its engagement to be transferred to another app when a user clicks on a link. For example if I am advertising on Adwords for users to install my app, Google/Website should be able to transfer its engagement to my website to provide an expected experience.

In addition to this, the app must not be installed on the homepage already.

In our case, like an android or ios app, we need to be able to let the user install our app from the landing page. If we have a native app we can directly take them there. The web should have equal requirements or similar requirements.

[photopea]

How are app makers supposed to explain to the users "well ... wait 30 seconds ... now add our website to bookmarks ... almost there ... now touch twice ... few more steps ..." And the worst part is - the webpage is not being abusive, but your browser does it for your "safety" and "comfort".

There are apps on stores/markets, which can be installed and used immediatelly. Why do you enjoy "handicapping" webapps (in contrast with native apps) so much?

As I said before, the install prompt should be initiated only by the webpage and the user, just like the Fullscreen API and the Pointer Lock API.

[ghost]

You are right. This only makes web apps inferior to native apps. Any extra click required reduces install rate. I have edited after thinking that. If the same thing is possible for native app, it should be possible for web app. If we are pushing the web to compete with native, adding arbitrary requirements should not be encouraged.

I suspect that initially for a few months there will be spam. After PWA's becomes the norm, things will settle down.

[dominickng]

We're keenly aware of the difference between web and native here, and are working to reduce those differences. However, we also want to ensure that the significant structural and security advantages of the web over native apps is not lost. Add to home screen should be an incremental improvement over the existing functionality of a web site. You should be able to use and derive value from the web without having to install - that's a huge advantage over native in a world where billions are users are data-constrained and are adverse to having to download a large artefact. Add to home screen is an added bonus, not a necessary requirement.

The right to add to home screen is significantly more powerful than either fullscreen or pointer lock, since it actually leaves a permanent artefact on the user's device that can be persistently re-enter an app-like context.

[anirbansaha77]

I suspect that initially for a few months there will be spam. After PWA's becomes the norm, things will settle down.

I don't think there would be spam.. i want to delay the add to home screen only after i am sure that the customers have a good and a meaningful interaction with my site i.e, complete a purchase or added some items to wishlist...prompting them too early will definitely get lots of rejections... that's why i feel that its better if the control is with the developers.... and not the user-agent...