1207591 - badge background color - provide 3 recommended colors

Status: NEW

(WebExtensions :: Frontend, defect, P5)

Description

[Markus Jaritz [:designakt] (UX)]

Currently the developer can pic any color as a background color of the badge attached to a browserAction. To match our Firefox Style Guide we would like to - in addition - provide 3 states for different severity of notifications: Info (grey), Casual (blue), Warning (red) for which we can update the color and have it match our Firefox Style.
Using these states should be preferred by developers to best integrate their add-ons in Firefox.
Besides that we need to handle the case when the developers pics a color that is matching the badge-text-color too closely and might therefor not be readable.

Comment 1

[Shane Caraveo (:mixedpuppy)]

Drive-by proposal for api expansion:

Expand the details object for browser.browserAction.setBadgeBackgroundColor to:

details
  color: per docs
  tabId: per docs
  stateData: {
    info: color
    normal: color
    warning: color
  }

stateData is new.  It is an object allowing for named color states.

Proposal #2:

details
  color: per docs
  tabId: per docs
  state: [info, normal, warning]

This proposal of course requires 3 calls to set all the state data, so I prefer the above approach.

Comment 2

[Leif-AMO]

I'm writing an add-on and have just gotten to the browser action badge, and came across some of these issues.  Not sure if it needs a new bug, bug I also had feedback.

(In reply to Markus Jaritz [:designakt prev :maritz] (UX) from comment #0)
> Currently the developer can pic any color as a background color of the badge
> attached to a browserAction.

As it should be.  There are many colors to choose from, and that can convey state data, which is important when limited to about 4 characters and 1 badge on a tiny 16x16 icon.

> To match our Firefox Style Guide we would like
> to - in addition - provide 3 states for different severity of notifications:
> Info (grey), Casual (blue), Warning (red) for which we can update the color
> and have it match our Firefox Style.
> Using these states should be preferred by developers to best integrate their
> add-ons in Firefox.

While it makes sense to /suggest/ colors for specific classes of information, I think it is unnecessary or overly restrictive to require it or even categorize usage of colors as frowned upon in any way whatsoever.  I've specifically had users ask for some state data to be encoded in color, including every color of the rainbow.  If a user has an accessibility issue with color, it's an exercise for the developer to offer an option, perhaps a fallback to these defaults.

Maybe I want to use red but not to mean a warning, but rather an event that may be of concern.  I want to use orange to signify an event that is of lesser concern.  Yellow to indicate an error (either in my script, or transferring data, etc).  Green to indicate a successful transfer.  Blue to indicate some information.  Violent to indicate a 2nd type of critical event.  And so on.  It's an exercise for the developer to communicate to the user what all these color mean, likely by a small color legend on the configuration page.

Additionally, I think the "Error" state is missing.  Error, Warning, Info, Other.  I have no idea what state "Casual" is supposed to imply, or what meaning it conveys to users.

> Besides that we need to handle the case when the developers pics a color
> that is matching the badge-text-color too closely and might therefor not be
> readable.

To me, this is the wrong solution.  Not only are we suggesting to limit the use of background colors, but now we've restricted the user to a single foreground color, and using that as justification to further restrict background colors, by implementing an algorithm to tell us what we can and can not do.  No thanks!!!

I think the solution here is to allow the foreground color to be changed along with the background color.

The suggestions here risk making the user interface look so bland and boring and unappealing that the user just gets mind numbed even further.  I understand the risk of too many colors causing color fatigue or confusion, and for all the built-in buttons that Mozilla provides, it makes sense to keep them consistent.  But when a user goes out of their way to install a web-extension, they have already expressed an interest in doing things differently, and they likely have some awareness of the complexity of information provided by such a web extension, and likely are hoping to get information AT A GLANCE and not by moving mouse to the button and hovering to wait for a tooltip to see if the button title has changed.  They will rapidly complain to me, or just uninstall the add-on and go get an Android app which is allowed to create a proper interface targeted towards a specific niche of users with a capability of multi-color comprehension and expectation of multi-color interface elements.

Comment 3

[Markus Jaritz [:designakt] (UX)]

(In reply to Leif-AMO from comment #2)
> I'm writing an add-on and have just gotten to the browser action badge, and
> came across some of these issues.  Not sure if it needs a new bug, bug I
> also had feedback.

Thank you for your feedback. You are totally right. Developers that think about what colors to use should be free to use what they think is right. Those states are intended to be an easy solution for devs that do not want to think about color and trust that the Firefox default works. (The Firefox default colors could in future hopefully also be changed with a theme, or tie into windows high contrast settings, solving the accessibility problem you mentioned. - Without the dev needing to do extra work.)


> I think the solution here is to allow the foreground color to be changed
> along with the background color.

What do you think will be the benefit of changing the text color? (Other than readability - which more easily can be solved by inverting the text at a certain brightness)

Comment 4

[Leif-AMO]

(In reply to Markus Jaritz [:designakt prev :maritz] (UX) from comment #3)
> (In reply to Leif-AMO from comment #2)
> Thank you for your feedback. You are totally right. Developers that think
> about what colors to use should be free to use what they think is right.
> Those states are intended to be an easy solution for devs that do not want
> to think about color and trust that the Firefox default works. (The Firefox
> default colors could in future hopefully also be changed with a theme, or
> tie into windows high contrast settings, solving the accessibility problem
> you mentioned. - Without the dev needing to do extra work.)

First let me say this is a great idea to have some defaults as a starting point.  There are many cases where color scheme may not matter much, and having some defaults to throw in during development is nicer than worrying about colors or having a bunch of developers just do it "wrong" (unreadable).  Changing the worst-case scenario from developer time spent making unreadable variants for a user, to minimal time spent to get a consistent color scheme is definitely an improvement.  Having them defined also lends to ease of tweaking on the browser code side.  Not sure how high-contrast settings work on other OSes, but if that's achievable in a portable manner to other OSes besides windows, that would definitely be cool.

> What do you think will be the benefit of changing the text color? (Other
> than readability - which more easily can be solved by inverting the text at
> a certain brightness)

I suppose the main benefit is readability.  The secondary benefit is flexibility or ability to customize.

A cursory search has shown that there are various formal (e.g. W3C WCAG, ITU BT.601, etc) and semi-formal (HSP) algorithmic approaches to measuring brightness, contrast, luminescence, etc.  At best, these appear to quantify the "difference" between FG and BG colors, and define a "threshold" for tolerance, meaning that they define a range, not a specific optimal color.  Although such a threshold could be tweaked to limit the range, and some algorithms even go further to simply resolve to white or black color.

Given a background color, an algorithm might generate a range of suitable fonts, or perhaps simply even black or white.  This might be the simplest implementation, and avoid the need for both validation checks and implementation a new API method (which is difficult for political reasons).  However, it might be an acceptable compromise.  If this avenue is chosen, a decent research process should be conducted to compare the accuracy of different algorithms, rather than just "picking one" that "everyone else" uses because it "feels right".  May end up using such a popular algorithm, or discover, create or refine something slightly better in the process.

Perhaps that could be the solution that everyone could live with, but I will continue to play "Devil's Advocate" and try to make a counter argument for a more thorough consideration.

What if we don't care too much about BG color, just want to set a FG color, and have a BG be chosen automatically, or upon a validation check, be warned of a low-contrast scenario with a range suggested?  The benefit, as a developer, is the sensation that "I can do what I want", as a user, "these buttons stand out with unique colors".

The benefit is that we stay true to the core values stated in the Mozilla Style Guide:

"Firefox challenges the status quo and taunts the titans."

Google didn't implement setBadgeForegroundColor.  So what?  Now unfortunately the API can't be trivially changed, because now we must "cooperate" with 2 monopolies.  With WebExtensions, our core value has disgracefully shifted to "Beholden to the whims of the titans" under the guise of another core value, "Plays nice with others".  There's a distinction between the two.  An example of playing nice: If WebExtensions was developed cooperatively by all parties, then there should be a two-way (three-way, N-way?) process for suggesting modifications, rather than a one-way process of porting whatever Google and Microsoft decide, or whatever least-objectionable thing they allow Mozilla to do.

"Firefox anticipates user needs and delights them with unexpected features, experiences, design and tone."

Delights with "unexpected features" (oh, yes, we love bugs).  ;-)  Is that "Unexpected features" by itself, or a logical modifier to a list, "Unexpected (features, experiences, design, tone)"?  If the list, then flexibility of font color would be an unexpected design.  Although this is likely contrary to everything in UX design.  ;-)  That particular core value statement (unexpected list) is self-contradictory and problematic to logically adhere to, but we would nonetheless adhere to it.

Comment 5

[Kev Needham [:kev]]

Agreed that suggestions for what colours are used are of benefit, and should be part of the style guide and recommended best practices. Enforcing those recommendations isn't something that I see tremendous benefit for, as our recommendations aren't going to fit software developed as an extension of Firefox. 

Foreground colour is something I struggle with, and needs it's own consideration. Given that the background colour will be set explicitly, I'm not clear on why using both approaches wouldn't make sense (other than complexity) where a) if a FG colour is specified, it's used and b) if it's not specified, and the theme colour is close, we'd dynamically change the fg colour. The alternative is forcing a fg colour if a bg colour is used, and I'm not crazy about that, but it would be simple and consistent (it just wouldn't play nicely with theming, which is something we're trying to avoid)

Markus, additional thoughts on what an acceptable approach would be given the ability to arbitrarily set a background?

Comment 6

[Markus Jaritz [:designakt] (UX)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)
> Drive-by proposal for api expansion:
> 
> Expand the details object for browser.browserAction.setBadgeBackgroundColor
> to:
> 
> details
>   color: per docs
>   tabId: per docs
>   stateData: {
>     info: color
>     normal: color
>     warning: color
>   }
>

I was more thinking about changing the definition of color to allow for some firefox-specific variables which would be resolved to colors, like:

> details
>   color: per docs (+ badge-generic, badge-attention(default), badge-success, badge-warning, badge-error)
>   tabId: per docs

but I am sure you best know how to implement to make it easy for devs to use those recommended colors.

Default colors for Photon would be: 
badge-generic   = Grey-20   = #ededf0
badge-attention = Teal-50   = #00feff
badge-success   = Green-50  = #30e60b
badge-warning   = Yellow-50 = #ffe900
badge-error     = Red-50    = #ff0039

(color-names are from http://design.firefox.com/photon/visual/color.html#palettes and available as variables here https://www.npmjs.com/package/photon-colors)

Comment 7

[Markus Jaritz [:designakt] (UX)]

(In reply to Kev Needham [:kev] from comment #5)
> Foreground colour is something I struggle with, and needs it's own
> consideration. Given that the background colour will be set explicitly, I'm
> not clear on why using both approaches wouldn't make sense (other than
> complexity) where a) if a FG colour is specified, it's used and b) if it's
> not specified, and the theme colour is close, we'd dynamically change the fg
> colour. The alternative is forcing a fg colour if a bg colour is used, and
> I'm not crazy about that, but it would be simple and consistent (it just
> wouldn't play nicely with theming, which is something we're trying to avoid)
> 
> Markus, additional thoughts on what an acceptable approach would be given
> the ability to arbitrarily set a background?

(In reply to Leif-AMO from comment #4)
> Given a background color, an algorithm might generate a range of suitable
> fonts, or perhaps simply even black or white.  This might be the simplest
> implementation, and avoid the need for both validation checks and
> implementation a new API method (which is difficult for political reasons). 
> However, it might be an acceptable compromise.  If this avenue is chosen, a
> decent research process should be conducted to compare the accuracy of
> different algorithms, rather than just "picking one" that "everyone else"
> uses because it "feels right".  May end up using such a popular algorithm,
> or discover, create or refine something slightly better in the process.

For arbitrary backgrounds, first consideration is readability of the text on top, as I think everyone agrees on.
For that, changing the text color between light and dark, depending on the perceived luminescence of the background should be sufficient. This delivers readable results for every background as can be seen here: https://codepen.io/WebSeed/full/pvgqEq/
(And as it is only the color of the text on a badge, I don't see how it will be interfering with any theme.)

Choosing the text color independently seams like a separate bug to me.
(I personally see no argument or real world use for it, other then, it is possible to do.)

Comment 8

[Shane Caraveo (:mixedpuppy)]

I think we can just override the color option as you suggest to accept the state words.

So to summarize:

For the color parameter documented here: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browserAction/setBadgeBackgroundColor

We add a third option which is one of [generic, attention, success, warning, error]

That is nice and simple.

I don't really know how your link to npmjs relates to what is in mozilla-central.  Are there css values in m-c somewhere?  ie. if we just add a class badge-attention on the button would that be fine? A quick search for badge-attention provides no results.

Comment 9

[Markus Jaritz [:designakt] (UX)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #8)
> I don't really know how your link to npmjs relates to what is in
> mozilla-central.  Are there css values in m-c somewhere?  ie. if we just add
> a class badge-attention on the button would that be fine? A quick search for
> badge-attention provides no results.

No, those are not yet in m-c but we are working on it. With photon we start to better document design decisions. One of those is, what colors to use across Firefox products. Those are documented here: http://design.firefox.com/photon/visual/color.html#palettes, and instead of just using the hex vaules in products we hope to have them based on variables and/or classes, so that, it becomes easier to talk about colors (teal-50 instead of #00feff) and to allow for easier adaptation of colors if needed.
For developers to be able to easily use those colors, we started to provide those variable in various formats (css, scss, json https://github.com/FirefoxUX/design-tokens/tree/master/colors) and made them available via npm (as our first users are AMO and the Design System website itself). I am not sure how we could best integrate those color-variables into Firefox code, but I wanted to make you aware of their existence, as it might be easier than always copying hex values.

I would hope that it would go something like: have colors.css in Firefox once to define basic colors, like Teal 50, and link those to other variables for specific purposes.

e.g.:

--teal-50: #00feff;
...
--notification-background-attention: --teal-50;
...
--badge-attention: --notification-background-attention;
...
--messagebar-bg-attention: --notification-background-attention;

(cc'ing Amin, as he has started that work on structuring colors and had conversions on how to integrate best into mozilla-central.)

Comment 10

[Eldmannen]

Markus,
It would be really nice if colors.css was available in chrome:// so extensions can reach it and import it.

See also bug 140919.