EuiColorStops component

[nreese]

Add EuiColorStops component. The Maps application will use this component to allow users to specify custom color ramps with ranges.

Checklist

• This was checked in mobile
• This was checked in IE11
• This was checked in dark mode
• Any props added have proper autodocs
• Documentation examples were added
• A changelog entry exists and is marked appropriately
• This was checked for breaking changes and labeled appropriately
• Jest tests were updated or added to match the most common scenarios
• This was checked against keyboard-only and screenreader scenarios
• [ ] This required updates to Framer X components

[cchaos]

Thanks @nreese. Give me some time to think over the design of this component. It seems we can most likely condense it into a single input.

I've also added the checklist back into the summary of the PR. It's vital that new components get checked against this. I also see you're lacking any doc description text. Can you add some?

[snide]

Off hand my guess is we'd want to make something that renders the gradient and handles the color picker in a popover.

[nreese]

Users will need to be able to define the color stop for each color.

Think of the use case were you want to show traffic colors. Red for really slow traffic, yellow for slow traffic and green for fast traffic. Just defining a gradient is not enough. Users must have the ability to define at which numerical value the color will switch from one to the next

[snide]

@nreese will you know the range ahead of time? I guess it could be anything huh, even data that's not yet in the set. Hmm.

[nreese]

will you know the range ahead of time?

This input is envisioned for cases where you know the range ahead of time. Use cases like speeds, file sizes, temperature, weights and such that fall into a known range and want to styled by that range

[nreese]

Think of another use case where you are sizing icons based on upload size. You most likely do not want to style based on relative size but want to style based on fixed size ranges so items on the map that are large mean the same thing regardless of the data set. For example, its really confusing to see a large icon symbolize 100MB and then zoom the map to a different location and see the same large icon symbolize 5MB (just because its the largest out of the data set). It would be better if the size is consistent for a defined range regardless of whats in the data set and how the value is relative to other values in the data set.

[snide]

I guess I'm just wondering if you'd know the min / max. If so you might be able to do something like this. I guess there's nothing stoping you from also just starting with two stops and making them set the values.

Very dirty mock

[nreese]

That would work. The user just needs to be able to define as many stop/color pairs as needed to describe the data set.

I think there is some value in being able to see all of the stop numerical values one a single screen so users can see how data flows through the stops and is able to compare and contrast each stop against the others.

[cchaos]

I think there is some value in being able to see all of the stop numerical values one a single screen so users can see how data flows through the stops and is able to compare and contrast each stop against the others.

Shouldn't the legend take care of that?

[cchaos]

The other question though, is it actually creating a gradient or are these hard stops, or can it be either?

Hard stops as in the case of your stoplight, solid Green from 0 - 20, then solid Yellow from 21 - 40 etc...

[snide]

I think there is some value in being able to see all of the stop numerical values one a single screen so users can see how data flows through the stops and is able to compare and contrast each stop against the others.

Yeah, it might just be where our heads are at right now, but we're trying to make things as minimal as possible from a footprint perspective with anything that might sit in an edit panel since you folks love to add stuff and those side controls get super scrolly! This one seems like something we'd only use in an edit panel, and it's a pretty common layout for designery tools. Prolly hardest bit would be figuring out some of the accessibility. You'd likely need a tab + enter to make a new stop before tabbing to the individual stops. We'll chat it up in our design meeting today.

[snide]

Did a small sess on this. Mock above would work (needs cleanup). Feature wize it needs to include the hex value and give some way to delete the stop. Accessibility will be challenging.

[ghost]

Hi @nreese, we have found your signature in our records, but it seems like you have signed with a different e-mail than the one used in your Git commit. Can you please add both of these e-mails into your Github profile (they can be hidden), so we can match your e-mails to your Github profile?

[ryankeairns]

@thompsongl @snide
Here are some initial mockups and accessibility notes based on our conversation.

Point popovers

---

The popover contains a text input for the stop value, a delete button, the color picker, and an input for the hex value. In reality, there would never be two popovers open at the same time, but the screenshot below includes an example of a popover with a validation error.

Note that this uses the new compressed inputs.

Keyboard navigation

---

1. ‘Tab’ to component to place focus; a subsequent tab moves to next sibling element, bypassing the guts of the EuiColorStop component

2. While the component is focused, ‘Arrow up/down’ will cycle through existing stops; ‘Enter’ will create a new stop at the midpoint and open the popover (as pictured above); ‘Escape’ places focus back on the parent color stop component.

3. While a stop is focused, ‘Enter’ will open the popover and focus on the ‘Stop value’ text input; tabbing will cycle through the main elements (stop input, delete button, color picker, or hex input).

4. While the color picker focused, ‘Enter’ will place focus on the color field and follow existing keyboard navigation for this component; ‘Escape’ will place focus back on parent color picker element in the normal flow of the popover content (i.e. subsequent tab goes to hex input).

5. While any first level child is selected (stop input, delete button, color picker, or hex input), ‘Escape’ will close the popover and retain focus on parent stop point;

At this point, the user can use the up/down arrows to cycle through the stops or use 'Tab' to move past the EuiColorStops component and on to the next sibling element in the DOM.

[thompsongl]

@ryankeairns Nice!

I'm going to move your spec to a new issue and copy over relevant discussion. This PR will be used as prior art and may have some cherry-pick-able code, but we've ultimately decided to go in a different functional direction.