Expands on the declarative alternative solution for Web Install #975
Conversation
diekus
commented
Feb 27, 2025
diekus
commented
- expands on declarative alternative and the reasons why we think starting with an imperative API works best.
- adds details about the try-before-you-buy scenario as UA defined UX.
* expands on declarative alternative and the reasons why we think starting with an imperative API works best. * adds details about the try-before-you-buy scenario as UA defined UX.
diekus
added
the
Web Install API
Co-authored-by: Howard Wolosky <[email protected]>
Co-authored-by: Howard Wolosky <[email protected]>
Co-authored-by: Howard Wolosky <[email protected]>
Co-authored-by: Howard Wolosky <[email protected]>
Co-authored-by: Howard Wolosky <[email protected]>
Co-authored-by: Howard Wolosky <[email protected]>
* Streamlines the declarative alternative explanation
WebInstall/explainer.md
Outdated
| * Supports `install_url`. This url can be an optimized url or the normal homepage that an application already has. The advantage is that unlike a declarative version, there is no scenario where an end user can be left stranded accidentally in a blank page that is meant to be a lightweight entry point to the app. | ||
| * Code can be used to detect if an origin has [permission](#new-installation-permission-for-origin) to install apps, 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). |
There was a problem hiding this comment.
In the TAG review, some of the feedback was this: "'Takes the user out of the current context.' is a downside, but the TAG currently disagrees that that's a downside and would need to be convinced. What data have you collected that shows that it's bad for users to have to visit a website before installing it? A "peek" UI like https://resources.arc.net/hc/en-"
You and I are in agreement that there exist potential dev benefits to allow the current context to be retained, but I don't think you've managed to provide an actual example here to demonstrate that. I just think we need to flush this point out a little further. They ask what data we have for our suggestion. We have at least one web developer (store.app) who's desired model would be to have the install occur without navigating away (in theory to facilitate multiple installations). TAG doesn't present data to the contrary. I don't think we necessarily need data, but flushing out realistic scenarios might help close this part of the conversation down.
Co-authored-by: Howard Wolosky <[email protected]>
Co-authored-by: Howard Wolosky <[email protected]>
Co-authored-by: Howard Wolosky <[email protected]>
* Adds mention of a use case where it makes sense to keep the context for the end user while installing.
