Color rationalized between charts

[gelim]

When looking at a dashboards, same items are attributed different colors between charts (i.e between a pie term & histogram with derived queries).
It would be a big enhancement for homogeneity and correlation between charts if the color attribution algo was the same between every elements, for instance by hashing the field's value.

Cheers,

[blysik]

+1

[bobrik]

+1

[dbeckham]

@gelim, your issue is well written and wonderfully worded, but wow, it took me a bit to confirm whether or not there was an issue about chart colors not matching the color picker in the query tool. =)

Can anyone weigh in on where this might be in the priority list? I know it has to be on there as not having the color orders match can only be a huge, accidental oversight and not intended.

[scharf]

+1
I think what would be needed is a map with terms an colors. Whenever a term appears in the UI and is associated with a color, chek it the term already has a color and use it....

[ralphm]

#1121 seems related

[bhumirjhaveri]

+1

[Bertg]

+1
I think @scharf 's suggestion is the way to go.

2 ideas to add:

• Kibana should keep a temporary color map per session; this map can be persisted/updated by the user.
• Term color matchers could also take an expression. Any term matching the expression would start from that matched colour and become lighter/darker. This way a visual correlation could be made by the user.

[rashidkpc]

Related to #1362

[quasipedia]

As per request by @rashidkpc I'm pasting here the text from #3317.

Please observe I describe a different problem that the one expressed by the OP. The "rationalisation" I call for is across time, not across views...

---

So, this is a snapshot of my view, it basically counts the number of log messages per unit of time, splitting the bars between INFO and ERROR messages. These logs refer to incoming API calls.

All nice and dandy, but then one of our partners automated jobs started, and we got inundated by requests:

See the problem? No?! I didn't either for a little while!

Kibana actually switched the colour-keys and the relative position of the bar segments (see the legend on the right) so the second graph does not read "ok, an automated job is running" but rather "OMG! Nothing is working as it should, alarm!!".

What is happening is that Kibana4 uses the colour green for the bucket with the most objects in it, and places this segment of the bar at the bottom. In our case the balance between INFO and ERROR tipped with the broken import.

I classify this as an anti-feature as it defeats the purpose of having an intuitive, visual data representation, but I don't have a killer solution to it. The best I could come up with is:

1. Allow to optionally "lock down" colours (so, kibana will keep track of what colours have been used for what values and never recycle a colour for a new value, unless the colour cache is manually flushed
2. Allow to optionally "lock down" order. This is same principle as above, but with "position in the bar" rather than colours (so, in my case, INFO would always be the bar segment on the bottom, with ERROR on top of it, regardless of maybe having 200 INFO below 20.000 ERROR.

The two could be possibly combined. As I said, none of the two is ideal: I'd be more than happy if somebody would come up with a better suggestion.

[quasipedia]

One of the problems of the solutions proposed here (including mines!) is that in any chart you typically want highly contrasting colours between adjacent areas. This is a well studied, well understood topological problem, and you can get away with just four colours (and their shades) in a 2-dimensional space.

However the nature of Kibana is such that the graph may change over time, so that colours that were previously separated by another one, gets one close to the other. Using my example above, if I had dark green for INFO, pink for WARNING and light green for ERROR, I would end up with two greens touching each other in case I don't have any WARNING in a given unit of time (=bar).

My example is kind of silly (as logging levels are usually 10 at the very max), but for terms with a wider range of possible values, and with kibana sorting bars segments according to the number of items in it, you may quickly find out that the plot becomes unreadable on a big wall mounted dashboard.

The second problem / observation is that colours carry a semantic connotation. At least in continental Europe, green equates to "OK", yellow to "WARNING", red to "DANGER". So, again: taking my example above, there is some cognitive dissonance in having a graph whose ERROR level is plotted in green. As it would be to have pink for "male" and blue for "female", or brown for "summer" and green for winter (northern hemisphere, here!), black for "day" and yellow for "night" and so on...

So, here's a third idea I'm throwing up for discussion: terms values or intervals may be manually associated to dominant colours (possibly via a tag). Using my example above, I shall be able to classify TRACE, DEBUG and INFO under the "cool" tag, WARNING under the "meh" tag and ERROR and CRITICAL under the "wtf" tag. I could then instruct Kibana to always use some shade of green for "cool" terms, some shade of yellow for "meh" terms, and some shade of red for the "wtf" tag.

Again: not a silver bullet idea, but maybe can inspire somebody to come up with something better?

[zaakiy]

+1 Mac.

Perhaps the devs could incorporate the ability to colour a term based on another field, e.g., "colour" (or "color" or whatever one chooses the field to be named).

This "colour" field could hold a HEX colour, e.g., #FFFFFF.

Zak

From: Mac Ryanmailto:[email protected]
Sent: ?Thursday?, ?12? ?March? ?2015 ?9?:?28? ?AM
To: elastic/kibanamailto:[email protected]

One of the problems of the solutions proposed here (including mines!) is that in any chart you typically want highly contrasting colours between adjacent areas. This is a well studied, well understood topological problem, and you can get away with just four colours (and their shades) in a 2-dimensional space.

However the nature of Kibana is such that the graph may change over time, so that colours that were previously separated by another one, gets one close to the other. Using my example above, if I had dark green for INFO, pink for WARNING and light green for ERROR, I would end up with two greens touching each other in case I don't have any WARNING in a given unit of time (=bar).

My example is kind of silly (as logging levels are usually 10 at the very max), but for terms with a wider range of possible values, and with kibana sorting bars segments according to the number of items in it, you may quickly find out that the plot becomes unreadable on a big wall mounted dashboard.

The second problem / observation is that colours carry a semantic connotation. At least in continental Europe, green equates to "OK", yellow to "WARNING", red to "DANGER". So, again: taking my example above, there is some cognitive dissonance in having a graph whose ERROR level is plotted in green. As it would be to have pink for "male" and blue for "female", or brown for "summer" and green for winter (northern hemisphere, here!), black for "day" and yellow for "night" and so on...

So, here's a third idea I'm throwing up for discussion: terms values or intervals may be manually associated to dominant colours (possibly via a tag). Using my example above, I shall be able to classify TRACE, DEBUG and INFO under the "cool" tag, WARNING under the "meh" tag and ERROR and CRITICAL under the "wtf" tag. I could then instruct Kibana to always use some shade of green for "cool" terms, some shade of yellow for "meh" terms, and some shade of red for the "wtf" tag.

Again: not a silver bullet idea, but maybe can inspire somebody to come up with something better?

Reply to this email directly or view it on GitHubhttps://github.com//issues/485#issuecomment-78386674.

[goerge]

Very well said @quasipedia . That's exactly the problem I had today.
+1 for a solution for this with next kibana release.

[fakeh]

For me, it's just too disconcerting to have different colours used for the same terms across different graphs. Worse when a term is clicked on one graph which then assumes a colour that previously indicated another.

+1

[PhaedrusTheGreek]

+1

Even if you could set "Sticky Color on Term" or something like that in the dashboard options

[surildhruv21]

+1
Is the locking color feature releasing with next kibana release?

[bradvido]

+1 With multiple graphs on the same dashboard, it's intuitive to thinks that the same color correlates the same data across the dash, but that's not the case at all currently. It confuses many new users.