Add screenshots object

[RobDolinMS]

Many catalogs / stores of apps include one or more screenshots of an app.

While image dimensions and aspect ratios may vary, it would be useful for the spec to define a place to look for screenshots (similar to the icons object)

This could be an optional member of the manifest, but including a standard place to look for screenshots would be useful in building catalogs of web apps such as https://pwa.rocks/

[RobDolinMS]

Anyone have any other comments on this? I can open a PR if there are no big concerns or things I'm missing.

[marcoscaceres]

The challenge I see with screenshots is that the fetching behavior for user agents will be different from that of sites (servers) like pwa.rocks.

I'm also concerned that each store will have its own requirement for screenshots - e.g., some will want desktop, others will want mobile, or tablet, etc. Some may require squares, other particular dimensions and so on (and developers will likely want to crop or adjust display of those screenshots on various sites).

Additionally, it's not uncommon for screenshots to be customized for the particular store they are targeting. Compare Steam and Apple's App Store: where games listed on each show different screenshots with, what I can only assume, is either an attempt to appeal to an audience or an attempt to meet store guidelines. Furthermore, some stores support videos and others only images.

[patrickkettner]

do any of your comments not also apply to icons, @marcoscaceres?

The intricacies of how, when, what, and why they are fetched are different on a per client basis.

[marcoscaceres]

do any of your comments not also apply to icons, @marcoscaceres?

Yes. We define specifically how to fetch images from a browser (so the fetching can correctly work together with service workers and CSP).

The intricacies of how, when, what, and why they are fetched are different on a per client basis.

Correct. Which may lead to weirdness for non-web clients.

[patrickkettner]

I feel like I wasn't clear. I was reacting to the following statements

some will want desktop, others will want mobile, or tablet, etc. Some may require squares, other particular dimensions and so on (and developers will likely want to crop or adjust display of those screenshots on various sites).

Additionally, it's not uncommon for screenshots to be customized for the particular store they are targeting.

This (albeit loosely) reflects the current state of icons as well. an iOS icon != android icon. Also true for related_applications as well.

My point is that I don't see how platform differences in stores should prevent developers from being able to optionally include screenshots in a standard way.

There will always be specificities that the spec doesn't/shouldn't cover. But if a store ingests a site with a manifest as a store app, they would undoubtedly allow for a person to "claim" that app in the store to modify the metadata further (adding videos, release notes, etc).

[marcoscaceres]

This (albeit loosely) reflects the current state of icons as well. an iOS icon != android icon. Also true for related_applications as well.

Yes, please see #361. We are working on solving that too.

My point is that I don't see how platform differences in stores should prevent developers from being able to optionally include screenshots in a standard way.

I don't disagree. But I'm concerned about adding this and then no stores using it (because they might have specific requirements - and also because of manifest data synchronization/data-authority problems - which I discuss below).

With icons it's different: it's the browser, as a conforming user agent, in control of the life cycle and placement of the icon on the homescreen. We don't have any conformance requirements related to stores.

There will always be specificities that the spec doesn't/shouldn't cover. But if a store ingests a site with a manifest as a store app, they would undoubtedly allow for a person to "claim" that app in the store to modify the metadata further (adding videos, release notes, etc).

Again, I don't disagree. I guess I'm looking for commitment that screenshots will be used before adding anything. That's how we've added the other features of the spec: we've always had at least one implementer say "yes, we are totally supporting/implementing this".

I'm also hesitant because I saw how badly it went with the Firefox Store: manifest data was ingested, then developers made modifications during the store's app submission process (e.g., fixed typos), and then they updated their manifest elsewhere, and now everything falls out of sync (store's data doesn't match manifest data... it leads to much sadness).

This is why I think stores should manage their own data - because keeping store + manifest data in sync is really hard.

[patrickkettner]

But I'm concerned about adding this and then no stores using it

Ah, that makes more sense. However I am not sure I agree with the concern. I am quite certain that my team would be interested in using it.

We don't have any conformance requirements related to stores

We (spec folks) don't have any requirements of the browsers, either. They can be determined, and cataloged, but that is no guarantee that it won't change the moment we go to CR. Much in the same way, we can easily get the requirements for the major app stores (happy to do so myself if desired), and normalize them.

I guess I'm looking for commitment that screenshots will be used before adding anything.

I know that Edge is extremely interested in using them.

I'm also hesitant because I saw how badly it went with the Firefox Store: manifest data was ingested, then developers made modifications during the store's app submission process (e.g., fixed typos), and then they updated their manifest elsewhere, and now everything falls out of sync (store's data doesn't match manifest data... it leads to much sadness).

I am not clear on what the issue is - that user has manifest data. Stores A and B ingest it, user updates the data on Store A, and as a result Store B is out of date?

I think we may be viewing this from two different viewpoints. I believe this would work great a way to seed store data, not necessarily mirror all of the store content across platforms. If a user wants to customize the data after the fact, I don't see the harm in it.

[marcoscaceres]

Ah, that makes more sense. However I am not sure I agree with the concern. I am quite certain that my team would be interested in using it.

Ok. That's sweet music to the spec editor's ears 🎸.

We (spec folks) don't have any requirements of the browsers, either.

Nit pick: but the RCF2119 keywords are conformance requires precisely for browsers.

I know that Edge is extremely interested in using them.

Ok, cool. That's what I needed to hear.

I am not clear on what the issue is - that user has manifest data. Stores A and B ingest it, user updates the data on Store A, and as a result Store B is out of date?

No, that user updates the data in the manifest, but Store A and B don't update. So, user updates data in Store A and B, but then stops updating the manifest.