In the absence of any other input … here’s a straw-person proposal for screenshots:
And for videos:
I think we need to take into account what restrictions Gnome Software has for screenshots @willcooke ?
GNOME Software has no limitation on the number of screenshots, though it doesn’t handle it particularly well (this is 100 screenshots):
It also doesn’t limit the screenshot sizes.
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:
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).
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 | 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:
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 writing that up @pheurton.
A couple of comments:
Thanks for the notes @jdahlin. Updated content based on our conversation over IRC:
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).
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.
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.
| 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:
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.
Hi folks,
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:
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
Thoughts?
Just bump on the new screenshot restriction with the following CLI screenshot:
Not going to complain it as it can be easily workarounded by resizing the window, or use screenshot generators like Carbon.
Note that the snap banner and banner icons documented in Getting ready for stable are no longer upload-able due to this restriction.
