Intent to Ship: API to support web/native app install banners
Owen
Intent to Ship: API to support web/native app install banners
Contact emails
benw...@chromium.org, sligh...@chromium.org, owe...@chromium.org, ta...@chromium.org
Spec
https://github.com/slightlyoff/AppInstallImprovements/blob/master/explainer.md#offering-related-applications (see open pull request on the manifest spec: https://github.com/w3c/manifest/pull/344)
Summary of feature
Chrome 42 for Android allows users to easily add high quality sites they visit frequently to their home screen via an add-to-homescreen banner. We would like to provide developers more control over this banner, including its timing and the ability to show a native app in the banner in place of the web app. Note this is primarily a UA-specific UI feature.
The motivation for the banner is two fold:
Many web developers wish they could place an icon for their web app on the users homescreen to drive more re-engagement. Chrome currently has a menu item which allow users to add a site to their homescreen but it isn’t easily discovered.
Many websites currently implement ‘door slam interstitials’ demanding users install their native app. Our implementation only prompts users to install the app if they have already shown engagement on the site and provides much more respectful UX. We hope developers will adopt this, reducing the number of door slam users experience on the web.
Example of a UI that may be provided to a user after visiting the SVGOMG web app multiple times:
Summary of proposed changes
The triggering of the banner is the decision of Chrome and will depend on repeat engagement and a minimal site quality bar in the initial implementation. This intent covers the minimal API we propose that will allow developers to configure the banner:
The related_applications key in the Web Application Manifest for sites to provide a prioritized list of the various versions of their app that exist that the user may want to install.
The beforeinstallprompt event allows developers to detect when the prompt is shown and what the user's response was (via the userChoice promise). This intent also includes the ability for developers to postpone the banner from being displayed by calling e.preventDefault() and later trigger it via window.dispatchEvent(e).
This feature relates to Safari's Smart App Banners, but is distinct as it does not pollute the head of the document with an additional meta-tag, and supports installing apps from many platforms (including web apps) generically. This new API provides the site with more insight into the user interactions with the banner via the beforeinstallprompt event.
Link to the “Intent to Implement” thread
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HSSqpbYd8W8
Ongoing technical constraints
None
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Android: Yes
Windows, Mac, Linux, ChromeOS: Not today, but we plan to support them in the future
Android WebView: No, it’s not obvious how a feature like this would be supported in web view
iOS: No, we are unable to support this due to platform limitations
Compatibility Risk
The new API surface is small and there is consensus in an issue on the Manifest spec between Google and Mozilla that the related_applications approach is good, minimizing risk.
One minor risk is that the set of outcomes returned by the userChoice promise may change/expand. Today it only supports installed and dismissed.
OWP launch tracking bug?
https://code.google.com/p/chromium/issues/detail?id=459839
Link to entry on the feature dashboard
Manifest changes: https://www.chromestatus.com/features/4754986680451072
Event: https://www.chromestatus.com/features/6560913322672128
Yoav Weiss
One minor risk is that the set of outcomes returned by the userChoice promise may change/expand. Today it only supports installed and dismissed.
OWP launch tracking bug?
https://code.google.com/p/chromium/issues/detail?id=459839
Link to entry on the feature dashboard
Manifest changes: https://www.chromestatus.com/features/4754986680451072
Event: https://www.chromestatus.com/features/6560913322672128
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Kenneth Rohde Christiansen
We already adopted the idea in the Web App Manifest spec and Mounir is writing the spec text. We didn't look at the API yet, but feel free to open an issue for the spec and we can discuss it there.
Chris Harrelson
TAMURA, Kent
Software Engineer, Google
