Bug #15798
closed
Added by Eric Biagiotti about 5 years ago.
Updated 17 days ago.
Release relationship:
Auto
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
- Release changed from 20 to 60
- Target version set to Future
- Release deleted (
60)
- Target version changed from Future to Development 2024-09-25 sprint
- Target version changed from Development 2024-09-25 sprint to Development 2024-10-09 sprint
- Target version changed from Development 2024-10-09 sprint to Development 2024-10-23 sprint
- Target version changed from Development 2024-10-23 sprint to Development 2024-11-06 sprint
- Description updated (diff)
- Subject changed from [Workbench2] Cluster label colors to Cluster label colors
- Assigned To set to Lisa Knox
These are my recommendations:
- Status changed from New to In Progress
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.
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.
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.
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.
Notes:
- 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.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF