Ribbons

[jcayzac]

To support differentiating prerelease versions of apps (installed from a different URL), Rakuten supports overlaying a ribbon on top of a PWA's shortcut. For example,

The feature is supported by the following additions to the web manifest:

partial interface WebAppManifest {
  attribute Ribbon? ribbon;
};

interface Ribbon {
  attribute USVString text;
  attribute USVString? text_color;
  attribute USVString? color;
};

color and text_color are both processed according to Web Application Manifest » §1.17.2 Processing color members. Our platform provides default values when these attributes are omitted.

Is this something others in the working group would be interested in standardizing? If so, I could send a PR @aarongustafson @marcoscaceres

[aarongustafson]

Interesting. Can you outline use cases for this feature? And is it only for application within an app catalog (rather than in the catalog and the host)?

[marcoscaceres]

I have the same questions as above :)

[jcayzac]

@aarongustafson @marcoscaceres we use this to make it possible to register multiple variants of an app inside the catalog, for instance a separate "beta" version with a different base url. Ribbons show in both the catalogue and the host, so if you use both the beta and the stable variants you know which is which.

The reason we added support for this is so that apps don't need to manually compose the ribbon into their icons, which was previously reported as something they would rather not have to. It also makes it easier to e.g. promote the beta version of yesterday as today's new stable version: just delete the ribbon field and push the code to the stable deploy url.

Another benefit is that we can decide how ribbons are presented, which would not be possible if apps manually composed their ribbons into their icons. As shown in the picture above, we're currently showing the text centered in a ribbon showing at the bottom of the icon, and we truncate the text if it's too long. We could decide to instead show it in the top-right corner of the icon, or even to have long text bounce from left to right. We can even choose to ignore the specified colors completely if we decide ribbons should have a standardized style. Or not show the information as a ribbon on top of the icon, but instead as a tag next to the icon label. Basically, we own the presentation of this information.

[marcoscaceres]

The reason we added support for this is so that apps don't need to manually compose the ribbon into their icons, which was previously reported as something they would rather not have to.

Right, but then it would fall on stores or browser engines to do it... we would probably do it much worse. Consider, for "beta" icon. Some companies like to do it one way, others like to do it another way:

I don't think a store is an a good position to generate something that would please everyone (e.g., the background color, the font, the placement, etc. would be immediate issues, as they might clash with the corporate identity of the product).

It also makes it easier to e.g. promote the beta version of yesterday as today's new stable version: just delete the ribbon field and push the code to the stable deploy url.

Understood, but that's the same as deleting a layer in Sketch and asking it to pump out the new icons.

Another benefit is that we can decide how ribbons are presented, which would not be possible if apps manually composed their ribbons into their icons. As shown in the picture above, we're currently showing the text centered in a ribbon showing at the bottom of the icon, and we truncate the text if it's too long. We could decide to instead show it in the top-right corner of the icon, or even to have long text bounce from left to right.

Again, I feel these are decisions best left to professional designers: computers can't do this reliably.

[jcayzac]

[...] it would fall on stores or browser engines to do it [...] they might clash with the corporate identity of the product

Right. I guess our scenario being that of a super app, our business people are more keen to be in charge of the branding and not leave it to the companies who onboard our platform than a web store or browser would be to inflict fixed design choices upon web sites.

[marcoscaceres]

So... ok to close this @jcayzac?