New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is prefer_related_applications too simplistic? #365
Comments
That doesn't make sense to me... iOS can't run an Android app? Maybe it should just be If a developer really prefers a web app, then they wouldn't build or promote a native app. |
The problem is that the preference between web and non-web is enforced to be the same across operating systems. What if the Android app is preferred over the web app because it provides a better user experience, but the web app has more functionality than a boilerplate Windows Phone app which was only created to have a presence in the Windows Phone Store?
That's a terrible assumption to make, there are plenty of platform-specific apps created which are a poor relative of a fully functional web app that has existed for longer, especially in the long tail. The reality is that small developers can't always afford to maintain functionally equivalent platform-specific apps on all operating systems. I don't think a boolean flag has enough fidelity to represent that situation. It also depends a lot on how this feature is implemented on each user agent and how much choice is given to the user vs. made for them. |
@slightlyoff might have input for this |
I think we will have to wait and see. I'm tempted to mark this as experimental in the spec pending Google feedback. |
@mounirlamouri, this was a question for you (or Google folks). Can you please take a look, comment, and close? |
I'm not sure how we can help. This was designed by Chrome people so we will unlikely tell you it is too simplistic. It seems that some websites use it, for example, Twitter: https://twitter.com/manifest.json Is there anything more specific? |
I consider this a limitation in the spec. If a site prefers its Android app but not its Windows Store app there's no way for it to express it. This can be improved upon by adding an optional boolean field to the ExternalApplicationResource dict which if unset falls back to the value of |
This seems like a fair concern to me. Although I agree with @marcoscaceres that this is addressable by (to use your example) excluding the Windows version from |
In Chrome we plan on not promoting PWA installation (but not blocking it) when the user already has a related app installed. This is to avoid guiding the user towards having two instances of an app installed using different app technologies, a technical detail we don't want to force users to think about. |
On a slightly related note: There is an Origin Trial (what is an Origin Trial?) for an API called |
Isn't the current boolean design of prefer_related_applications maybe a bit too simplistic?
I don't agree that a list of advertisements for non-web software applications and the stores from which they can be downloaded should be part of a web standard, but if it is then I'm not sure a boolean flag provides enough fidelity for a developer to express their preference for which app the user uses.
What if a Google Play Store app is preferred over the web app, but the web app is preferred over the Apple App Store app? Or what if the Google Play Store app is preferred over the Amazon Appstore app? If there are multiple apps which are compatible with the device, how does the user agent choose which one to offer based on just a boolean flag?
What happened to the idea of the developer putting the list of related_applications in their order of preference? If we're going to let developers make a choice on behalf of users, we may as well make it possible for them to fully express that choice.
The text was updated successfully, but these errors were encountered: