-
Notifications
You must be signed in to change notification settings - Fork 14
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
Developer information? #40
Comments
Do you have pointers to Rakuten's documentation for this feature? I failed to find it. |
@tomayac unfortunately it's not public yet. I copy-pasted the part relevant to the |
Most of this is on the roadmap for the Manifest App Info spec (which is focused on catalog info). I'm going to move it over there and connect it to the various issues we've already got in the hopper. |
Questions:
|
@aarongustafson Thanks for moving the issue. I didn't know there was a proposal already for supplemental app information. I just read the draft and liked what I saw a lot. Thanks for writing it. Regarding your questions, and the factors that guided our current implementation above: Current popular distribution channels for apps (Apple App Store, Google Play Store, etc) don't have a distinction between developer*, publisher or seller, and the terms there often seem interchangeable. Support/privacy/TOS links are also directly relevant to the app itself, not much so to the larger entity who published it. Only the "developer website" links to the organization. Functionally, I think this maps well to the Service and Organization schemas I linked to in my original message, but we wanted to avoid the complexity of those schema by keeping only a subset of the most common information. The discussions around these schemas in https://github.com/schemaorg/schemaorg are very interesting to read. Our implementation also packages this information into an object field, rather than spreading the fields at the top level of the manifest. This was both to avoid collisions with other extensions of the web manifest, and to make the data better structured. But maybe a single object isn't the best option after all. * The developer information, when talking about the people who actually wrote the code, is usually not exposed by the various app stores. On the web, agencies use |
Considering this (and the related items), I’d propose we consider the following structure: {
"name": "App Name",
"publisher": {
"name": "Company X",
"url": "https://domain.tld"
},
"policies": {
"usage": "/terms",
"privacy": "https://domain.tld/privacy",
"accessibility": "/accessibility",
"support": "/support",
"security": "/security",
"license": "/#license"
}
}
Would love to hear thoughts from @jgw96 here as to what they are seeing folks ask for or need in the Microsoft Store. @tomayac and @torgo Do y’all have any insights into whether this might be of interest in the Play and Samsung stores? |
|
Just a comment on the URL format: Our platform enforces absolute URLs for simplicity, because we actually open these links in the default browser and not in our super app. Relative links are of course great, but I think it should be explicitly mentioned that absolute URLs are supported as well, and that they are not affected by the |
@jcayzac Totally agree. That’s why I showed both within the same policies block. At Microsoft, for instance, we have a single Privacy Policy for all web properties, but other policies may differ by property. It should totally support both. |
@JudahGabriel Does this proposal align with what the Microsoft Store is interested in? Any feedback you have would be much-appreciated. |
Yes, this align with some of our goals for PWA ingestion. Looks great! |
Hi,
Rakuten has started to add support for third-party merchant websites in its mobile payment application, based on PWA. The catalogue of web apps you can "install" and use in our "super app" thus gets all the app's metadata from its web manifest.
When a user launches a 3rd-party app the first time, a dialog is shown to present some information about it: name of the developer with an optional URL, as well as links to the app's privacy policy, terms of use and support site. This information is also available from the web view menu once the web app is opened.
Although a few schemas could be used, for instance Organization or Service, they are quite complex. Moreover, JSON-LD seems out of place in a manifest, and the schemas too obscure for us to expect them be used in merchants' web apps either.
Our current implementation thus takes inspiration from Kai OS webapp manifest, which feels more "idiomatic":
Although our user agent is a super app, we think this metadata would also have value in a web manifest for web browsers. Without this, discovering the information relies on parsing the HTML DOM and looking for many complex schemas with a lot of fragmentation, with no easily predicable behavior.
The text was updated successfully, but these errors were encountered: