Intent to Implement and Ship: Rich PWA installation dialogs
Finnur Thorarinsson
Intent to Implement and Ship: Rich PWA installation dialogs
Contact emails
fin...@chromium.org, pe...@chromium.org, fbea...@chromium.org
Spec
https://w3c.github.io/manifest-app-info/#supplementary-manifest-members
Following this intent, we would like to start using the “description” and “screenshots” members of the Web App Manifest Application Information draft to provide a richer, more informative installation experience for users.
Because the effect of this will be visible to users, rather than developers, it’s important to note that the feature will be rolled out as a Finch experiment to validate that it has the ability to add value.
Explainer
https://w3c.github.io/manifest-app-info/
https://github.com/w3c/manifest-app-info/blob/main/explainer.md
https://web.dev/add-manifest/#screenshots
TAG review
These properties were included during the original Manifest TAG review:
https://github.com/w3ctag/design-reviews/issues/30
Summary
Most browsers have facilities to enable users to add a website to their homescreen.
Several browsers provide the ability to install PWAs. Currently the context that’s available to convey is the website’s origin, as well as the name and icons made available through the Web App Manifest. This is different from other store mechanisms, on all platforms, that also share developer-provided information such as a description and screenshots.
Microsoft’s Aaron Gustafson (cc’d) has proposed a Web App Manifest Application Information draft, through which we can obtain that information.
Following this intent, Chrome for Android will start experimenting with a new, richer user interface that displays this information when the developer has provided it. We’ve carefully designed this interface to continue to highlight known information such as the origin, and are working with the permission and privacy teams to make sure we can evolve it responsibly going forward.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No. The manifest members are platform agnostic, but this implementation applies to Android only for now (Desktop work is planned).
Demo link
Enable the “Mobile PWA Installation bottom sheet” flag on chrome://flags
Visit https://squoosh.app
Press the Install button and observe the new bottom sheet.
Risks
Interoperability and Compatibility
This is a new feature that requires developers to provide new fields in their manifest. There is no change in behaviour for websites that don’t, and we continue to enable installation for such websites as well.
There are various on-going discussions about what it means to install a PWA, particularly in regards to it being a security boundary. This particular intent has no impact on that decision, but composition of information in installation prompts may be revisited in the future.
Edge: Positive (they proposed the specification)
Firefox: No signal (issue).
Safari: Descriptions are implemented (thread, code), but not exposed in UI. No signals for screenshots (bug).
Web / Framework developers: Positive (tweet with 38 Retweets and 135 Likes, 42 stars on the implementation bug).
Ergonomics
There is no change in behaviour for developers who do not adopt this feature. For those who do, there will be a slight delay in showing the install dialog while the screenshots are downloaded.
Activation
Description and screenshots are optional fields and there is no need to polyfill because PWA installations will continue to work as they do today if these fields are not supplied. Developers who do not adopt this feature will therefore see no change, but we will reach them through the usual social media channels, as well as through targeted partner outreach.
Debuggability
DevTools debugging support is currently available to help web developers diagnose installability issues with screenshots. Those are available in the Manifest pane of the Application panel.
Tracking bug
Launch bug
https://crbug.com/1169951
Chrome Platform Status
https://chromestatus.com/feature/6422599217184768
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Not yet, there is an open issue for this: https://github.com/w3c/manifest-app-info/issues/26
It’s worth noting that WPT in this instance may be able to validate existence and reflection of the properties, but will not be able to cover how a user agent uses the information. This has been added to Chromium as Android JUnit tests, but will continue to be platform specific.
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB2L5-Y44vqep-0-tMqjbCcCrX7jn1jqe23KxSk4NhSBvmU9tQ%40mail.gmail.com.
Finnur Thorarinsson
Hi Chris,
Thanks for the questions. I also apologize for my late reply -- it took a bit of time to gather and process the information requested and a couple of sick days didn’t help either.
1) Do you have information about how many existing PWAs might have this information exposed?
We inspected the manifests of the most popular PWAs installed on Android, which together represent more than half of installs seen this year. Only about a third included the ‘description’ field but none of them included the ‘screenshots’ field. Since both fields are required for this feature, we could not find any PWA within that set that would trigger the showing of the new richer install UI.
It’s worth adding that, despite being previously unused, all the ‘description’ fields we encountered had sensible values, so it looks like this was very much anticipated by developers.
2) Consider the case of a PWA that fills out these fields, but since they aren't being used or exposed prominently, they would be surprised by this change.
There is little incentive for developers to have provided this data if they did not anticipate that it would get used, as we have never checked for it, let alone validated it. Even if the showing of this information in this particular user interface may come as a surprise, by nature both a site's ‘description’ and ‘screenshots’ are clearly intended to represent their property.
Furthermore, it is hard to determine whether people will be surprised by this change or delighted, because developer enthusiasm has already led to sites starting to fill this out in anticipation of launch. For example, see Discourse comment on the feature bug https://bugs.chromium.org/p/chromium/issues/detail?id=1146450#c49
3) What does it mean for Safari to parse but not use the fields?
It means they’ve implemented the code to parse the manifest (including the ‘description’ field) but they are currently not exposing the data in their UI. We don’t know what their intentions are for using the information as they’ve not responded on this topic (to my knowledge).
4) Is there something web-exposed about this behavior that can be detected?
No.
Best regards,
Finnur
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB2L5-YFuVHkoz1tNFa%3Dm-qE%3D%3D87%3DPAsS%2BzJnWNUnXLzb78ciA%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_xteO52M1z48OVmyow9hJgbP_9TOa%2Bn6vH55sdTFm5yQ%40mail.gmail.com.
Daniel Bratell
LGTM3
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWeFAur6rQ8%2BGJsL9BO%3D-cW5xxtE%3DkvRb2-8D9QNsUU6g%40mail.gmail.com.