Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color rationalized between charts #485

Closed
gelim opened this issue Sep 12, 2013 · 16 comments
Closed

Color rationalized between charts #485

gelim opened this issue Sep 12, 2013 · 16 comments

Comments

@gelim
Copy link

gelim commented Sep 12, 2013

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
Copy link

blysik commented Oct 10, 2013

+1

1 similar comment
@bobrik
Copy link

bobrik commented Oct 11, 2013

+1

@dbeckham
Copy link

@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
Copy link

scharf commented Mar 28, 2014

+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
Copy link

ralphm commented Jul 17, 2014

#1121 seems related

@bhumirjhaveri
Copy link

+1

@Bertg
Copy link

Bertg commented Dec 19, 2014

+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 rashidkpc added this to the 4.3.0 milestone Feb 23, 2015
@rashidkpc rashidkpc changed the title color attribution rationalized between charts Color rationalized between charts Feb 23, 2015
@rashidkpc
Copy link
Contributor

Related to #1362

@quasipedia
Copy link

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.

selection_005

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

selection_004

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
Copy link

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
Copy link

zaakiy commented Mar 11, 2015

+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
Copy link

goerge commented Mar 24, 2015

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

@fakeh
Copy link

fakeh commented Mar 29, 2015

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
Copy link
Contributor

+1

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

@surildhruv21
Copy link

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

@bradvido
Copy link

+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.

rashidkpc pushed a commit to rashidkpc/kibana that referenced this issue Jul 22, 2015
@rashidkpc rashidkpc added v4.2.0 and removed v4.3.0 labels Aug 14, 2015
harper-carroll pushed a commit to harper-carroll/kibana that referenced this issue Jul 11, 2016
…iverDomains

Re-add sender and receiver domain for SMTP.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

17 participants