Cleaning up category badge language in the category drop down

(Sam Saffron) #1

At the moment we have this:

So we have a “foreground color” in the badge UI that basically does nothing except for one case, the category drop down.

This is proving particularly complicated for a few reasons.

  1. We are disrespecting this value in all places except for the category dropdown. which means that people that want the “old” style have no option.

  2. We have UI setting that appears to do “nothing”

  3. We have two very distinct and different ways of showing a category.

  4. If we were to start respecting foreground style, a whole bunch of categories will look invisible.

I think the only real correct way to address this is to unify the style used for the drop down.

I am thinking of ways out of this mess… but just wanted to open this to feedback.

We also are probably going to be stuck with “bar” style respect no foreground, otherwise we can not safely switch it on in an upgrade. But I want to leave the system flexible here.

cc @awesomerobot

(Dean Taylor) #2

Selecting foreground and background colours for 48+ well organised categories and sub-categories when initially moving over to Discourse on one installation was a pain.

Not sure how well that would translate over to just a single foreground colour, there would be overlap.

I can see it working if both the category and subcategory colours are displayed when the subcategory is listed.

Alternatively I would interested to see icon / image selection suggestion taken further as per @codinghorror’s post here:

Because of the amount of UX testing Gmail gets - here is a screenshot of Gmail’s label colour selector, something like this with default colours would have been good back when both fg and bg were the target. However now things are targeting one colour it’s a kinda useless suggestion, sorry.

This what comes up if you select “Add custom colour”:

(Sam Saffron) #3

Another consistency issue the bar has that squares do not, which complicates styling some:

Text is exactly same size but bar half the height, so we need to add special rules here.

(Jeff Atwood) #4

I think I am open to moving to the square style, that will at least resolve the height issue.

But foreground color, you just have to expect that it will only matter if you define a new badge layout that uses it.

(Sam Saffron) #5

I am fine with that, but we need to “consistensize” the drop down somehow. If we are ignoring foreground color we should ignore everywhere, if respecting, we should respect everywhere.

(Jeff Atwood) #6

True, this is really about the category drop down then, isn’t it. Switching to square style would make no difference there.

(Sam Saffron) #7

Yes, that is the biggest open “flexibility” pain we have with the current design.

The height thing is resolved with an extra css rule, but its much trickier to sort out the drop down.

(for example, if people have “bar” style enabled by default we can simply suppress that foreground color selection altogether from the UI)

(Jeff Atwood) #8

Couple ideas. Here’s how it is now…

  1. Just let the button look like a button, don’t inherit any styles or colors. This is probably easiest. Maybe we should do this.

  2. We could add the stripe of color on the left to the regular button

    (and maybe get rid of that line between the button and arrow, and tighten up on space there? that’d be nice)

  3. We could have the color be on the button arrow thing?

I thought about making it just a drop-down floating there in white but that would not let people know it is a button and I think that’s a very bad idea…

Looking at this I favor #2 with the tightening. #1 if we are pressed for time.

(Sam Saffron) #9

option #2 seems fine, will see if I can get it going, will also add copy to the foreground color thing to explain.

(Régis Hanol) #10

Also in favor with option #2 with tightening :+1:

(Daniel) #11

In a project I was working on I used the following method to calculate the contrasting colour (either black or white) to use based on the background colour.

function getContrastYIQ(hexcolor){
	var r = parseInt(hexcolor.substr(0,2),16);
	var g = parseInt(hexcolor.substr(2,2),16);
	var b = parseInt(hexcolor.substr(4,2),16);
	var yiq = ((r*299)+(g*587)+(b*114))/1000;
	return (yiq >= 128) ? 'black' : 'white';

Source and details: Calculating Color Contrast ◆ 24 ways

(Sam Saffron) #12

This is now resolved and style #2 by @codinghorror is now deployed.

I am considering suppressing “foreground color” from the UI if “bar” category style is in place, or at least adding a warning.

(Jeff Atwood) #13