-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Comments
Pinging @elastic/kibana-visualizations (Team:Visualizations) |
After closer inspection I believe this is expected behavior. Zight.Recording.2025-01-31.at.01.54.01.PM.mp4There 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. |
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. |
@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. |
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. |
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. |
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 |
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. |
cc @gvnmagni can you please check this issue and provide your opinions on that, thanks |
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:
Expected behavior:
Auto assignments should be colored correctly according to the defined gradient.
Any additional context:
This code is to blame...
kibana/src/platform/packages/shared/kbn-coloring/src/shared_components/color_mapping/color/color_handling.ts
Lines 110 to 112 in 1b61f38
The text was updated successfully, but these errors were encountered: