Do a snap’s screenshots have, and if not should they have:
A maximum number? (We just tested uploading 18 screenshots, with no error. I’d suggest a maximum of 4 or 5, not counting banner graphics.)
Minimum dimensions? (The upload form seems to accept a 10 px × 10 px “screenshot”, which would be obviously a mistake.)
Maximum dimensions? (The upload form seems to accept a 10000 px × 6000 px “screenshot”. Any sufficiently large image is effectively a DoS for end users.)
A maximum file size?
Any restrictions on aspect ratio? (A “screenshot” that’s 3840 px × 100px might be within allowed dimensions, but it would look like a malfunction to store users.)
Any restrictions on animation? (That is, what happens if you try to upload an APNG?)
Separately, should it be possible to upload videos? Other stores allow this. If so, they should also be limited in number (I’d suggest 1), dimensions, duration, and file size.
These questions are important because they influence the UI for uploading and ordering. For example, the easiest UI for organizing screenshots is quite different if the maximum number is 4 than if it’s 30.
Appstream supports any number of screenshots in any size, though it doesn’t explicitly support videos. I’ve pinged the authors to see if it would need a new <video> tag or supplying a .avi (exactly what codecs are supported would need to be defined) for a screenshot would be sufficient here. Either way video support could be added to GNOME software but it doesn’t have it today.
I think the proposal on the screenshot image parameters makes sense, we can look at what’d be needed to implement this and come back with any needed changes to the idea.
Storing/handling videos is out of scope for the snap store. We can discuss adding external video URLs as snap metadata but should do so on a new thread.
Continuing the conversation here. Let me know your thoughts:
Video
We will not host video media but will allow publishers to include links to media video from popular platforms in their snaps. Some platforms we discussed to introduce: asciinema.org (specifically for terminal-based snaps), youtube.com, vimeo.com (already allowed in dashboard).
Images
Right now we are only allowing users to upload image media related to Snaps but in the future, there will be public publisher pages which will allow users the ability to include their branding and perhaps some featured banner to be used in these pages.
There are 2 additional work streams that will help publishers to contribute with acceptable and great media types to the platform: be able to preview a Snap listing page and guidelines and rules for media types (i.e. safe zones for featured banners, guidance on what to showcase in screen shots, avoiding text as much as possible in screen shots…). These will be worked out once we have an agreed direction.
General details
Accepted media formats: PNG, Animated GIFs, JPG, JPEG
Maximum overall file size : 2 Mb
Media images related to Snaps
General
Number
Required
Allowed aspect ratio
Min size
Max size
Recommended size
Max. file size
{snap-name}-icon
1
1:1
40x40
512x512
256x256
256 kb
{snap-name}-featured
1
2:1
640x320
3840x1920
1920x960
2 Mb
{snap-name}-shot-#
Up to 4
1:1, 4:3, 16:9
480x480
3840x2160
1920x1080
2 Mb
Description of items from the table above:
Snap icon: This image will be shown in search results, store pages and its details page.
Snap featured: Storefronts might decide to promote a given snap and this media type will allow them to feature a Snap
Snap shots: Any image/s from a snap that will be displayed on the given public listing page
Media images related to Publishers
NOTE: We are not currently working on public publisher pages but it is something that will be worth considering in this thread.
General
Number
Required
Allowed aspect ratio
Min size
Max size
Recommended size
Max. file size
{publisher-name}-icon
1
1:1
40x40
400x400
256x256
256 Kb
{publisher-name}-banner
1
1:1
640x480
3840x2160
1920x1080
2 Mb
Description of items from the table above:
Publisher icon: Refers to a brand image to be displayed in Snap details pages and (future) public pages from publishers listing additional information
Publisher banner: To be used in (future) public publisher pages in case they will be featured somehow in any of the storefronts or used as a background image for their (future) public pages
Regarding GNOME Software - we would implement this using a Web View for the videos. Based on previous discussions this is probably not going to be accepted upstream, so would have to be carried as a distro patch (and the videos wouldn’t show in other distros). The work is non-trivial but do-able.
Thanks for the notes @jdahlin. Updated content based on our conversation over IRC:
Video
We will not host video media but will allow publishers to include links to media video from popular platforms in their snaps. Some platforms we discussed to introduce: asciinema.org (specifically for terminal-based snaps), youtube.com, vimeo.com (already allowed in the old dashboard).
Images
Right now we are only allowing users to upload image media related to Snaps but in the future, there will be public publisher pages which will allow users the ability to include their branding and perhaps some featured banner to be used in these pages.
There are 2 additional work streams that will help publishers to contribute with acceptable and great media types to the platform: be able to preview a Snap listing page and guidelines and rules for media types (i.e. safe zones for featured banners, guidance on what to showcase in screenshots, avoiding text as much as possible in screenshots…). These will be worked out once we have an agreed direction.
General details
Accepted media formats: PNG, Animated GIFs, JPG / JPEG, SVG (currently converts to PNGs)
Maximum overall file size: 2 Mb
Support for SVG for icons
Upload of SVG images is currently supported for icons which currently convert to PNG format after the publisher uploads them. We have discussed future native SVG support as the majority of clients could render and support this file format.
Limitations for animated GIFs
Minimum frames per second: 1 fps
Maximum frame per second: 30 fps
Maximum length: 20 seconds
Media images related to Snaps
General
Number
Required
Allowed aspect ratio
Min size
Max size
Recommended size
Max. file size
{snap-name}-icon
1
1:1
40x40
512x512
256x256
256 kb
{snap-name}-featured
1
2:1
640x320
3840x1920
1920x960
2 Mb
{snap-name}-shot-#
Up to 4
1:1, 4:3, 16:9
480x480
3840x2160
1920x1080
2 Mb
Description of items from the table above:
Snap icon: This image will be shown in search results, store pages and its details page.
Snap featured: Storefronts might decide to promote a given snap and this media type will allow them to feature a Snap
Snap shots: Any image/s from a snap that will be displayed on the given public listing page
Media images related to Publishers
NOTE: We are not currently working on public publisher pages but it is something that will be worth considering in this thread.
General
Number
Required
Allowed aspect ratio
Min size
Max size
Recommended size
Max. file size
{publisher-name}-icon
1
1:1
40x40
400x400
256x256
256 Kb
{publisher-name}-banner
1
2:1
640x480
3840x1920
1920x1080
2 Mb
Description of items from the table above:
Publisher icon: Refers to a brand image to be displayed in Snap details pages and (future) public pages from publishers listing additional information
Publisher banner: To be used in (future) public publisher pages in case they will be featured somehow in any of the storefronts or used as a background image for their (future) public pages
For screenshots, these are the allowed aspect ratios. What happens if I want to present a screenshot not of the entire screen/desktop (which would presumably match these ratios) but only of my application’s window, which may well not match the ratios? Moreover, what if my screen has a different aspect ratio? (it does - it’s 1920x1200 which is 16:10).
Having discussed this with @jdahlin, @roadmr, and @pheurton last night, I am in favour of the proposed changes to better govern media constraints of screenshots but I have one concern.
My feeling is that enforcing screenshot aspect ratios will introduce a hurdle that will prevent publishers submitting screenshots to the store. Currently, ~75% of screenshots in the snap store do not adhere to the proposed aspect ratio constraints. Few are full “screen” shots, most being an arbitrary size window.
I’d prefer to see the aspect ratio constraint dropped.
I was in that call as well, I hope that the screenshot sizes that would be allowed would also be the ones provided by appstream so that snapcraft’s parse-info could consume from and reuse on the Snap Store.
AppStream is even stricter and only allows 16:9 aspect-ratio screenshots, also requiring that the smallest dimension is 620px, so that part should be covered.
The aspect ratio restriction was intended to prevent entirely nonsensical images (example: a screenshot of the top menu bar only would be e.g. 1920x32 which makes no sense, or a screenshot of the dock which could be 64x1200). But anything somewhat rectangularish should cause no problems, unless clients do expect a very strict set of aspect ratios and have presentation logic (CSS argh) to deal with those aspect ratios and no more.
Requiring an exact aspect ratio, as well as causing needless rejections, would result in a greater proportion of screenshots being full-screen. This in turn would result in a greater proportion of screenshots containing:
prominent bits of shells that a visitor might not be running (e.g. a screenshot taken on KDE)
launchers and panels containing icons of other apps, which their vendors might complain about, if they didn’t want to be associated with your app
bits of windows belonging to other apps, ditto.
I think my original proposal — from 1:3 to 3:1 — would achieve that.
Looking at the feedback from the replies here, we thought that instead of prescribing allowed aspect ratios which as @mpt and @Wimpress suggests could create needless rejections, we can allow a range of allowed dimensions from minimum to maximum with the caveat that the image should be at least 1:2 or 2:1. This can help us avoid strange situations of 1000x30, 300x50, 10x3000…
i.e. If a publisher uploads an image that is 500px wide, then height should be at least 250px tall
