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] Improve color stop UI #119165

Merged
merged 114 commits into from
Jan 25, 2022
Merged

[Lens] Improve color stop UI #119165

merged 114 commits into from
Jan 25, 2022

Conversation

VladLasitsa
Copy link
Contributor

@VladLasitsa VladLasitsa commented Nov 19, 2021

Closes: #116422

Summary

This PR changes UI of color stops in Lens.

How it looks now:

image

Also was added new functionality:

  • distribute values - allow user to distribute ranges equally between max and min.
  • auto detect man and max values - allow user to auto detect man and max values for currect state of data.

Tasks:

  • add new and fix existing unit tests
  • fix existing functional tests
  • fix behavior with max/min values in heatmap
  • doesn't keep changed first range between percentage and number mods

@VladLasitsa VladLasitsa requested a review from markov00 November 19, 2021 14:16
@VladLasitsa VladLasitsa requested a review from alexwizp November 24, 2021 10:50
@VladLasitsa VladLasitsa requested a review from dej611 November 26, 2021 14:33
Copy link
Contributor

@dej611 dej611 left a comment

Choose a reason for hiding this comment

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

Had a first round of code review.
Locally I've test it and managed to break it only on the metric visualization. 👍

Test the metric visualization, which makes an intense use of the rangeMin/rangeMax props.

@@ -83,7 +83,7 @@ export function remapStopsByNewInterval(
return (controlStops || []).map(({ color, stop }) => {
return {
color,
stop: newMin + ((stop - oldMin) * newInterval) / oldInterval,
stop: newMin + ((stop - oldMin) * 100 * newInterval) / 100 / oldInterval,
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the * 100 / 100 can be removed here as there's no actual change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It help to fix some problems with correct rounding

Comment on lines 406 to 407
start: roundValue(start + (step * 100 * index) / 100),
end: roundValue(start + (step * 100 * (index + 1)) / 100),
Copy link
Contributor

Choose a reason for hiding this comment

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

Also here I think the * 100 / 100 are superfluous. The roundValue will apply already some internally

Copy link
Contributor Author

@VladLasitsa VladLasitsa Nov 30, 2021

Choose a reason for hiding this comment

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

no because firstly we should use *100 and after that * index / 100 in another case we have problem. You can check it try with that expression 11596411699.2 * 3 * 100 / 100 and 11596411699.2 * 100 * 3/ 100 you will get different results. And the second more correct.

Copy link
Contributor

Choose a reason for hiding this comment

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

But that's not a different result, it is just how float values work. But even when slightly different after the 5th digit, the roundValue will take care of it.

Copy link
Contributor Author

@VladLasitsa VladLasitsa Nov 30, 2021

Choose a reason for hiding this comment

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

sometimes I got .5999999 instead of .60000 if i use the first options, with the second always .6000.

@markov00
Copy link
Member

markov00 commented Dec 6, 2021

@VladLasitsa just a minor comment on the SVG icons: you can reduce the size by half, most of the time, if you use https://jakearchibald.github.io/svgomg/ to cleanup the SVG path: the resulting SVG is exactly the same but optimized

@VladLasitsa
Copy link
Contributor Author

@VladLasitsa just a minor comment on the SVG icons: you can reduce the size by half, most of the time, if you use https://jakearchibald.github.io/svgomg/ to cleanup the SVG path: the resulting SVG is exactly the same but optimized

Thank you @markov00, I am used this tool and decrease size of all my SVGs.

@VladLasitsa VladLasitsa requested a review from dej611 December 7, 2021 12:58
@flash1293
Copy link
Contributor

@elasticmachine merge upstream

@flash1293
Copy link
Contributor

flash1293 commented Jan 21, 2022

  • Doesn't work for numbers with a decimal point:

Screenshot 2022-01-21 at 12 19 44

Screenshot 2022-01-21 at 12 20 27

Edit: See the stuff below, it's probably related to the same issue about max not being handled correctly

@flash1293
Copy link
Contributor

flash1293 commented Jan 21, 2022

  • The thing above is also an issue for percentage-based palettes - I think it always happens if the value the percentage evaluates to has digits after the decimal point, but it's also possible to completely confuse it:

Screenshot 2022-01-21 at 12 21 36

@flash1293
Copy link
Contributor

flash1293 commented Jan 21, 2022

  • Seems like max value doesn't work:

Screenshot 2022-01-21 at 12 24 41

@flash1293
Copy link
Contributor

flash1293 commented Jan 21, 2022

  • Same for explicit max value instead of data bounds:

Screenshot 2022-01-21 at 12 25 51

@flash1293
Copy link
Contributor

flash1293 commented Jan 21, 2022

  • For metric specifically, absolute min value works but data-bounds based min value makes it always use the min value:

Screenshot 2022-01-21 at 12 32 16

Screenshot 2022-01-21 at 12 32 10

It should just behave like minus infinity

@flash1293
Copy link
Contributor

flash1293 commented Jan 21, 2022

  • When distributing equally, it rounds all of the intermediary things, but not the min (use an average metric to get values with long tails):

Screenshot 2022-01-21 at 12 37 08

@flash1293
Copy link
Contributor

flash1293 commented Jan 21, 2022

  • On selecting the "custom" palette again from the dropdown if it's custom already it does very weird things - it removes the first stop and adds an additional stop in the end (0 - 80 before, to 20 - 100 afterwards):

Kapture 2022-01-21 at 12 40 42

@flash1293
Copy link
Contributor

@VladLasitsa first two tests look unrelated flakiness, the last one is probably legit

Jest Tests #5 / metric_expression MetricChart component it renders the correct color styling for numeric value if user select auto detect max value

@VladLasitsa
Copy link
Contributor Author

@elasticmachine merge upstream

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Test Failures

  • [job] [logs] Default CI Group #18 / apis Maps endpoints maps_telemetry should return the correct telemetry values for map saved objects

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
charts 76 77 +1
lens 718 735 +17
total +18

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
charts 281 286 +5

Async chunks

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

id before after diff
charts 41.8KB 42.1KB +347.0B
expressionHeatmap 15.0KB 15.0KB +16.0B
lens 1.0MB 1.0MB +11.6KB
total +11.9KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
charts 58.0KB 58.3KB +262.0B
Unknown metric groups

API count

id before after diff
charts 314 319 +5

ESLint disabled line counts

id before after diff
lens 39 38 -1

Total ESLint disabled count

id before after diff
lens 41 40 -1

History

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

cc @VladLasitsa @alexwizp

@alexwizp alexwizp requested a review from flash1293 January 24, 2022 09:29
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.

A few nits I found but let's split them out into a follow-up issue:

  • On metric, turning off auto max value will not round the value:

Screenshot 2022-01-24 at 14 49 52

  • On metric, turning off auto min value will log a warning: `The specified value "-Infinity" cannot be parsed, or is out of range.

Besides that it looks good to me - @dej611 @stratoula could you give it another look as well?

Copy link
Contributor

@stratoula stratoula left a comment

Choose a reason for hiding this comment

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

This works great. I only found the following behavior that seems weird to me and if I am not mistaken it happens only on heatmaps.

When I am on the percentage mode and change the max value from 100 to 87 for example, this change is not depicted in the chart
image

If I change to Number, this works fine
image

@flash1293
Copy link
Contributor

Good catch @stratoula - I think we can merge in this PR and fix this problem along with my nits in a follow-up (to make sure it's safe and sound before FF)

Copy link
Contributor

@stratoula stratoula left a comment

Choose a reason for hiding this comment

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

Definitely @flash1293. I am approving as we are going to have a followup PR!

Copy link
Contributor

@dej611 dej611 left a comment

Choose a reason for hiding this comment

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

Code review only

@alexwizp alexwizp merged commit 95f2967 into elastic:main Jan 25, 2022
@MichaelMarcialis
Copy link
Contributor

Hey gang. I'm only just now seeing this PR (got a notification because it closed out the originating issue). Really great work here! I'm excited to see these enhancements added.

I know this has already been merged, but in testing after the fact, I had a handful of comments/questions. Would we be able to address the following in a follow-up PR?

  • Adding new color to the color ranges currently increments the new color's value by +25 from the last color value. Can we change this to increment by +1, per the designs (to make it less likely to create a value that is invalid in percentage mode)?

  • Can we change the wording of the Add color range button to Add color and Distribute equally button to Distribute values to better match the design (and reduce the likelihood of the buttons breaking into two lines)?

  • The percent symbol append isn't necessary for the EuiFieldText components that are set to be the current data's min or max value. Can we conditionally remove those append percent symbols in those cases?

  • It looks like the tooltips and accompanying text from the designs didn't get applied to the min, max, and pencil icon buttons. Can we add these in to match the designs, as shown here: https://www.figma.com/file/kWrDcUFIPsD6qwYO5bouju/Exploration-%2F-Version-4-%5BAwaiting-Dev%5D?node-id=114%3A121407

  • The color picker popover should support changing the opacity, as shown in the designs. Was the omission here intentional? I suppose there is an argument to be made for not supporting color opacity when the text is being colored (in table and metric type visualizations), but for all other instances, I don't believe there is a reason to exclude it.

  • Disabled color range action buttons are currently missing their suggested tooltips. Would it be possible to add these in to match the designs, as shown here: https://www.figma.com/file/kWrDcUFIPsD6qwYO5bouju/Exploration-%2F-Version-4-%5BAwaiting-Dev%5D?node-id=114%3A121018

  • Why are we warning users when they select a value that is lower than the current minimum data value or higher than the current maximum data value? Isn't that the point of applying a custom value (not being beholden to the current set of data values)? I feel like we should remove this warning, as it will likely give users the impression they're doing something wrong when they're not at all. Thoughts?

image

image

  • Can we change the Maximum value should be greater than preceding values error message to be Maximum value must be greater than preceding values. to better match designs.

  • This PR currently shows gauge color band configuration as being unable to apply a custom value to the min/max values in the range. Is this intentional? Why wouldn't we allow the users to customize these values (as shown in the designs)?

image

image

CCing @ghudgins and @flash1293, in case they have any comments on the above.

@flash1293
Copy link
Contributor

Thanks for these @MichaelMarcialis , I will pull these into a separate issue together with my comments above, we can discuss there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Lens release_note:enhancement Team:Visualizations Visualization editors, elastic-charts and infrastructure v8.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Lens] Improve color stop UI