I am unable to add screenshots to Wekan snap listings.
As of today this is fixed thanks @Lin-Buo-Ren 
@xet7 This is due to the new media restrictions and the front-end not handling them properly, I’ve updated https://github.com/canonical-websites/snapcraft.io/issues/1663 with the current status 
Around 120 cols by 24 rows works pretty well
1 Like
Based on our conversation, we decided to move away from featured and use the term banner instead as featured might imply additional consideration.
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 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 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}-banner | 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 banner: 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
Note: Support for the old GNOME Software banner (1218x240 using -banner.jpg at the end of the file) will be temporary as we will transition to use the banner specified above.
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
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
@cprov let me know if you want to discuss further
@pheurton My only objection is trying to “formalize” the legacy banner support. IMO, we should leave the legacy banner support as is and promote the new banner experience across the ecosystem.
The legacy banner can coexist with the new banner, if necessary and under the current terms (fixed dimension and specifically named screenshot), but it will eventually be forgotten and die.
1 Like
It seems this post is now missing banner restrictions altogether!?
What I’ve implemented on the snapcraft.io publisher side for the new banner media type: Image type: PNG or JPEG File size limit: 2mb Aspect ratio: 3:1 Max dimensions: 4320x1440 Min dimensions: 720x240
@pheurton @kenvandine @cprov can we agree on these restrictions?
If so,
- the front-end (uploading of assets) is ready to go
- the store binary-data API will need updating to the new restrictions
- Snap Store snap, GS etc. will need updating to use the new sizes
2 Likes
The image type, file size and min/max dimensions are fine for GNOME Software; the aspect ratio is a big change.
Is the intention that the whole banner image be always visible? Banners are currently stretched to fit the screen width and cropped to fit the available space.
If we just updated the banners to the new aspect ratio then without any futher changes it would look like this:
If we fit them vertically it looks like this:
Note the text and icon would not be used - just showing these examples to give an idea of the GNOME Software behaviour. I used the currently promoted snap (krita) which has a much wider banner and cropped it to be 1:3.
If we accept the banner aspect ratio of 1:3 I see us as having the following options:
- Centering the banner as shown in the last two screenshots.
- We need to work out what to put in the space either side of the banner (if anything).
- Not a lot of work, and should be upstreamable.
- Showing multiple banners to fill the available space.
- Resolves the whitespace issue from above.
- Reasonable amount of work, but doesn’t align with existing banners used upstream so may not be acceptable.
- Use a new home screen layout in GNOME Software.
- Allows us to place banners in any desired layout.
- A lot of work and expected to be sufficiently Ubuntu specific that would not be upstreamable.
If we go with options 2 or 3 then we’d probably also need to do option 1 for non-Ubuntu users of GNOME Software to have an acceptable experience.
1 Like
The idea long-term is to remove the requirement of having an icon and snap name overlay and instead have publishers “bake-in” the logos or text.
Would that mean its possible to scale the image up with the window, to a maximum width, then center the image, without needing any magic to keep the icon and text over the background? This would probably need some design/ UX input /cc @pheurton.
Based on the options proposed I’d say option 3, is the preferred.
Option 1 is a sensible fallback if there is no banner.png and banner-icon.png. If those files are available they should be used - as they currently are - in place of option 1. You’ll have to advise on the potential of upstreaming that logic.
1 Like