-
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] Waffle visualization type #119339
[Lens] Waffle visualization type #119339
Conversation
212aef9
to
6111d8a
Compare
Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally on Safari, and I have some questions (no necessarily to be addressed in this PR):
- Can we make the legend
Show
by default when inAuto
? I see no other way to understand categories in this type of chart. Not even sure anAuto
makes sense here, rather than a simpleShow
/Hide
.
- I assumed the sorting of each waffle square goes from "big" to "small" categories from top to bottom. I see this criteria applied here:
but then changing categories I see random placement (easy to reproduce with array fields):
- legend labels have some issue when they are number-like?
String categories make a rational use of the space for the legend:
Number-like don't:
- Legend entries have a different order than the chart categories:
- When transitioning from another chart to Waffle, sometimes with a partial configuration the "too small data" warning is shown, but the chart no:
- I have some conflictual feelings for this Labels popover menu with only percent precision in it. I see it may be useful, but:
- the nature of Waffle charts tends to blur the "percentage" precision below the integer limit anyway
- and having a popover named "Labels" only for that seems overkill.
While it is still experimental I may propose to get rid of the popover altogether and keep only the Legend one? Maybe we could workout a better way to expose the same feature, in the future, in a better context?
Probably only 1, 5 and 6 can be addressed in this PR as all the others belong more to the elastic-charts
realm. What do you think about them?
warningMessages.push( | ||
<FormattedMessage | ||
id="xpack.lens.pie.smallValuesWarningMessage" | ||
defaultMessage="The received data contains too small values that can be incorrectly visualized in the {shape} chart" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KOTungseth maybe you could help out with the copy for this message? The screenshot of how it's used is here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about "The data contains small category values that could be incorrectly represented by the waffle chart. Try switching to table or treemap to better represent these values."
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
Design question: Maybe the legend should be by default at the bottom? I think it look better for this chart. CC @MichaelMarcialis |
I like the side legend by default as it can show a larger the amount of categories, compared to the bottom one. |
CC @gvnmagni on the legend question too |
Hi all! In this case I agree with @dej611 , if we keep the legend on the side by default we might prevent problems with long list of elements. If isn't there something that I'm missing I'd suggest to keep it on the side |
@elasticmachine merge upstream |
@alexwizp I've just read the comments and the features and I like to comment on them:
sortPredicate: ([, node1]: ArrayEntry, [, node2]: ArrayEntry) => {
return node2.value - node1.value;
} This will sort series by value, on both the legend and the chart. Please provide a dataset example if this sorting is not correctly applied on both legend and chart the same way.
|
I think this is what the warning is for - it explains to the user that the cardinality is too high for this chart type. It's very difficult to completely prevent the user from doing this because in a lot of situations the terms depend dynamically on the data and this case could happen on the dashboard as well. We have the same issue in a lot of places (e.g. a pie chart with hundreds of slices, a bar chart with lots of series, you name it), I'm not a fan of implementing some special handling for this chart type but rather think through this holistically in a separate project. There is no single place to prevent the user from entering a number larger than 10 to not have this happening unfortunately, it's more complicated than that. |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: cc @alexwizp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally in Safari.
The sorting behaviour is much better, but there are still some edge cases which I suspect may be an elastic-chart bug:
But that's not a blocker for this PR.
A suggestion as a follow up PR would be to have a way to not display values on legend, but just labels. Sometimes it's ok to have just a rough idea of quantities without knowing the exact amount.
Also this one is not a blocker for the PR.
@mbondyra: Good question. My initial instinct is to keep it defaulted to right alignment for two reasons: 1) it's consistent with the default legend alignment of all other visualization types in Lens, and 2) the bottom aligned legend requires scrolling when there is more than four legend items (a fact that could be missed or annoying to users when crafting their visualization). CCing @gvnmagni as well, in case he has other thoughts. |
@MichaelMarcialis yes, agree with you. Legend on the side would still be my preferred choice, it is just way more easier to handle and more consistent with all the rest. @markov00 @flash1293 agree with both of you, unfortunately. Until our users are not educated enough (or guided enough) to make the right choice I'm afraid the only thing we can do is to signal them that they are doing something that could be done better with a different chart. I'm not sure what we use typically so point out things like this (a warning? a popover message?) but probably is the best thing to do. When we have too many categories we should say to the user ("This chart is not recommended for this number of categories, you should try with a stacked barchart" or something similar) |
* [WIP][Lens] Waffle visualization type Closes: elastic#107059 * add showExtraLegend for waffle * add tests * resolved 1 and 5 * resolved 6 * add sortPredicate for waffle chart type Co-authored-by: Kibana Machine <[email protected]>
Closes: #107059
Summary
Add waffle chart as a Visualization Type to the set of partition visualizations in Lens (alongside Pie, Treemap, Moasaic). It shows a parts to whole relationship, like pie charts or treemaps, but sometimes a better option than these. It is distinct from the gridded charts in APM that show specific units and were titled waffle map.
Screens
Chart:
Options:
Small values warning: