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

[Maps] custom color ramp #41603

Merged
merged 13 commits into from
Aug 15, 2019
Merged

[Maps] custom color ramp #41603

merged 13 commits into from
Aug 15, 2019

Conversation

nreese
Copy link
Contributor

@nreese nreese commented Jul 19, 2019

fixes #27716

This PR adds the ability to specify custom color ramp with stop values for data-driven styling.

The color stop UI is temporary. @snide is working on a new color stop UI that will replace the one currently used in this PR.

Screen Shot 2019-08-14 at 12 39 09 PM

@nreese nreese added release_note:enhancement WIP Work in progress [Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation v8.0.0 v7.4.0 labels Jul 19, 2019
@nreese nreese requested a review from a team as a code owner July 19, 2019 19:37
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-gis

@nreese
Copy link
Contributor Author

nreese commented Jul 19, 2019

@alexfrancoeur Does the color ramp work as expected? Stops are numbers in strictly ascending order. The range is from the given stop number (inclusive) to the next stop number (exclusive).

@elasticmachine
Copy link
Contributor

💔 Build Failed

@alexfrancoeur
Copy link

@nreese If we can, I feel like we should be consistent with other ranges defined in Kibana visualizations.

Visualize:
image

TSVB:
image

Lens, Canvas and others: ?

That being said, I don't think we're consistent defining ranges anywhere. If we're getting a common color stop UI from design, I think we have some freedom here.

In the current implementation, as a new user, I'm not sure how obvious it is that you're defining a range or matching a for a single metric. For example, in your screenshot above it could easily be argued that that UI is only showing colors for when a value is 0, or 6, or 12, etc. Also, what operators are being used - >, >=, >, >= or = ? And should we consider those being customizable by the user? I personally know how it works because of your last comment but maybe we can provide some additional context / text or UX hints as to how we're defining the range. @cchaos any thoughts on how best to approach this?

I happen to like how TSVB defines this logic (screenshot above), but I'm not sure if it's more or less confusing for a new user. I think I prefer this method because you can define exactly what each range is.

@alexfrancoeur
Copy link

fwiw, I just saw what the design team was working on. I think the scale configuration is much more self explanatory with that top color bar

image

@snide
Copy link
Contributor

snide commented Jul 22, 2019

fwiw, I just saw what the design team was working on. I think the scale configuration is much more self explanatory with that top color bar

Yep. The lower part won't even be in there when we're done, and will hopefully happen all through popovers. As mentioned, the component @nreese has in now will be temporary till we get the new one in. It's gonna be a lot more technically challenging to build so we didn't want to hold up this PR.

Hopefully be able to just swap this in when we're done.

@nreese
Copy link
Contributor Author

nreese commented Aug 13, 2019

Talked with @snide and color stop UI with the color bar will not make 7.4 FF. So this PR will need to move ahead with the color stop UI as is.

I feel like we should be consistent with other ranges defined in Kibana visualizations.

@alexfrancoeur The other range definitions are defining a range. This UI is not defining ranges. The UI is defining color stops and color stops do not need to be provided in pairs.

@nreese nreese removed the WIP Work in progress label Aug 13, 2019
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@alexfrancoeur
Copy link

Talked with @snide and color stop UI with the color bar will not make 7.4 FF. So this PR will need to move ahead with the color stop UI as is.

Ah well, it'll be nice to have it when it's ready though. Do we think 7.5?

@alexfrancoeur The other range definitions are defining a range. This UI is not defining ranges. The UI is defining color stops and color stops do not need to be provided in pairs.

Makes sense to me. Honestly, any way we can introduce this type of functionality to our users will be fine for the first iteration. I still think the color stopping is a bit more obvious with the EUI component and we'll get there eventually

Copy link
Contributor

@thomasneirynck thomasneirynck left a comment

Choose a reason for hiding this comment

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

I dig it!

Some initial comments. Biggest change imo would be not using interpolation, although that may be worth a larger discussion.

return null;
if (styleDescriptor.options.useCustomColorRamp &&
(!styleDescriptor.options.customColorRamp ||
!styleDescriptor.options.customColorRamp.length)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can this (!styleDescriptor.options.customColorRamp || !styleDescriptor.options.customColorRamp.length) ever arise? I think the UX already prevents creating dysfunctional color ramps. And if it doesn't, shouldn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can this (!styleDescriptor.options.customColorRamp || !styleDescriptor.options.customColorRamp.length) ever arise

Yes. The default vector style does not set customColorRamp so when useCustomColorRamp is first set to true, customColorRamp is undefined until a color has been added with ColorStops

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@nreese
Copy link
Contributor Author

nreese commented Aug 14, 2019

I'd use the step function. https://docs.mapbox.com/mapbox-gl-js/style-spec/#expressions-step I think this would give us the behavior closest to what we have in the UX (ie. select the lowest color, when the value falls in between).

@thomasneirynck I have updated the PR to use step instead of interpolate. I like step a lot better. Thanks for suggesting. I updated the description screen shot to show an image with step instead of the interpolate example

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Contributor

@thomasneirynck thomasneirynck left a comment

Choose a reason for hiding this comment

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

very sweet, thank you! This is going to be super useful ..

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@nreese nreese merged commit c633565 into elastic:master Aug 15, 2019
nreese added a commit to nreese/kibana that referenced this pull request Aug 15, 2019
* [Maps] custom color ramp

* round value down to find center color

* do not update redux state with invalide color stops

* rename EuiColorStop to ColorStop

* remove untracked file

* fix jest tests

* review feedback

* use steps instead of interpolate

* add percy functional test to verify rendering of interpolate and step color expressions

* add padding to color stop row so add/remove icons do not overlap color select
nreese added a commit that referenced this pull request Aug 15, 2019
* [Maps] custom color ramp

* round value down to find center color

* do not update redux state with invalide color stops

* rename EuiColorStop to ColorStop

* remove untracked file

* fix jest tests

* review feedback

* use steps instead of interpolate

* add percy functional test to verify rendering of interpolate and step color expressions

* add padding to color stop row so add/remove icons do not overlap color select
@kfosburg
Copy link

Talked with @snide and color stop UI with the color bar will not make 7.4 FF. So this PR will need to move ahead with the color stop UI as is.

Ah well, it'll be nice to have it when it's ready though. Do we think 7.5?

@alexfrancoeur The other range definitions are defining a range. This UI is not defining ranges. The UI is defining color stops and color stops do not need to be provided in pairs.

Makes sense to me. Honestly, any way we can introduce this type of functionality to our users will be fine for the first iteration. I still think the color stopping is a bit more obvious with the EUI component and we'll get there eventually

Thanks for this... considering we end users had to hack CSS in previous versions to get custom color ranges anything will be great! Is there an estimate for 7.4 release?

@nreese
Copy link
Contributor Author

nreese commented Aug 17, 2019

Is there an estimate for 7.4 release?

Yes, the feature is merged into 7.x branch so should be included in the next release

@mbarretta
Copy link

@maihde this meet your needs or need algorithmic ramp like #5058 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Maps] Customize color ramps and ranges
7 participants