Re: [w3ctag/design-reviews] (brand new ✨) Web Install API (Issue #1051)

diekus left a comment (w3ctag/design-reviews#1051)

Hola @jyasskin ✨

Thanks for your prompt review. I have modified the explainer to address the two points you mention are still pending, and I'd like to expand on them in this issue as well.

First and foremost, I want to express that I firmly believe that both solutions are desired. As stated in the explainer, we believe that a declarative implementation is a simple and effective solution, and should be considered as an additional method of installation in the future.

For the current solution, **we want to go with an imperative implementation since it allows more control over the overall installation UX**:

* Allows the source to detect if an installation occurred with ease. (*resolves/rejects a promise*).
* Supports `install_url`. The current reality of the web is such that some websites intentionally do not expose their manifest nor user experience until the user has authenticated.  We believe that having the ability to offer an `install_url` (one where the only content may simply be a link to the manifest) is a key advantage for both developers and end-users.  The declarative version *does not* cleanly support this concept (as a fallback navigation to an `install_url` that was specified as the `href` on non-supporting UA's might leave the user confusingly stranded on a blank page.
* Code can be used to detect if an origin has permission to install apps (and/or if the UA supports the API at all), and UX can be tailored to change accordingly (for example, remove a button or display a link instead).
* The developer ergonomics of handling a promise are better than responding to an `a` tag navigation.
* Keeps the user in the context, which *can* be beneficial in certain scenarios (if the developer *wants* to take the user out of the current context, they *can* do so with a `a` tag).

Overall it gives developers more control to create really compelling UX experiences for **end users, which are the ones that will benefit from frictionless app acquisition in the end**. 

Regarding the idea of a try-before-you-buy scenario, it's a really good call and great idea! I have added a section in the explainer as well to mention it. I do think that is an implementation detail, up to the UA. Some browsers might want to show a prompt, some a confirmation dialog, some might want to do a rich-install-prompt... and some might even load the app for the users to see before confirming that they want to install it! (like the neat link you sent about Arc's peek). All this is up to the browser and what they consider is the best UX to present to the user before installing an app.

I hope these points address your concerns and we can continue to discuss the Web Install feature!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1051#issuecomment-2688992473
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1051/2688992473@github.com>