[field formatters] Unable to enter hex code for color formatter due to lack of rendering space

[mattkime]

The current field formatter color selector doesn't show the hex values -

...because they're hidden due to rendering constraints (modified via dev tools) -

The layout should be altered so the user can see and edit these values. Discovered on 7.15.2 and verified on main/8.1.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesSv)

[rushilp2311]

@mattkime Can I look into this?

[Dosant]

@rushilp2311, sure! Go ahead :)

[Dosant]

@elastic/kibana-design could you suggest a good fix here?

Things I've considered:

1. Force internal horizontal scroll:
   

2. Force switch table to mobile mode (not sure if this is allowed by EUI, maybe will need to add a prop to allow it):

[MichaelMarcialis]

@elastic/kibana-design could you suggest a good fix here?

Hi, @Dosant! I'm coming into this conversation a bit sideways, but I did have a quick thought regarding one possible way to address your color formatting spatial concerns. I've put together a quick little mockup below of that thought:

I thought it may be better to save space by taking advantage of the fact that EuiColorPicker can use a custom button to trigger the color selection popover (example in EUI docs). In this example, I'm using a slightly modified EuiButton that uses an EuiColorPickerSwatch as a child instead of text and has no minimum width. I've also applied a prepend label to the regex input, removed the containing table (since I thought the labels provided were sufficient to no longer require column headings), and suggested adding a link for folks to get some help on regex syntax.

Let me know if this suggestion helps, or if you require additional support. Thanks!

[mdefazio]

One way to save a bit more horizontal space would be to remove the switch for formatting and simply show 'Default'.
When turning on the switch, it currently just shows 'Default', which is a bit odd to me.

This would likely mean having to move the switches for the other 2 options as well. (Probably need to include 'Off / On' after the switches as well. Doesn't fully solve the issue, but may save a bit more room and solve a UX bug as well.

I def like the above suggestion to the color formatter—do we need to include the output example somewhere too?

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[Dripcoding]

hi is anyone still working on this? If not I'd like to contribute a PR as a community member.

[jughosta]

Hi @Dripcoding,

Thanks for your interest in solving this issue!
Seems like nobody is working on it at the moment. How would you approach it?

[Dripcoding]

@jughosta I would move away from using the table component and favor using a card for each format definition. @MichaelMarcialis solution looks like a good starting point.

I would try using a non-interactive card with a border to make it clear that each format definition is separate from subsequent definitions. Each card could have a row to show the inputs horizontally as in Michael's mock and another row below it to show the example of the applied color formatting and the delete icon.

Let me know if that sounds reasonable to you.

[jughosta]

@Dripcoding Sounds good! Let's maybe start with a PoC for your suggestion before committing fully. Thanks!

[MichaelMarcialis]

Note that #201676 only address the color picker portion of my suggestion. Additional suggestions such as taking the interface out of a table component, removing the example text outright, increasing the width of the regex input, etc. were not addressed. If those additional suggestions are desirable to include, please feel free to re-open.

[davismcphee]

@MichaelMarcialis This issue was originally for the hex code issue specifically, but I think these improvements are worth tracking. I opened a dedicated issue for them here: #202620.