[Ratings and Reviews Prompt] Author-submitted vs. crawled store information

[tomayac]

There is a difference between indie app stores where anyone can submit apps to and that are crawl-based (they crawl regularly and update the local information they have about an app like, for example, automatically created screenshots) vs. submission-based app stores that have the requirement that the submitter be the verified author and submitter of all screenshots. While the former kind of app stores may recreate their local info on a regular basis, the latter may be stuck with the initial version.

Assuming the case that a news app is listed on an app store of the former and the latter kind, the screenshots in the store listings may be different on both stores. A review that, for whatever reason, makes a reference to such screenshots (maybe because they are about unfortunate news on a random day), will need to take this into account.

Example:

1. The indie app store happens to create app screenshots on a day of a tragic event. (The author-verified app store meanwhile happens to have harmless innocent screenshots of happy events.)
2. A reviewer not aware of the auto-generated nature of the screenshots submits a review to the indie app store saying how tasteless it is of the author to choose screenshots of that tragic event to boost installs of their app.
3. Without author intervention the indie app store recreates its screenshots for the app at a later stage.
4. The author is stuck with a negative review.

In the author-verified app store, if this ever happens (like when the author unknowingly chooses offending screenshots), they can update their app listing by submitting a new version of their app, which stores commonly use to hide reviews for earlier versions.

I reckon this is a bit of a contrived example with overlaps to app version history (which you deal with in a different explainer).

[aarongustafson]

Agree that this is an issue. I think this would be best addressed in the Manifest App Info spec by providing guidance to catalogs around a lifecycle for updating their listings based on Manifest updates. In terms of this proposal, perhaps it could provide guidance about enabling developers to flag ratings/reviews for reconsideration by the catalog if they are no longer relevant. Thoughts?

[tomayac]

Agree that this is an issue. I think this would be best addressed in the Manifest App Info spec by providing guidance to catalogs around a lifecycle for updating their listings based on Manifest updates.

This assumes that app catalogs hash the Web App Manifest and all screenshots mentioned therein (since the URLs in the manifest may not necessarily change when the screenshot changes). It might be easier to tie this recommendation to the suggested "version" member. This sets the expectation that when the author changes the version the catalog would update its metadata, including potentially hiding or showing less prominently reviews for outdated versions.

In terms of this proposal, perhaps it could provide guidance about enabling developers to flag ratings/reviews for reconsideration by the catalog if they are no longer relevant. Thoughts?

This sounds out of scope for the proposal. It's more a feature of the app catalog, no?