We currently look for a two screenshots uploaded with the name “banner.png” or “banner.jpg” and “banner-icon.png” or “banner-icon.jpg” and use these to promote this snap:
When then hide these screenshots from the screenshots when viewing the snap details. Note that no other client would understand this and show these images as screenshots. GNOME Software is using a regular expression to match these files (since Django can add a suffix onto them):
^banner(?:_[a-zA-Z0-9]{7})?\\.(?:png|jpg)$
This is obviously pretty hacky… So we’d like to pay down some technical debt.
What I propose we do:
Check if any other clients are going to make use of this feature, and if so check the format of the banner and icon are suitable for these.
Consider any additional information we would like to have for promoted apps. For example, the font colour is currently hard-coded to black but that would be probably be better configurable (as it is for existing promoted apps in GNOME Software).
Add two new database fields for the banner images and the associated web UI to set these (this would be a variation of the screenshot code). Add any other fields as determined in step 2.
Pass these banner URLs through snapd to the client.
Migrate any existing apps to the new database format.
Update GNOME Software to make use of the new format (synchronised with step 5).
border-color: #000000;
text-shadow: 0 1px 1px rgba(255,255,255,0.5);
color: #000000;
outline-offset: 0;
outline-color: alpha(#ffffff, 0.75);
outline-style: dashed;
outline-offset: 2px;
background: url('https://dashboard.snapcraft.io/site_media/appmedia/2017/08/banner-icon_Ugn6pmj.png) left center / auto 100%% no-repeat, url('https://dashboard.snapcraft.io/site_media/appmedia/2017/08/banner_MgEy4MI.png') center / cover no-repeat;
So we can easily control anything on the background with that. This also seems suitable for use in a web UI.
The title and summary are straight from the app metadata, so would require work with upstream if we wanted these to show something different than the details page.
Are we collecting any of this in a document that can be tracked (ideally a plain-text file that can be kept in version control). I would love to see this become the standard way to describe the associated meta-data. Is this something we should be contributing to Appstream?
@zyga-snapd do you mean the CSS format? As far as I can tell this is only currently used by GNOME Software, so the documentation is the gnome-software source. G-S pulls out CSS from AppStream data by looking at the “GnomeSoftware::FeatureTile-css” metadata item - this must be an extension (it’s not in the spec). There doesn’t seem to be any recoded discussion on the appstream mailing list.
Regarding the media detection problem, we are designing a new version of the snap API that is accounting for this issue and will return metadata for all media specifying what media type each item is, so this will surely help with identifying banners (one of the media types would be banner).
Regarding storing the CSS, that feels like a feature that could get complicated and messy pretty easily and pretty soon.
I would advice instead to see if the snap title can be placed outside the banner, or if Gnome Software can have defined a title CSS that would show a soft white-transparent background to ensure the black text is always visible, or have a white border for each letter?
In any case I would suggest to contact our design team so they understand the problem, review the specifics, and make a recommendation.
The Apple Store Guidelines seem to request several graphics but as for the banner it is composed of two images, the background (“Backdrop”) and main graphic (“Subject”), no css or other code involved.
I wonder how Apple does the text. The images seem to imply it’s overlaid but there doesn’t seem to be a text colour mentioned. Perhaps it is always white (so you need to make a background that’s appropriate) or it analyses the background to choose white or black? As @natalia said we could do an outlined font to cover both cases.
I’m told this will be raised at the next Design-Desktop meeting, so hopefully we can get some design input on it.
I’ll be picking up the banner work over the next few weeks and would like to understand how Gnome currently works and how we can integrate with the snapcraft.io publisher experience
the font colour is currently hard-coded to black but that would be probably be better configurable (as it is for existing promoted apps in GNOME Software).
Could I get a 101 on how this is done?
Is this layover text required? Here’s Apple’s banner:
Using the wordmark keeps the banner branded like the application which will keep publishers happy and add to credibility of an application (it’ll feel more like Redshift Astronomy). We currently ask for a banner_image and banner_icon, we already have the snap_icon perhaps we could explore something like this?
Banners in GNOME Software can use any GTK+ CSS. In the case of snap banners we generate some basic CSS. This is where we have to guess the text colour. The use of CSS seems overkill / not appropriate to ask our publishers to provide.
There is a tool provided installed that actually allows you to generate banner CSS:
$ gnome-software-editor
The layover text is currently required, though we could probably add a method to override this for our banners. The advantage of the overlay is they are easily translatable, though as you point out you get a much nicer visual effect being in full control of the text. If we do remove the text layer we should make sure banners can be uploaded for each language as required.
What is more difficult is how the banners scale to the available width. This means that the top and bottom of a banner can be clipped off. This is harder to handle if it contains text / details that look bad clipped. How does the Apple solution handle this?
I’ll talk with upstream about making the text overlay optional and fixed height banners.
Having a play, I think we can actually do everything via CSS. We can set the font size to 0pt, which will effectively hide it. We can also lay out the background in any way - so you just need to specify what we will do (letterbox it?).
The use of CSS seems overkill / not appropriate to ask our publishers to provide.
Agreed!
This is where we have to guess the text colour.
#Dangerzone
We can set the font size to 0pt, which will effectively hide it.
Interesting… Would definitely be worth exploring. The plus side for using text is:
There may be an issue for publishers to provide quality assets to be featured
Using text means that app titles are “always” legible.
They are easily translatable
in-line with how other package formats are featured
The downside being:
Off brand for publishers
Having to guess accessible colours (is this a manual process)
$ gnome-software-editor
Thanks for the tip! Having a play with that now.
(letterbox it?)
Exactly. If we do an audit of the possible banner sizes, we can create a template with ‘art safe areas’ and provide guidelines in the docs on how to use it. This can then be extrapolated to other software centres too. A la Apple’s example:
There is also a piece of work for us to design a ‘promo banner preview’ where a publisher can see what their banner would look like in a Gnome-like software centre.
I’d like to stress the importance for the ability to put these files in the repository itself so people can easily create a PR to a snap to change/update the banner.
There may be an issue for publishers to provide quality assets to be featured
Off brand for publishers
