search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.72k stars 8.14k forks source link

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

Open mattkime opened 2 years ago

mattkime commented 2 years ago

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

Screen Shot 2022-01-20 at 10 30 46 PM

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

Screen Shot 2022-01-20 at 10 29 00 PM

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 commented 2 years ago

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

rushilp2311 commented 2 years ago

@mattkime Can I look into this?

Dosant commented 2 years ago

@rushilp2311, sure! Go ahead :)

Dosant commented 2 years ago

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

Things I've considered:

  1. Force internal horizontal scroll: Screen Shot 2022-03-09 at 13 48 59

  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):

Screen Shot 2022-03-09 at 13 47 26

MichaelMarcialis commented 2 years ago

@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:

Frame 171

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 commented 2 years ago

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?

image
elasticmachine commented 1 year ago

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

Dripcoding commented 4 months ago

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

jughosta commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

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