Bug #15798
closedCluster label colors
Description
Pick at least 12 (or more) colors that have good contrast between them, following our user interface guidelines. Avoid saturated red/green colors that are similar to the colors used for status badges in order to avoid suggesting problems or success. Get feedback on the color choices.
Rewrite the algorithm that assigns colors to clusters to use the new color list, and ensure that no two clusters are assigned the same color in the same session (up to the number of distinct colors available).
Files
Updated by Peter Amstutz 4 months ago
- Release deleted (
60) - Target version changed from Future to Development 2024-09-25 sprint
Updated by Peter Amstutz 4 months ago
- Target version changed from Development 2024-09-25 sprint to Development 2024-10-09 sprint
Updated by Peter Amstutz 3 months ago
- Target version changed from Development 2024-10-09 sprint to Development 2024-10-23 sprint
Updated by Peter Amstutz 2 months ago
- Target version changed from Development 2024-10-23 sprint to Development 2024-11-06 sprint
Updated by Peter Amstutz about 2 months ago
- Subject changed from [Workbench2] Cluster label colors to Cluster label colors
Updated by Lisa Knox about 2 months ago
These are my recommendations:
Updated by Lisa Knox about 2 months ago
It just occurred to me that we could take the name of a cluster and use that to generate a hex color code, ensuring that the same clusters would always be the same color, regardless of any other factors. That's probably overkill, though.
Updated by Peter Amstutz about 2 months ago
Lisa Knox wrote in #note-13:
It just occurred to me that we could take the name of a cluster and use that to generate a hex color code, ensuring that the same clusters would always be the same color, regardless of any other factors. That's probably overkill, though.
So last I checked there is some code which chooses the color based on the cluster name with some really simplistic hashing algorithm, but it only has a set of 5 colors that it chooses from, and it doesn't check if the same color is assigned twice.
So if we can do something that makes the color choice somewhat stable, that would be nice, but just not assigning the same color twice is more important.
Updated by Peter Amstutz about 2 months ago
Also if you generate the colors on the fly you still need to check for adequate contrast/differentiation with the text and other colors which is why just having a pre-approved set seems easier.
Updated by Lisa Knox about 2 months ago
15798-cluster-label-colors @ 74edc1db8f9420ac7c4ed3b6c18e55d44a1dcbcd
developer-run-tests-services-workbench2: #1312
- ✅ All agreed upon points are implemented / addressed.
- - Anything not implemented (discovered or discussed during work) has a follow-up story.
- ✅ Code is tested and passing, both automated and manual, what manual testing was done is described
Tested with 3 clusters - ✅ New or changed UX/UX and has gotten feedback from stakeholders.
- Documentation has been updated.
na/ - ✅ Behaves appropriately at the intended scale (describe intended scale).
Intended scale is one user with any number of clusters (the cluster colors will repeat after the 12th cluster) - ✅ Considered backwards and forwards compatibility issues between client and server.
No changes - ✅ Follows our coding standards and GUI style guidelines.
- I used the colors above with a slight adjustment to the mustard yellow color (top right) to make the white text show up better.
- I opted to assign colors to clusters based on an alphabetized list of sessions generated during the auth cycle, with the best-looking (in my opinion) colors first.
- There is an edge case that happens when a user manually logs into a new session after the initial auth cycle has completed. In this case, the background color will default to a dark grey and will then be updated the next time the user is authenticated.
Updated by Peter Amstutz about 2 months ago
- Status changed from In Progress to Resolved
I went ahead and merged this (e3a50a47bb62f1387fac46ae3c34eb2abc4c19dc)