Annotation color

[HadrienGardeur]

In the current draft, each annotation can provide a different color using the color property and values based on the CSS3 Color Module Level 3.

With our recent discussions around Media Overlays, we've seen that this approach is problematic:

• there's no guarantee that the selected colour will work well with the user preferences for a book
• even if it does, it might be problematic for users who cannot perceive properly a number of colors

By allowing an almost unlimited number of values, we also open the door to a "rainbow coloured rendering" of a publication, where dozens of colors could show up on a single page if you start combining several annotation sets.

I think our approach should be different:

• instead of allowing unlimited values for colours, we should bring this down to a subset of named colours instead
• since reading systems are very likely to adopt a colour per tag or per annotation set to make them easy to identify, we should also take into account that reading systems MAY override any of these values

Reading systems SHOULD enable filtering by color or by tag. Filtering by color is not sufficient because imported annotations may have the same color as personal annotations, or both may have no colour to enable them to be disambiguated.

With unlimited colour values available, I don't see how filtering by colour could reasonably work. With a subset, this could be considered, but it seems like a slippery slope as soon as you allow several annotation sets.

IMO, filtering by tags and annotation sets is more reliable overall.

[llemeurfr]

You are introducing 2 discussions here:

1. Should we standarize a color set?
2. If we don't, should we allow filter by color?

If we standardize a color set but an app can add colors, the standardization is destroyed.
If we try to standardize a color set with no escape for apps, I fear that the community will spend ages getting a consensus on the set (a11y friendly, compatible with the taste of the designers of different apps ...).

If we don't allow filtering by color, we loose an obvious way to filter personal annotations in an app.

I recognize that filtering by colors imported from another app by color code, is not perfect. We are experiencing it now with our dev on Thorium.

[HadrienGardeur]

I would avoid variants of the same colours, such as bluegreen and lightblue.

Let's first document what's used out there, and I'm sure we'll be able to figure out a reasonable subset of values.

[HadrienGardeur]

Here's an early look at some of the largest platforms:

Apple Books (macOS)

• Yellow
• Green
• Blue
• Pink
• Purple

Google Play Books

• Yellow
• Red
• Green
• Blue

Kindle

• Yellow
• Blue
• Pink
• Brown? (Orange?)

Libby (Overdrive)

• Yellow
• Pink
• Green

Kobo

• Yellow
• Purple
• Blue
• Green

Total (so far)

• Yellow (5)
• Green (4)
• Blue (4)
• Pink (3)
• Purple (2)
• Orange (1)
• Red (1)

We see that most of these apps offer 4 different colours, which means that 5 to 6 values should probably be what we aim for as a maximum. Thorium is currently a bit of an outlier with 8 different values.
Yellow, green and blue already look like must-haves, with pink being in a good position too.

[llemeurfr]

Our designer (Mylène) chose a color set with accessibility in mind. I can agree with other comments about the proximity of some of these colors.

[llemeurfr]

Pierre recommends to select a subset of https://www.w3.org/TR/css-color-3/#svg-color, and let the apps change the exact RVB nuance according to designer's taste.

[HadrienGardeur]

Pierre recommends to select a subset of https://www.w3.org/TR/css-color-3/#svg-color, and let the apps change the exact RVB nuance according to designer's taste.

That's aligned with what we've said so far with @mickael-menu. But the real question is "how small of a subset"?

["yellow", "green", "blue", "pink"] is a valid subset for example.

I'm convinced that a large subset would work against the interoperability of this feature, since most apps stick to anywhere between three and five different colors.
With a dozen colors, you could end up with three different apps that each use three unique colors.

I can continue to document what's used in various apps, targeting for example scholarly reading app as well to see if they offer an extended set of values. But all in all, we already have enough data to see that we should target eight values at most (and ideally less than that).

[llemeurfr]

Follow-up : this is what is used by Thorium 3.0 beta.

Which corresponds to the following labels:
red, orange, yellow, green, blue-green, light-blue, cyan, purple

In this set, blue-green is not part of CSS named-colors, and is really similar to green and light-blue, let's remove it.
Let's rename light-blue to blue.
Let's remove cyan, which is a kind of blue.
I see that no app has both red and pink, both can be similar (depending the nuance), let's forget pink.

We get 6 colors which can be easily distinguished:
red, orange, yellow, green, blue, purple

[HadrienGardeur]

I see that no app has both red and pink, both can be similar (depending the nuance), let's forget pink.

In the apps that I've listed, pink (3 apps) is far more common than red (1 app). If we had to select between them, it would be more logical to drop red.

I agree that 6 colors is a good balance, but 5 colors might be even better 😁
For apps that only support 3 colors, we could get two apps with a completely different selection if we go with 6 colors, whereas they'll always have at least 1 color in common with 5.

With apps that use 4 colors, there would always be 2 colors in common if we go with 6 colors in total vs 3 colors in common if we go with 5 colors in total.

Let's map this back to the examples that I've listed above.

If we take the following colors:

• Yellow (5 apps)
• Green (4 apps)
• Blue (4 apps)
• Pink (3 apps)
• Purple (2 apps)

This would be the coverage:

• Apple Books (5 out of 5)
• Google Play Books (3 out of 4)
• Kindle (3 out of 4)
• Libby (3 out of 3)
• Kobo (4 out of 4)

Thorium is a bit of an edge case currently, but with these 5 colors we would match 4 out of 8.

[llemeurfr]

What should apps do if they support only 3 or 4 colors (different from the ones we define) and product owners don't want to extend their set?

I imagine the only fallback is translating and merging colours on display (if the inner model supports keeping native colours on disk) or on import. For instance, if an app supports yellow, blue, pink, brown: red can be changed to pink, brown to orange, green and purple to blue.

There is a semantic loss, but the user still gets the most of what his app can provide.

[HadrienGardeur]

There are different use cases that should be considered separately:

• apps that only support 3 or 4 colors
• importing annotations in an unsupported color in an app with 5 colors
• exporting annotations made with a color that's unsupported by the specification

Apps that only support 3 or 4 colors

In addition to highlight colors, apps should also have a "neutral" option. Underline could serve that purpose for example.
For these annotations, apps shouldn't do 1-to-1 color substitution (apps with only 3 or 4 colors won't be able to do so anyway), instead they should use the neutral option and display the unsupported color as a special tag that can only be substituted to another official color.

Importing annotations in an unsupported color in an app with 5 colors

For this use case, it's tempting to match missing colors, but this could lead to a confusing user experience when navigating between multiple apps.
I think that using a neutral option remains the best option, but if the app substitutes a color, it should also follow the "special tag" approach.

Exporting annotations made with a color that's unsupported by the specification

Using a tag is the best approach in this case.

[llemeurfr]

The "neutral" option could be a grey color on display.

[llemeurfr]

I updated the spec from this discussion.

• changed allowed values for the colour property -> proposal for 6 values.
• added a section in the RS guidelines: https://github.com/readium/annotations#46-dealing-with-colors with simplified rules vs those proposed by @HadrienGardeur.

Note for subsequent discussion in this thread: I renamed tag to keyword. I feel that the notion of tag is associated with multiple values, but we want only one value per annotation. Keyword is less associated with multiple values. Category could be even better. This can be another discussion item.

Using a keyword as an alternative to a colour seems like a hack. And what if the annotation already has a keyword?