treemap chart > modify the colour behaviour of tiles when alerts are used
1. What is your idea?
currently, colouring treemap tiles (when a block alert is set) uses a shading function around the threshold value, e.g. for threshold alert = 4 and colour red, the tiles for values 3 and 5 will get a lighter red, whereas 4 has a full red colour.
I have use cases where this behaviour is not the expected one. Instead, the expected behaviour is that each tile has a colour which is located "within" the colour "interval" of the two thresholds it belongs to.
Example:
- lower threshold = 1, colour = black
- middle threshold = 6, colour = grey
- high threshold = 10, colour = white
if a
- tile1 has a value = 4
- tile2 has a value = 7
==> i wish the colour of tile1 being like this: colour of tile 1 < colour of 6 < colour of tile 2 (from darker to lighter grey), because 1 < 4 < 6, whereas 6 < 7 < 10. Currently this is not the case.The degree of darkness should be defined by the distance of the tile's value to its two thresholds boundaries.
** edit after comment below **
Would be nice have the choice to between the following options for the colour coding in a treemap:
- Current behaviour : Fade the colour of the alert
- Behaviour described here : Do a gradient between the range the value in
- Use the actual colour of the alert or of the closest threshold value
2. Example of the current BOARD behaviour
Here an example with four thresholds used in an alert of block d.
- #FF646464 (black)
- #FF949494 (dark grey)
- #FFCDCDCD (light grey)
- #FFE8E8E8 (almost white)
The dataview and the treemap below have the same layout. both are sorted by the block block used for sorting (desc). Both have The same alert on block rank (BOARD native ranking fonction).
- the tiles surface is defined by the block block used for sorting (desc).
- the tiles colour is defined by the block rank (BOARD native ranking fonction).
I see an issue in the behaviour of the colours in the treemap, e.g. :
tile rank #4 is lighter than tiles rank #6 and rank #5
the reason is, i guess, because the value 4 is closer to 6 than to 1 and that's how currently BOARD works. This is to my mind a misleading colour management, because the reader thinks rank #6 is higher than ranks #2, #3, #4 and #5, which is not the case.
I would have wished that:
tile rank #4 has a colour between #FF646464 (black) and #FF949494 (dark grey), while closer to the second one since 4 is closer to 6 than to 1.
in other words, that colours are "ordered" within each range of thresholds.
3. What specific problem are you trying to find a solution to, or what new scenario would this idea respond to?
see example in §2, the member rank #4 has a lighter colour than member rank #6, although it is ranked higher, it should have a darker colour than rank #6.
4. What workaround have you found and used so far (if any)?
I have found no workaround, except with very few tiles where each tile has his own alert colour threshold manually defined.
§§§
Feel free to comment if criticize if it is unclear or not a good idea.