badge background color - provide 3 recommended colors

NEW
Unassigned
(NeedInfo from)

Status

()

Toolkit
WebExtensions: Frontend
P5
normal
2 years ago
3 months ago

People

(Reporter: designakt, Unassigned, NeedInfo)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webextension-polish][browserAction]triaged)

(Reporter)

Description

2 years ago
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.

Updated

2 years ago
Whiteboard: [webextension-polish] → [webextension-polish][browserAction]

Updated

2 years ago
Flags: blocking-webextensions-

Updated

a year ago
Whiteboard: [webextension-polish][browserAction] → [webextension-polish][browserAction]triaged

Updated

9 months ago
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Flags: blocking-webextensions-
Priority: -- → P5
Blocks: 1303905
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

5 months ago
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.
(Reporter)

Comment 3

5 months ago
(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

5 months ago
(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.

Updated

4 months ago
webextensions: --- → ?

Updated

3 months ago
webextensions: ? → ---

Updated

3 months ago
Flags: needinfo?(kev)
You need to log in before you can comment on or make changes to this bug.