Accent colors

[cassidyjames]

Something we're using as an extension in elementary OS and Pop!_OS is a "primary" color, and a "primary text" color.

https://github.com/cassidyjames/dippi/blob/5b22f996648bf49890b850814da62b4b5ebc4f55/data/com.github.cassidyjames.dippi.appdata.xml.in#L240

This allows clients to have a developer-picked accent color to use how they want in their UI, such as for headers or button accents. "Primary text" is used as a contrasting color when needed, and is planned to be validated for a minimum contrast ratio on the build server.

We do this rather than automatically picking a color from the icon (as GNOME Software does and Flathub used to do), as oftentimes a developer will want to pick a nicely-contrasting color rather than the same color as in their icon.

The exact implementation could be discussed, but I feel like this could be broadly useful as a way to allow developers a little more detail that clients could then use to spruce up the presentation of apps.

[cassidyjames]

Example of this in use in Pop!_Shop:

[hughsie]

The way we do this in GNOME Software is to take the icon, "bin" the colors using a color map and then chose the most "popular" colors. It seems to work well, and I believe it's what endless also does to get the app-tile background and text colors without adding tons of metadata to all the apps.

[cassidyjames]

@hughsie right, that is a way to work around the lack of a developer being able to pick a color. However we've found that in AppCenter apps we're able to get much richer and more interesting color combinations when developers have control over this field. We're happy to continue with using a extension to the spec, but I figured it was worth discussing for inclusion.

For example, here I've picked a contrasting yellow for the accent color, which is much more interesting than what an algorithm would pick out as a "popular" color from the icon.

I know one concern that was brought up before was how clients would present the color; I think it's important to reiterate that clients could use the color however they want (or not at all). In elementary AppCenter, we happen to use it for the header and in promotional banners. I could see a different client using it for an Install button. I could see another client weaving it into the whole app listing in interesting ways. But having a developer-specified color to be able to use enables clients to have a much more rich and interesting presentation.

[cassidyjames]

without adding tons of metadata to all the apps

I'd argue that one or two developer-picked colors is not "tons" of metadata, and the value it adds for branding opportunity is worth it.

[hughsie]

two developer-picked colors is not "tons" of metadata

Sorry, the tons was in relation to the number of projects that would need to be changed rather than the XML additions themselves.

[danirabbit]

@huggsie, I’d imagine that GNOME software could continue using its algorithm as a fallback or ignoring this field altogether so that it wouldn’t be absolutely necessary for developers to add this metadata

[ximion]

I do agree that in principle it makes sense for the developer to define a color to override whatever the software center would autodetect to get a nicer-looking experience.
The question is whether this is universal enough to be in the main spec, and how far we go in case we add a feature like this. E.g. if we allow setting a primary color, would be also want to allow the developers to set more UI customizations in future, thereby creating some kind of design tag?

<design>
    <primary_color>#FF0000</primary_color>
    <header_image>http://...</header_image>
</design>

If the "I want to have developer set a primary color" feature is really ubiquitous and many software centers use it, I would have no reservations to adding it to the spec. If however it's more a thing specific to certain software-centers, then I think it would be better to keep it in the custom tag.

[hughsie]

whatever the software center would autodetect

I do think components should be able to specify colors for accents and text, however I don't think it should be the application author that chooses them. ElementaryOS applications will want to use the Elementary palette, GNOME apps will want to use the Hicolor/Tango Palette, and KDE apps will want to use Oxygen/Breeze. Allowing applications to chose from all these different palettes means, put bluntly, that the software center will look generally crap.

The accent colors are, like choosing which apps to feature, are something for a store "curator" to decide -- and whilst I think it's a good idea to express this in AppStream (perhaps with the software-center as a tag attribute or key prefix) I don't think we want to let app authors decide this. If we did, what would we do with this application:

<background>#000000</background>
<font>#FF0000</font>

i.e. fully saturated red on a 100% black background. Or an app that puts:

<background>#FF0000</background>
<font>#CF0000</font>

Where you can't actually read pink text on a red background. I'm also not sure how we'd make this high-contrast them-able for partially sighted users, without just ignoring the values altogether. I don't think you can make a software center that actually looks cohesive and not just a jumble of apps without some kind of manual curation.

See https://src.fedoraproject.org/cgit/rpms/appstream-data.git/tree/fedora-categories.xml or https://src.fedoraproject.org/cgit/rpms/appstream-data.git/tree/steam-oars.xml for what we do in Fedora to add metadata to existing applications.

[cassidyjames]

I do think it's partially up to a distributor to screen appdata for quality at this point already; the exact arguments could be made for the name, icon, and screenshots of an app.

Apps could set a terrible, unrecognizable icon, have an awful screenshot, and be named something incoherent. Choosing an accent color is not that much of a stretch there. Plus, apps intended for GNOME use GNOME-style icons and take screenshots with the default GNOME settings; apps intended for KDE use Oxygen-style icons and take screenshots in a KDE environment; apps intended for elementary OS use elementary-style icons and have screenshots from elementary OS. That is just the reality of having several different platforms that apps are targeting, and those are all things the authors of the app have the responsibility to consider.

For the record, several apps for elementary OS don't actually use the elementary palette; most pick a complimentary color to their icon and app branding that would work well on any platform. In the case of the previous Firefox screenshot, that's the Firefox brand blue and it looks great in the app store along with other branded apps.

[hughsie]

Apps could set a terrible, unrecognizable icon, have an awful screenshot, and be named something incoherent

Agreed, all good points.

and it looks great in the app store

But where do we draw the line? Do we let apps define the background image? The font color? I know a single static color isn't going to be enough for the GNOME designers; at the moment there's app-specific CSS (!) for the app banners to define things like the font, border, background, etc.

[cassidyjames]

I suppose I'm proposing to draw the line, to start, with one or two colors. 😄 To reiterate, this is something we've been doing in elementary OS with around 100 developer-submitted apps over the last year, and it has worked well for us so far.

We've also talked in the past about more rich branding opportunities like fonts and imagery, but decided that an icon, app name, summary, screenshots, and a couple of accent colors were a great start for developers while considering the constraints we wanted to impose.

[hughsie]

I'm proposing to draw the line, to start, with one or two colors.

:)

I assume those colors would be fully opaque, i.e. have no transparency?

[cassidyjames]

I think that's up for discussion. But I do think that makes sense, that way app stores could more easily use opacity and shades without worrying what's "underneath" those colors. In AppCenter I believe we use it as a CSS color, which means technically anything that's supported in CSS is supported in this field. But I think I would be okay restricting it to a single format without an alpha channel.

[bertob]

GNOME Software uses colors for its banners as well now, which are defined as a custom appstream tag. The current syntax for that isn't great, and we'd like to have something nicer going forward. I wonder if it would make sense to standardize this across desktop environments?

Some thoughts:

• Do we need a second set of colors for dark? If not, do we need to do something else for very bright backgrounds once we get the system-wide prefer dark setting (since the banners have a pretty large area)?
• Do we want to allow fancier types of styling? I could imagine gradient backgrounds being quite nice for this.
• The banners in GNOME Software do not have an app-defined foreground color currently, but if that makes things simpler to standardize I'd not be against adding that. For the record though, I'm not sure how much value the second color adds and whether it's worth it given that it's more work and it's much easier to create an ugly combination for developers not well-versed in design.

Relevant Software issue https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1445

cc @allanday @pwithnall @Kekun @Exalm

[cassidyjames]

I'm not sure how much value the second color adds and whether it's worth it given that it's more work and it's much easier to create an ugly combination for developers not well-versed in design.

That's a fair point but something we're going to run into with any increased branding ability. We really like having the ability to set a background and foreground for AppCenter, though: some developers go for a more bold look when it suits their app, while others go for a more subtle look; I don't think this would be possible with only one color.

For some more concrete examples in production, the elementary Calendar uses a light background with a dark green foreground because it's similar to the in-app styling of a mostly-neutral UI and subtle green accents by default:

…whereas my Palette app uses a fun, bold color as the background with a neutral foreground because it fits in better with the style of my app:

Having either of those use the other style (just a colorful background or just a colorful foreground) may be possible, but it wouldn't let them be as expressive and intentional with the design.

Do we need a second set of colors for dark?

This is a really good point, and something our current system in AppCenter doesn't consider. In the Calendar example, that would be much nicer if we could pick an alternate set of colors for a dark style.

Today	Potential alternative color scheme

[cassidyjames]

Something I'm noticing for most if not all AppCenter apps: most use what would be considered a primary accent color as either the foreground or background, and then a contrasting neutral as the other.

This might be over-complicating, but I'll spitball for completeness sake: it would probably serve AppCenter just as well for developers to only pick one color for their app, and then for them to choose if their branding should be "bold" or "subtle" or something similar.

If "bold," we'd use their color as the background and use a mathematically contrasting foreground color (e.g. white or black, possibly subtly tinted with their color). If they chose "subtle," we could use their color as the foreground with a mathematically contrasting background.

That would cover the cases above, and most that I'm seeing in AppCenter. (Calendar would be "subtle" with its green accent color, while Palette would be "bold" with its yellow accent color.)

I have no idea if that's just over-complicating things, or actually really clever, though. And I guess it would give software stores more flexibility in what to do with those colors, which could be good (for diversity of implementations) or bad (for lack of clarity in the spec).

[bertob]

only pick one color for their app, and then for them to choose if their branding should be "bold" or "subtle" or something similar.

Looking at the apps on the appcenter page it does seem like there's only a handful of apps that currently do this, so not sure it's worth the extra effort. That said, given that it's just a boolean and frontends are free to ignore it, I don't have a super strong opinion.

My feeling is it would be good to keep this simple for app developers and have just two colors (light and dark), rather than four, or ideally just one (maybe we could darken the light color automatically if its lightness is above a certain level?).

[sophie-h]

I'm not in favor of supporting "bold" and "subtle" selection in GNOME because the design of the software using it would become too inconsistent for my taste.

I also tried custom bg and fg colors on apps.gnome.org and it just doesn't give me any beneficial results compared to black/white fg colors. Might be due to the GNOME color palette. But also most likely something that GNOME wouldn't use.

But also, if others have a use case for it I'm fine with it as long it is okay to ignore the properties :)

I'm mostly thinking of the accent color as part of the app's brand. That's why I'm a bit skeptical about having two different colors for light and dark. However, adjusting the color to get a good contrast could lead to undesired results that are out of control for app developers? Maybe I will do some real live experiments on GNOME apps for this.

[cassidyjames]

@sophie-h I'll also propose a branch against either the AppCenter client or AppCenter website that dynamically chooses a contrasting color as well so we can get a variety of apps and colors to see how it works.

[sophie-h]

@cassidyjames Forgot to give an update. Darkening yellow shades like the one of Music gave very questionable results. That's why I currently think that we probably need two different colors for light/dark.

[ximion]

Sorry for the delayed reply, this was an interesting read!
TBH though, I may be slightly more confused now than I was before, but let's try to cast this into a specification addition for AppStream that application authors can use.
Fundamentally in the past it has proven to be a good idea to design things as extensible as possible and to create logical groupings in the XML. And it looks like having multiple colors defined is at the very least something people may want.
I was wondering how the logical group that those colors would be in would be called, and I came up with "presentation", as it is how the app is presented to the user ("style"/"styling", "appearance" etc. felt a bit to broad, as we aren't defining the apps appearance here).
So, a possible XML block that people can use may be something like this:

<component type="desktop-application">
  <id>org.example.StylishApp</id>
  [...]
  <presentation>
    <color type="primary">#ff00ff</color>
    <color type="secondary">#993d3d</color>
  </presentation>
</component>

I am not sure about the "primary"/"secondary" naming for the color, as that may be awkward if we ever add a third color. Adding a "foreground"/"fg" and "background"/"bg" color type is a lot more specific and will indicate to the app author how those colors will actually be used. But using the would mean that the specification has to require software centers to use these colors for foreground, background and possible text colors, so we would be adding design requirements to the AppStream spec (which I don't have a problem with, but which may not be universally considered a good idea).

What do you think?

[cassidyjames]

@ximion I think a presentation block makes sense; my only other suggestion naming-wise might be branding, but I don't care that much.

It's probably worth deciding what we do want to support here without getting overboard; something we enforce on the elementary side via review is a level of contrast between the two colors provided, but if all we want is an accent color to be used with light styles and an accent color to be used with dark styles (e.g. if we expect software centers to determine how to use them, and an appropriately-contrasting color themselves when used in UI), then we should just name them in a way that that's more clear. To take heavy inspiration from the web CSS spec,

<component type="desktop-application">
  <id>org.example.StylishApp</id>
  [...]
  <presentation>
    <color type="primary" prefers-color-scheme="light">#ff00ff</color>
    <color type="primary" prefers-color-scheme="dark">#993d3d</color>
  </presentation>
</component>

…or maybe something less verbose, but in that vein.

[sophie-h]

I'm happy with @cassidyjames' proposal :)

We don't have use for a second color at the moment but, if someone else has it does not hurt if it exists.

I think we should use the same property name for light/dark mode in #304.

[amifelipek]

This is great! I'm working on a homepage redesign for KDE's software center and we could use the app's branding colors in these featured cards:

[ximion]

@cassidyjames

@ximion I think a presentation block makes sense; my only other suggestion naming-wise might be branding, but I don't care that much.

I think branding may actually be even more obvious as to what it's for.

It's probably worth deciding what we do want to support here without getting overboard; something we enforce on the elementary side via review is a level of contrast between the two colors provided, but if all we want is an accent color to be used with light styles and an accent color to be used with dark styles (e.g. if we expect software centers to determine how to use them, and an appropriately-contrasting color themselves when used in UI), then we should just name them in a way that that's more clear. To take heavy inspiration from the web CSS spec,

Using exactly the same attributes clashes with how AppStream names things, but taking inspiration from there makes sense.
So, probably something like this:

<component type="desktop-application">
  <id>org.example.StylishApp</id>
  [...]
  <branding>
    <color type="primary" scheme_preference="light">#ff00ff</color>
    <color type="primary" scheme_preference="dark">#993d3d</color>
 </branding>
</component>

This needs specification and implementation, maybe I can get to that this week or next week.

[ximion]

This is specified & implemented now. Please review the changes, as I intend to make a release next Tuesday (and once this is out there, making changes again is very hard!).
The implemented stuff matches the things we discussed in this thread and the specification addition in cbddee6.

[bertob]

It looks to me like you added both primary and primary-text, i.e. background and foreground colors, but reading through the thread here it seems to me that people were leaning towards the latter not being needed?

I don't have a super strong opinion here since it's all optional, but my feeling is that it'd be better to start with just background, and maybe revisit the foreground question once we see how it works out in practice. As you said, changing/removing stuff later is hard :)

[ximion]

Ah, I was under the impression that @cassidyjames needed a text color to realize a mockup like the one from the Pop!_Shop.
If it's not needed (yet) I would like to add it later when needed, rather than doing a preemptive strike that may not be required at all ;-)