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] Allow modifying curve type for line/area series charts #94675

Merged
merged 23 commits into from Mar 26, 2021

Conversation

shahzad31
Copy link
Contributor

@shahzad31 shahzad31 commented Mar 16, 2021

Summary

Fixes: #94060

Default will be CurveType.Linear

image

@shahzad31 shahzad31 marked this pull request as ready for review March 16, 2021 10:02
@shahzad31 shahzad31 requested a review from a team March 16, 2021 10:02
@shahzad31 shahzad31 self-assigned this Mar 16, 2021
@shahzad31 shahzad31 added the Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability label Mar 16, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/uptime (Team:uptime)

@flash1293
Copy link
Contributor

flash1293 commented Mar 16, 2021

Thanks for looking into this! As this feature entered the roadmap on short notice, there are some UI/UX questions we haven't answered. Let's try to do so on this PR.

  • (probably not relevant, but I at least want to bring it up) No option is always the best - should we just always curve lines? As far as I understand this would satisfy the Obs use case. I'm not sold on it though because it makes it less fitting for exact data.
  • If we want to offer an option to the user here (basically switching between an exact chart and a chart highlighting the overall trend instead of the exact data points), do we want to offer a list of different curving algos? I'm no expert on this topic (but I guess our users aren't either), and I would expect a simple switch here - curved vs. not curved.
  • Do we really need a separate popover for this? I would vote for making this part of the "Values" popover which already houses the value labels setting for bar charts and the missing values handling. I guess in this case we would have to rename the menu (what about "Visual options" and the brush icon)?

cc @dej611 @mbondyra @MichaelMarcialis @markov00

@markov00
Copy link
Member

(probably not relevant, but I at least want to bring it up) No option is always the best - should we just always curve lines? As far as I understand this would satisfy the Obs use case. I'm not sold on it though because it makes it less fitting for exact data.

I have a different view here: I rather prefer a valid default and the option to change it, than having a valid default for most cases but no option to change it.
There is always the case where the analyst, the designer, or the final end-user wants to tweak a particular part of the visualization, if we have that ability why completely removing that from the user's hands? I think we should provide always a good set of defaults for beginner users, but we should provide enough flexibility for power users. Unfortunately, there isn't a real standard in data visualization but conventions applied to cases.

If we want to offer an option to the user here (basically switching between an exact chart and a chart highlighting the overall trend instead of the exact data points), do we want to offer a list of different curving algos? I'm no expert on this topic (but I guess our users aren't either), and I would expect a simple switch here - curved vs. not curved.

The monotonic along X is usually the curve that best represents a trend along the x-axis (like most of our use cases), without exaggerating the turns.
Screenshot 2021-03-16 at 15 08 27
Screenshot 2021-03-16 at 15 08 07
Screenshot 2021-03-16 at 15 08 34

I think it's fine for a first version to expose only the monotone x curve type, and I think is fine to hide that under a "curved" label instead of the function name, just remember to use the function name when saving it so internally we know exactly what function was used.

A nice addition can be also the stepped function, we have 3 different functions on charts for this type of interpolation

Do we really need a separate popover for this? I would vote for making this part of the "Values" popover which already houses the value labels setting for bar charts and the missing values handling. I guess in this case we would have to rename the menu (what about "Visual options" and the brush icon)?

I've the same opinion here, we should start probably populate a single menu with visual options rather then having a button for each of them

@flash1293
Copy link
Contributor

Thanks @markov00 , that's great input!

@shahzad31
Copy link
Contributor Author

I also like the brush icon idea and keeping it in the same popover. I will go ahead and make the change, if there are no objections.

@shahzad31
Copy link
Contributor Author

Update: @flash1293 Switched to curved/non-surved option and consolidated in a single popover

image

@flash1293 flash1293 added Feature:Lens Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Mar 22, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app (Team:KibanaApp)

@flash1293
Copy link
Contributor

Seems like some tests have to be adjusted, but looks pretty good.

Copy link
Contributor

@MichaelMarcialis MichaelMarcialis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm liking this direction that you've all proceeded with. Left a few comments/questions below.

label={
<>
{i18n.translate('xpack.lens.xyChart.curveStyleLabel', {
defaultMessage: 'Line style',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency with how we've previously presented most switches across Lens, can you change the EuiFormRow label to something like Curve lines (and subsequently hide the label on the EuiSwitch component via the showLabel prop)?

Comment on lines 38 to 49
<EuiIconTip
color="subdued"
content={i18n.translate('xpack.lens.xyChart.curveStyleLabelHelpText', {
defaultMessage: `By default, Lines are not curved.`,
})}
iconProps={{
className: 'eui-alignTop',
}}
position="top"
size="s"
type="questionInCircle"
/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nitpick: I'd personally be OK with removing this tooltip altogether, as I imagine the default will be evident to users during the creation process.

return (
<ToolbarPopover
title={i18n.translate('xpack.lens.shared.curveLabel', {
defaultMessage: 'Visual options',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any thoughts on changing Visual options to Appearance options?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly to me seems like Visual and Appearance both are loaded words, but i am not a native speaker :D
It could be just simply Style options? then again style could be more of a css thing. i am 50/50 on Visual and Appearance. may be slightly in favor of Visual.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No opinion on this, previously Gail would do a pass over all newly introduced wording before the release. I think we can go either way on this PR and let her check before we push it out.

})}
type="visualOptions"
groupPosition="right"
buttonDataTestSubj="lnsLegendButton"
Copy link
Member

@markov00 markov00 Mar 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this probably a wrong copy and paste or have I miss something? it was lnsValuesButton in the previous code

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, i am cleaning the code, this should get cleaned as well, with tests alongside.

@shahzad31
Copy link
Contributor Author

Does anyone have any opinion about keeping default option as Curved? i feel like that aligns with providing user with sensible defaults kibana wide. I feel like providing curved lines is a sensible default.

@shahzad31
Copy link
Contributor Author

@wylieconlon that sounds like a good idea, but i guess we can do that as an enhancement. I think curved/non curved is a good start.

@shahzad31
Copy link
Contributor Author

@flash1293 this is ready as far tests etc goes.

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks almost good to me, left two minor comments.

I agree we can add stepped in a follow-up, this is definitely a valuable increment in itself.

Edit:

I noticed one issue: On switching from a curved line chart to an area chart, the curve option gets lost. Make sure to pass the setting along in the suggestions logic:


return (
<>
{isValueLabelsEnabled ? (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: You can use isValueLabelsEnabled && syntax here to get rid of the : null

@@ -0,0 +1,44 @@
/*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might miss something, but the visual options are only used for the xy visualization, right? In that case they should be located in the xy_visualization folder as well (shared_components is meant for things used in multiple chart types)

curveType: {
types: ['number'],
help: i18n.translate('xpack.lens.xyChart.curveType.help', {
defaultMessage: 'Define how curve type is rendered for a line chart',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we pass the enum here instead of the number (and resolve it in the component using CurveType[arg])? That seems easier to follow (and I'm somehow scared of the numbers changing and nobody notices)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am not sure how enum will work here. can you give an example?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done !!

@flash1293
Copy link
Contributor

It doesn't look like the comment I added via edit was addressed: #94675 (review)

I noticed one issue: On switching from a curved line chart to an area chart, the curve option gets lost. Make sure to pass the setting along in the suggestions logic:

Switching between area/line charts and adding dimensions should preserve the "curve" option

Copy link
Contributor

@flash1293 flash1293 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comment

Copy link
Contributor

@wylieconlon wylieconlon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While testing this I found a bug: using the Area Percentage chart type with a histogram shows this set of messages:

Screen Shot 2021-03-25 at 4 57 12 PM

It seems like we do not allow fitting functions for Area Percentage, but we do allow curving now. The message is outdated.

Other than that, the code and behavior LGTM

Edit: I would still like to see the Stepped option added here, but I will open an issue for it.

@shahzad31
Copy link
Contributor Author

While testing this I found a bug: using the Area Percentage chart type with a histogram shows this set of messages:

Screen Shot 2021-03-25 at 4 57 12 PM

That was a good catch, pushed a fix for that.

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
lens 489 492 +3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
lens 928.8KB 931.3KB +2.5KB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @shahzad31

Copy link
Contributor

@wylieconlon wylieconlon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@shahzad31 shahzad31 dismissed flash1293’s stale review March 26, 2021 15:23

Discussed offline, no objections.

@shahzad31 shahzad31 merged commit b1525f0 into elastic:master Mar 26, 2021
@shahzad31 shahzad31 deleted the lens-chart-curve branch March 26, 2021 15:23
@shahzad31 shahzad31 added the auto-backport Deprecated: Automatically backport this PR after it's merged label Mar 26, 2021
kibanamachine pushed a commit to kibanamachine/kibana that referenced this pull request Mar 26, 2021
@kibanamachine
Copy link
Contributor

💚 Backport successful

7.x / #95536

This backport PR will be merged automatically after passing CI.

kibanamachine added a commit that referenced this pull request Mar 26, 2021
#95536)

Co-authored-by: Shahzad <shahzad.muhammad@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Deprecated: Automatically backport this PR after it's merged Feature:Lens release_note:enhancement Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.13.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Lens] xy chart curving options
7 participants