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

[Lens][ColorMapping] Auto Assignment breaks for gradient with 1 or more assignments #209164

Open
nickofthyme opened this issue Jan 31, 2025 · 9 comments
Assignees
Labels
bug Fixes for quality problems that affect the customer experience Feature:Lens Team:Visualizations Visualization editors, elastic-charts and infrastructure

Comments

@nickofthyme
Copy link
Contributor

Kibana version:

latest

Describe the bug:

When assigning a gradient palette to terms in a Lens chart using the new color mapping UI, assigning an auto assignment incorrectly caps the color loop at the number of auto assignments instead of the total assignments.

Zight.Recording.2025-01-31.at.01.14.12.PM.mp4

Steps to reproduce:

  1. Create a bar chart with a y metric and a breakdown by.
  2. Open the palette settings and select the new color mapping mode.
  3. Click the gradient option. Do not create an assignment yet.
  4. Notice the colors are correctly assigned.
  5. Add one assignment and leave it blank (i.e. auto assignment)
  6. Notice all series are colored the same, the first color.
  7. Now add another auto assignment.
  8. Notice the series are looping every other color.

Expected behavior:

Auto assignments should be colored correctly according to the defined gradient.

Any additional context:

This code is to blame...

const totalColorsIfGradient = assignments.length || notAssignedCategories.length;
const indexIfGradient =
(nonAssignedCategoryIndex - autoByOrderAssignments.length) % totalColorsIfGradient;

@nickofthyme nickofthyme added bug Fixes for quality problems that affect the customer experience Feature:Lens Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Jan 31, 2025
@nickofthyme nickofthyme self-assigned this Jan 31, 2025
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-visualizations (Team:Visualizations)

@nickofthyme
Copy link
Contributor Author

After closer inspection I believe this is expected behavior.

Zight.Recording.2025-01-31.at.01.54.01.PM.mp4

There is however a major difference in how this Color for unassigned terms behavior works between the categorical mode and gradient mode. The main difference being that the number of assignment on the gradient mode determines the extent of the color scale. So in gradient mode, if you have 2 auto assignments with 4 categories/series in the chart, the scale will start looping after the 2nd color assignment. This is not the case with categorical palettes as their colors are predetermined.

I wonder if we can improve this behavior because it really feels like a bug.

What if we had a separate input to dictate the total steps of the steps in gradient. This could have an auto mode that updates to the number of assignments as it is now, or the user can change this to the desired count.

cc: @markov00 @MichaelMarcialis

@MichaelMarcialis
Copy link
Contributor

I believe you're right, @nickofthyme. I believe it was an intentional decision, and I do agree that the inconsistency between how the categorical and gradient colors scales behave makes it feel like a bug.

For gradients, I imagine we should define a maximum number of color stops (ex. up to 10) that can be auto assigned to terms. If there are more terms then the maximum number of color stops, then we can begin to loop the colors through the gradient again, similar to how we do for the categorical color mode.

On a slightly tangential note, this is another reason why I think our previous design proposal (the one just before the current implementation) was a better overall direction. In that design, we showed all color/term assignments, regardless if the user was in auto or manual assignment mode. With that approach, we can easily show users how the automated looping is working and give them quick access to adjust them if they wish (which would automatically turn off the auto assignment mode). The current approach where we attempt to hide or obscure the color assignments for the sake of "less stuff on the page" ends up ultimately confusing users.

Image

@markov00
Copy link
Member

markov00 commented Feb 4, 2025

@MichaelMarcialis agree, the current design was also considered not only to have less assignments on the page, but was mainly focused on removing that "auto mapping" switch that was marked as "confusing" from various folks.

@nickofthyme
Copy link
Contributor Author

I imagine we should define a maximum number of color stops

So what is the proposed solution here? Auto add 10 assignments on the gradient mode? I don't love that as this would now be strange toggling between modes.

No rush to find a solution just something to think about as we move past GA.

@markov00
Copy link
Member

markov00 commented Feb 4, 2025

There is not a clear solution to that, as you described we can add an input to select the number of steps, but what are you going to do? add these steps as auto assignments or leave the assignments empty? if its empty is even a cumbersome experience because to map the last color of the gradient I need to add 10 assignments. Adding all the steps in advance is fine, but we then need to disable the remove/add button.
I believe the two modes doesn't necessary need to work the same way, probably describing somehow that in the interface could be helpful

@nickofthyme
Copy link
Contributor Author

My idea would look something like that below. It's not anywhere near polished as the assignment logic is extremely unforgiving but you get the idea. We allow linking to the total number of series and have smart defaults if unlinked to increment the total number of steps. The user is always in control.

Zight.Recording.2025-02-04.at.05.53.32.PM.mp4

@MichaelMarcialis
Copy link
Contributor

FWIW, I feel like the addition of a "Steps" input runs counter to the user's ability to add assignment rows. It's also another layer of complexity in an already complex interface.

Regardless of internal user feelings regarding the presence of an "auto mapping" toggle, simply not obscuring/hiding colors and their assigned terms to users will already go a long way to resolving this issue. Taking @nickofthyme's original video example, instead of seeing no color assignments at the start, instead the user would see all of the auto-assignments and their corresponding colors in the gradient (6 colors). Manually adding a 7th assignment would append a new assignment row and redistribute the gradient accordingly to account for a 7th color (rather than incorrectly applying a single color to all terms).

Anyway, I know this is a complex topic, so let me know if ya'll want to discuss over Zoom or would like me to put together some quick wireframes of what I'm proposing here.

@markov00
Copy link
Member

markov00 commented Mar 5, 2025

cc @gvnmagni can you please check this issue and provide your opinions on that, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Feature:Lens Team:Visualizations Visualization editors, elastic-charts and infrastructure
Projects
None yet
Development

No branches or pull requests

4 participants