(brand new ✨) Web Install API

[diekus]

Hola (again) TAG!

I'm requesting a TAG review of the Web Install API.

The Web Install API provides a way to democratise and decentralise web application acquisition, by enabling "do-it-yourself" developers to have control over the application discovery and distribution process, providing them with the tools they need to allow a web site to install a web app. This means end users have the option to more easily discover new applications and experiences that they can acquire with reduced friction.

• Explainer¹: https://aka.ms/webinstall
• Specification: N/A
• WPT Tests:
• User research:
• Security and Privacy self-review²: here
• GitHub repo: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/
• Primary contacts:
  • Diego Gonzalez(@diekus), Microsoft, Program Manager for Web Install API
• Organization/project driving the specification:
  • @MicrosoftEdge
• Multi-stakeholder support³:
  • Chromium comments:
  • Mozilla comments: Web Install capability mozilla/standards-positions#1179
  • WebKit comments: Web Install API WebKit/standards-positions#463
  • Developers:
    • Principle: The Web should not owned by anyone ethical-web-principles#120 (comment)
    • Principle: The Web should not owned by anyone ethical-web-principles#120 (comment)
• Status/issue trackers for implementations⁴:
  • https://chromestatus.com/feature/5183481574850560

Further details:

• [ x ] I have reviewed the TAG's Web Platform Design Principles
• Previous early design review, if any: Web Install API - Cross-Origin #946/Web Install API - Same Origin #888
• Relevant time constraints or deadlines:
• The group where the work on this specification is currently being done: W3C Web Applications WG
• The group where standardization of this work is intended to be done (if different from the current group):
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: @MicrosoftEdge

You should also know that...

This is an updated design based on previous reviews and feedback from multiple parties, including TAG. The design has been streamlined to be consistent across all calls.

[zcorpan]

A comment on the self-review:

How does your feature handle non-"fully active" documents?
This feature does not interact with non-"fully active" documents.

This should be considered when writing the spec. It's possible to have a reference to the navigator object of a non-"fully active" document, and call install() on it. It should probably do something like https://html.spec.whatwg.org/#dom-navigation-navigate step 3 and 7

[jyasskin]

Hi! First, thank you for adjusting the proposal in response to some of our previous feedback, in particular removing install_sources and postponing navigator.getInstalledApps(). I don't see adjustments or explanations in response to some of the other comments:

• The "Declarative install" alternative, which mentions <a target> doesn't mention our suggestion to consider rel.
• The TAG felt like it was probably better for users if they can interact with the to-be-installed site before being asked if they want to install it. The Declarative Install alternative says that "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-us/articles/19335302900887-Peek-Preview-Sites-From-Pinned-Tabs might also offer a way to get the best of both options.

We don't expect to review this again in detail before our comments from last time are more fully addressed.

[diekus]

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!