First pass on install-related Client Hints

[dmurph]

I think a good road forward is for us to gather partners with explicit use cases (or even internal customers with explicit use cases) where these client hints are required. I know of one major one currently:

• server-side rendering is blocked for webapps where the display mode influences the content - e.g. a fullscreen view is different than a standalone, different than minimal-ui, different than tabbed (browser), etc. An easy example is minimal-ui vs standalone, and the need to present navigation controls if in standalone

and one minor use case that could greatly increase adoption:

• established properties use server-side logging frameworks for metrics and experiments, and it is really difficult to pipe back data from javascript on the client to join with the server side logs to know 'is this user viewing the site as a webapp?'. Providing this information as a client hints unblocks these sites from putting major resources towards webapps because they can now run experiments to determine things like "relation between user satisfaction / retention and web app usage (/ display mode)."

I think both of these are solved by having the 'display mode' client hint.

I think I generally agree with @marcoscaceres that we don't want to encourage the case for the install prompt, and if we are getting that feedback I really want to dig in and know why that partner wants the webapp to be installed. I think the one use case you are citing

[aarongustafson]

I think a good road forward is for us to gather partners with explicit use cases (or even internal customers with explicit use cases) where these client hints are required.

Agreed.

• server-side rendering is blocked for webapps where the display mode influences the content - e.g. a fullscreen view is different than a standalone, different than minimal-ui, different than tabbed (browser), etc. An easy example is minimal-ui vs standalone, and the need to present navigation controls if in standalone

Yes. This is an excellent case for the display mode hint, which I will work on shortly, over in the Manifest spec. Setting aside the topics of this PR for a moment, how are y’all feeling about the organization of the Client Hints section? Do you feel it could be replicated in the manifest for display mode?

and one minor use case that could greatly increase adoption:

• established properties use server-side logging frameworks for metrics and experiments, and it is really difficult to pipe back data from javascript on the client to join with the server side logs to know 'is this user viewing the site as a webapp?'. Providing this information as a client hints unblocks these sites from putting major resources towards webapps because they can now run experiments to determine things like "relation between user satisfaction / retention and web app usage (/ display mode)."

100% agree on this. Having access to this info without JavaScript would be huge for analytics on static sites as well.

I think both of these are solved by having the 'display mode' client hint.

I am not on board with equating display mode with installation unless we decide to specifically make that part of the implementation requirements in the spec for the display mode Client Hint. The current equivalent approach using matchMedia() suffers from false positives (see my comment above), so I don’t want to replicate that issue, nor do I want to create a situation where devs make assumptions about a web app’s installation status based on some other factor; I’d rather just explicitly tell them they’re installed.

I think I generally agree with @marcoscaceres that we don't want to encourage the case for the install prompt, and if we are getting that feedback I really want to dig in and know why that partner wants the webapp to be installed.

To be clear, I’m not suggesting web apps be able to prompt for their own installation (or that they shouldn’t), I was merely bringing up that some content may vary based on whether the app is installed (or not). An advertisement to install the app was an example of that.

With that in mind, my third use case would be:

Web apps are currently forced to deliver the same content and scripts to all users and cannot vary those based on whether the app is installed. For example, they may choose not to include the content and images advertising the availability of their app in an app catalog if they know it is already installed on this device.

[aarongustafson]

@marcoscaceres @dmurph @yoavweiss I made some tweaks to move the installation source to using Referer (which is, incidentally, what Google Play TWAs do now, as I understand it—and, FWIW, was my initial choice for this info). I also tweaked some of the language around the "installed" hint (which I have heard is something devs would like to have). Since CHs require a JS equivalent, what do folks think about proposing navigator.installed (or navigator.isInstalled) as a boolean?

[marcoscaceres]

Since CHs require a JS equivalent, what do folks think about proposing navigator.installed (or navigator.isInstalled) as a boolean?

I'd be personally opposed to that for the reasons I gave. However, if others are supportive, I'd go with the majority.

@annevk maybe you can give a Gecko perspective here? Not sure who to ping to get a Mozilla position on things like this.

[annevk]

We're not convinced Client Hints is worthwhile and are concerned about its implications on the same-origin policy.

[dmurph]

I'm also not convinced about using the installed status.

Differential serving of layout is useful, especially because we have two parters that have explicitly said as much, as well as the feature request that this: https://github.com/w3c/manifest/issues/954. So having the display mode CH makes sense here.

Regarding install status - I don't really see this getting used for quota or run on login in the real world, and I definitely think this would be used for fingerprinting and data collection about the client. I am skeptical if this is even the correct answer for a 'quota' question. I see the cons really outweighing the pros mentioned here. I also don't like how this allows a website to change behavior based on install status. With display mode, all display modes are 'accessible' in an installed app (open-in-tab, fullscreen, or standalone/minimal), so an web app is still incentivized to support them.

I see installation as being something that is more user-focused - the user agent is providing higher-os-level interaction and new features to the user to interact with this web app. They aren't required to install, and they should be able to still use the web app without installing.

[aarongustafson]

@marcoscaceres @dmurph While hardly scientific, I found this interesting: https://twitter.com/AaronGustafson/status/1385701549905571840

TLDR; More than 1/3 of developers want to be able to know if their PWA is installed, narrowly beating out a ~30% interest in dark mode colors & icons. Multilingual support was a close third, and knowing the installation source was in last place with ~13% of the vote (sample size: 131 on Twitter)

Trying to get more details on reasons folks want to know about installation. May also run a Kano study on some of this stuff to get a better sense of what developers need from the Manifest, etc.

[dmurph]

Cool! I would love to know why they want that signal. Maybe you can create a new thread on why devs want that?

[marcoscaceres]

would love to know why they want that signal. Maybe you can create a new thread on why devs want that?

I'd be keen to dig into that too. If we can look at concrete examples or real apps, that would be great, as we can then figure out what people are trying to do and derive a solution from there.

[aarongustafson]

Adding @diekus to this thread since install is something he’s working on as well.