PWA initiators

From MgmtWiki
Jump to: navigation, search

Full Title or Meme

This is an extension to the wiki page Progressive Web App to track evolving changes to the ways that PWA are initiated.

Context

  • The goal of the PWA is to eliminate the need for native apps. While it is likely that some functions, like access to the keystone, will not be available for PWA, many other features a being added.
  • This page is specifically interested in tracking the ways tat a PWA service worker can be initiated from the browser (which includes some other PWA.)

Taxonomy

Terms from Web Application Manifest

Solutions

PWAs as URL Handlers

  • Explainer - Even tho one of the goals is to keep the user in control of their own experience, this does not explain how tis would look to the user nor why this is good for user, but only for Microsoft and content owners. Wile it does put more choices in app pickers, the goal of giving user more clicks to get to the content seems artificial.
  • This is designed to give more control to the PWA for registering URLs tat can be accessed from native apps running on the phone.
  • In particular the PWA can register for URLs that are not it its own scope. (That seems dangerous.) The new feature is that this is handled in the browser and not in the o/s presumably so that all platforms will work the same way.
  • But they want to have their cake and eat it too, so the o/s will field such a link. The issue seems to be Android using WebAPK . Because WebAPK s are recognized by the Android OS, Chrome PWAs are able to fully integrate with OS features like the app picker.)

Declarative Link Capturing (DLC)

This is an attempt to get software launch to work, even tho that proposal has been around for several years without getting implementations it seems to have come back to life.

  • Explainer seems to be mostly about when to create a new browser tab when a link in the existing PWA is clicked.
  • Combined with the above this would work from native apps as well.
  • Would also work from file handler as well.
  • It appears that the "launcher" only knows how to create new tabs and this would fix that.
  • This was (re) introduced in 2019 and has not had much activity.
  • message from Alan Cutter <alancutter@chromium.org> 2021-03-21 FYI this experiment has been pushed one milestone from M90 to M91. On 2021-03-03 Canary included M91. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d5bf3061-153a-4f7b-8792-1e4d86f47309n%40chromium.org.

PWA Installation UX

The PWA install experience on Android is planned to be improved.

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. 

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 

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

Enterprise PWA

  • Managed Configuration API for Enterprise Web Applications. Provide an API which will be able to asynchronously obtain/monitor configuration provided by the enterprise admin. This configuration is set up in the Admin Panel by uploading a JSON file, which contains key-value configuration.

Crypto API

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=PWA_initiators&oldid=14765"