update text and background color for contrast. add fill and border to…

[bowenli]

Fixes #1943

• On contrast mode, text color set to black, background set to white (no gradient)
• Label background set to white (no transparency)
• Visual update of nodes

• Note: there is an existing bug where sometimes the node rendering has a gap between the fill and border. This PR does not fix this.

[davkal]

Looking at the big screen, my first reaction is that it looks less slick, but that was expected. To qualify this a bit more, I feel like the number of things on the screen vying for my attention increased.

On closer inspection I feel like the 3-color version of a node looks a bit cluttered with the two outlines.

I've created a version with two colors that makes use of a third transparent outline.

Here is the diff https://gist.github.com/davkal/c290c6fea25c6930eb15b43effac94d7

@foot WDYT?

[rade]

How is this supposed to work with metrics-on-canvas?

[davkal]

How is this supposed to work with metrics-on-canvas?

The background turns transparent again:

[foot]

Nice variations guys!

• Solid rank color on nodes does look a bit jellybeany and "less slick"
• But! makes rank much much clearer which is cool.
• But! Rank color is not actually that useful right now. [RFC] Separate node colors #1567

On 2 vs 3 tone

• I like the two tones
• But! I also think having a node as an "unbroken" solid, unclutters things and simplifies the diagram a bit.

[davkal]

Unbroken variant with 2 tones:

To add detail we could introduce the empty space at close zoom levels 👀

[foot]

Yep! Either the 3-tone, or the transparent (or bg colored) ring could make an appearance at closer zoom levels to make it look more... slick?

[rade]

• On contrast mode, text color set to black, background set to white (no gradient)
• Label background set to white (no transparency)
• Visual update of nodes

I suggest we do the first two only, which seem uncontroversial.

[bowenli]

The outer border ended up way bigger than I envisioned. The outline controls were a bit difficult to accurately position. Here is how I designed it:

[bowenli]

I think the 2 tone version is still nicer than it currently is.

[pidster]

If the original issue is about readability, the PR fixing it should address just that and not a change of colour - which seems unrelated to me.

[davkal]

I'm fine with the first two items as well.

As for the node changes, I would propose to go with 2 tones, but have the light one be lighter than what getNodeColorLight currently returns for the normal mode, and maybe the current getNodeColorLight for the HC mode. Also, getNodeColorLight is probably used in other places too, so you may need two different one.

[rade]

This has been dragging on for far too long. Move the node change into a separate PR, leaving just the first two items in this PR. Review. Merge.

[bowenli]

Closing this PR.

Text only change here: #2006