Restrictions on screenshots and videos in snap listings

#1

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.

#2

In the absence of any other input … here’s a straw-person proposal for screenshots:

  • Maximum number: 4
  • Minimum dimensions: 640 px × 640 px
  • Maximum dimensions: 4096 px × 2160 px (the biggest common 4K variant)
  • Maximum file size: 20 MB
  • Aspect ratio: from 1:3 to 3:1
  • Animation: none

And for videos:

  • Maximum number: 1
  • Minimum dimensions: 640 px × 640 px
  • Maximum dimensions: 4096 px × 2160 px
  • Minimum duration: 10 seconds
  • Maximum duration: 30 seconds
  • Maximum file size: 50 MB
  • Aspect ratio: from 1:3 to 3:1
#3

I think we need to take into account what restrictions Gnome Software has for screenshots @willcooke ?

#4

Paging @robert.ancell, our GNOME Software guru.

Show screenshots on the web store?
#5

GNOME Software has no limitation on the number of screenshots, though it doesn’t handle it particularly well (this is 100 screenshots):

Screenshot from 2018-01-09 09-18-17
Screenshot from 2018-01-09 09-18-17.png1200x860 68.6 KB

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.

#6

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.

#7

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 :heavy_check_mark: 1:1 40x40 512x512 256x256 256 kb
{snap-name}-featured 1 2:1 640x320 3840x1920 1920x960 2 Mb
{snap-name}-shot-# Up to 4 :heavy_check_mark: 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 :heavy_check_mark: 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

–

Thoughts @cprov @evan @mpt ?

#8

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.

#9

Thanks for writing that up @pheurton.

A couple of comments:

  • This should also mention that we support SVG for icons, but they are currently converted into PNGs when they are uploaded by the developer.
  • JPG/JPEG is the same format.
  • Would be good to see some kind of frame rate constraints for the Animated GIFs as well.
#10

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 :heavy_check_mark: 1:1 40x40 512x512 256x256 256 kb
{snap-name}-featured 1 2:1 640x320 3840x1920 1920x960 2 Mb
{snap-name}-shot-# Up to 4 :heavy_check_mark: 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 :heavy_check_mark: 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

–

#11

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).

  • Daniel
#12

Then you have to crop to one of the ratios

#13

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.

#14

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.

#15

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.

#16

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.

#17

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?

#18

Just bump on the new screenshot restriction with the following CLI screenshot:

download-pixiv
download-pixiv.png872x193 40.8 KB

Not going to complain it as it can be easily workarounded by resizing the window, or use screenshot generators like Carbon.