[EuiResizableButton] Prop to switch between drag handle icon or simple border

[MichaelMarcialis]

Currently, the EuiResizableButton component is designed to appear like our grab and grabHorizontal icons by default. When hovering, these faux icons transition to 2px wide gray border, extending the full width/height of the parent EuiResizableContainer. When active/focus, the border color changes to blue, with a lower opacity blue emanating from the border.

Current

While these styles work fine in some circumstances, I often find myself wishing we could provide a more minimalist option in some interfaces (ex. ES|QL editor vertical resizing). Would it be possible to add a new prop to the EuiResizableButton that functions as follows in the different states?

• Default: 1px wide euiTheme.colors.lightShade border, extending the full width/height of the parent EuiResizableContainer.
• Hover: Border width transitions to 2px and color transitions to euiTheme.colors.mediumShade.
• Active/Focus: Border color transitions to euiTheme.colors.primary.

Here's a quick mockup of what I was thinking. Thoughts?

Default

Hover

Active/Focus

CCing @cee-chen, as we chatted about this in the last Figma EUI library working group meeting.

[cee-chen]

@MichaelMarcialis how do you feel about keeping the slight blue tint/halo around the border in active/focus state? i.e.,

I personally kind of like it for greater visibility. WDYT?

[JasonStoltz]

This is not a strict objection, just adding some food for thought.

If we add this as an optional property, do we lose some important consistency? Users may have established a recognition of the grab handle meaning that things can be resized. Do we lose that by allowing this option?

Likewise, if we do add this option, what is the guidance that we provide that goes along with this? When should we be using the minimal option vs the regular option.

[cee-chen]

If we add this as an optional property, do we lose some important consistency?

Discover has already their own resize UI overriding/hiding the grab handle, so this is basically just bringing EUI to parity with production 🤷

Likewise, if we do add this option, what is the guidance that we provide that goes along with this? When should we be using the minimal option vs the regular option.

++, agreed some firmer guidance on this would be nice. My best guess is to opt out of the drag handle when there's a lot of other busy things going on on the page, or the resize behavior is "nice to have" but not a primary focus.

[MichaelMarcialis]

@JasonStoltz, @cee-chen: My apologies for the late reply to your comments. Some quick responses below:

If we add this as an optional property, do we lose some important consistency? Users may have established a recognition of the grab handle meaning that things can be resized. Do we lose that by allowing this option?

Discover has already their own resize UI overriding/hiding the grab handle, so this is basically just bringing EUI to parity with production 🤷

I don't disagree with you that this has the potential to create some level of inconsistency, where some instances of a EuiResizableButton are using the faux icon approach and others are using this new border approach. That said, I've personally struggled and ultimately ended up disliking ever having to use the EuiResizableContainer because there was no alternative to the current faux icon approach. When having to work within tight spaces and/or in close proximity to very robust interfaces, having to accommodate for the appearance of that icon can prove very troublesome. I imagine I'm not the only designer to feel that pain. A perfect example is the resizable button that appears at the bottom of the unified search interface (where its appearance almost looks like a visual bug).

That said, there are probably some instances in Kibana where the current faux icon approach is perfectly acceptable and perhaps even desirable. If that assumption is right, then I think keeping it as the default makes sense despite the consistency concerns (for the sake of avoiding breaking or unwanted changes). However, if that assumption is incorrect, I'd be open to a conversation to replace the faux icon approach altogether.

Likewise, if we do add this option, what is the guidance that we provide that goes along with this? When should we be using the minimal option vs the regular option.

++, agreed some firmer guidance on this would be nice. My best guess is to opt out of the drag handle when there's a lot of other busy things going on on the page, or the resize behavior is "nice to have" but not a primary focus.

@cee-chen's guidance is pretty much exactly what I had in mind. If the experience doesn't demand resizing as an imperative, and the resizable button placement is in tight quarters or in close proximity to an already busy interface, then perhaps this option may make more sense.

I suppose if we wanted to get more granular with it, we could also add more specific guidance such as "both ends of the border version must either 1) touch another border on the opposing axis in your interface or 2) touch the edge of the viewport (to avoid cases of resizable borders floating in space)", but I'm not sure if we require that level of hand-holding.

[JasonStoltz]

That makes sense to me @MichaelMarcialis, thank you for the detailed reply.