Re: [w3c/manifest] Add installation prompt control flow (#417)

Hi Marcos,

I spoke with Owen and Alex on Friday and we have come to an agreement that we can continue with the beforeinstallprompt API mostly as it is now (in #520), but with a few wording changes to the spec to allow UAs more freedom to experiment and change their UI.

Let me summarize what we've been talking about: we have some concern that our UI is not working; feedback from developers indicates that they want to be able to show the prompt more easily and reliably. A particular concern was that once users cancel the banner, they aren't able to have a button that shows the banner again (they have to wait for another BIP event). Maybe we want to, say, give 3 denies before we give the domain a long time penalty before prompting is allowed again. The current BIP doesn't naturally allow reprompting immediately after a deny.

We have to balance this with spammy behaviour, of course, but we want to keep the UI options open. For the reprompting case, we have 3 options:

1. Make `BIPE.prompt()` callable multiple times (if the UA allows reprompting).
2. Fire another BIPE immediately after a failed call to `prompt()` (if the UA wants to allow another prompt).
3. Change the API entirely.

Since we previously decided we wanted to work within the existing BIP framework, we decided that #2 is an OK option. #1 seemed wrong because it distorts the BIPE object into this long-lived object that you can use many times.

But if we fire a BIP after a failed `prompt()`, isn't that misleading because it isn't actually before an install prompt... the UA has no intention of showing an install prompt even if `preventDefault` isn't called! So that's another thing we talked about: we want to *not* mandate that the UA show an install prompt after a non-cancelled BIP. Because we want the freedom to be able to give the site the ability to show a prompt without necessarily showing the prompt automatically if the BIP is not cancelled. And besides, Alex is adamant, specs shouldn't mandate UI.

So in summary:

* The spec should not mandate that the UA displays a prompt if the BIPE is not cancelled (should be up to the UA).
  * This may require changing the language around "presents an install prompt" to say non-normatively that the UA may show some UI asking the user.
  * Even when `prompt()` is called, we should not mandate UI. It should non-normatively suggest that that’s what probably should happen.
* Because a BIPE may or may not indicate that an install prompt is about to happen if you don't cancel it, we could consider adding some attributes that indicate whether or not a prompt would be shown in fallthrough. *But* we don't need to do this; we could also just say that if you don't want a prompt, call `preventDefault`, if you do want a prompt, call `prompt()`. If you do nothing, you get unspecified default behaviour. I am personally in favour of not adding an attribute here.
* Allow multiple BIPEs to be thrown in a single page load -- for example if the user says No, the UA is allowed to fire the event again (either immediately or after some time passes).

Thoughts on this?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/417#issuecomment-262165091