Should we add the ability to resize flyouts?

[JasonStoltz]

#287

There has been renewed interest from the Kibana Discover team around the idea of resizable flyouts.

While they have a specific use case in mind for Discover, we on the EUI team are considering whether or not this is a generally useful feature that we would want to add to Flyouts for use elsewhere in Kibana.

We'd like to hear from other folks if they've encountered use cases where this would add user value.

The following is a quick demo of what that would look like.

https://codesandbox.io/s/thirsty-noyce-4gxycf?file=/demo.tsx

[mdefazio]

Would this be applicable to push flyouts only?

[cee-chen]

Also think we should consider just making all push flyouts resizable.

I feel incredibly strongly against this. This would be a breaking and unexpected UX change for our consumers, and where we can we should make that opt-in vs. opt-out when it makes sense to do so (and I don't think it makes sense to do so in this case). Also, making resizable the default completely breaks the new serverless EuiCollapsibleNavBeta component, which uses a push flyout under the hood.

TBH, I think the issue here is there's some confusion about what push flyouts are intended for in terms of use-case. Right now, they're used like a de facto portal that the body adjusts to, and they don't contain all the accessibility implications I would expect when I see the word "flyout". We almost want to rename its current implementation to something more technical like EuiBodyPortal or EuiBodySidePanel or similar that EuiFlyout and EuiCollapsibleNav dogfood, and then we can have more meaningful about what a push flyout is really meant to do and be able to separate that from its technical implementation.

Also think we should consider just making all push flyouts resizable. (And perhaps also overlay ones). My thinking is that if I am in one area of the app and it is resizable, wouldn't I expect I could do this with all flyouts?

TBH I don't agree. I do not feel that "every panel can be be resizable just because this on specific one is" is an expected paradigm across the internet; more things are not resizable rather than are resizable as a general rule. And if we're running into confusion in that regard, there are other options we can take, such as adding a visual resize indicator to the flyout.

[mdefazio]

Great points @cee-chen and @JasonStoltz . Thank you. Makes sense to have this as an opt-in prop. Very much aware my suggestions were a bit brute force and short-sided... 😄

And my comment regarding the resizable paradigm also belongs specific to Kibana, and not in the EUI component. (But also agree that this should be handled with a visual affordance that the particular usage is resizable, and not as a one-solution-fits-all).

we can have more meaningful about what a push flyout is really meant to do and be able to separate that from its technical implementation

+1 Had to re-read this paragraph a few times 😄 , but I get it now.

I'd be curious to see what it looks like to have a resizable overlay flyout. Particularly how the drag handle is shown. The examples I've seen seem to suggest the overlay gets docked, and then resized. Which makes sense to be certain, but didn't know if we have an example showing the overlay being resized.

[JasonStoltz]

This would be a breaking and unexpected UX change for our consumers

I'm fine with making this opt-in. However, I don't understand how this is a breaking and unexpected change. The initial layout remains the same. Nothing is broken. If the user chooses to resize a panel and something looks off, then they just resize it back to how it was.

[JasonStoltz]

So at best, it now helps users in some way we hadn't anticipated and we are able to delight them. At worst, the layout gets weird and they resize it back. We could add an opt out for stuff like collapsible nav beta.

[davismcphee]

Very likely that I'm missing benefits of one over the other, but I'm not sure I see the (UX) difference in this example for External control for collapsible panels and a push flyout.

Other than DOM structure and hierarchy, which have some a11y implications that the EUI team has raised to us, the main difference in my mind is how things work when the window size changes.

With EuiResizableContainer panels are always percentage based and resize proportionally when the window size changes. This works well for some use cases, but falls apart when the desired effect is to have an absolute-sized panel and a fluid-sized panel. In this case it should be possible for users to resize the absolute-sized panel, but when the window size changes, only the fluid-sized panel should be adjusted, with the absolute-sized panel maintaining its current size (until a minimum is reached, at which point adjusting is required).

This pattern is ubiquitous in modern apps, but one good example would be Slack where both the left-side channels panel and the right-side thread panel can be opened and resized absolutely, but when the window size changes, only the main/center panel is adjusted, and the two side panels retain their current size. I've actually created an EuiResizableContainer-based implementation of this in Kibana, but it required a number of what I would consider hacks, and a native EUI implementation would be valuable and help accelerate adoption of more modern UI patterns IMO: https://github.com/elastic/kibana/tree/main/packages/kbn-resizable-layout.

We almost want to rename its current implementation to something more technical like EuiBodyPortal or EuiBodySidePanel or similar that EuiFlyout and EuiCollapsibleNav dogfood, and then we can have more meaningful about what a push flyout is really meant to do and be able to separate that from its technical implementation.

This framing makes a lot of sense to me. While as a consumer I'm not very concerned about the specific naming, what we're really looking for is probably best described as an EuiBodySidePanel component that simplifies adoption of the above UX pattern in a consistent way.

[cee-chen]

Technical & design considerations:

1. Performance
   • This logic adds multiple window event listens (mouseup/down, touchend/start) that will cause a full page reflow for every ms that the flyout is being dragged/resized (for push flyouts)
   • We should determine whether we need a debouncer, and what debounce ms interval feels the best without causing excessive lag on heavy pages
2. Component design
   • Will need to support both left and right side flyouts
   • Allow consumers to set a min / max resizable width on the panel (needs a new prop)
   • Having the logic detect the pixel width of the screen (which means adding another window resize listener to get the window width?) to ensure the panel cannot be sized beyond that
   • Having the above bullet point respect the existing maxWidth prop passed to flyouts, which also incidentally gets overriden to be 90vw on smaller mobile screens, so we need to calculate that as well
   • Overlay flyouts will need a different resize indicator than push flyouts
3. Maintenance and testing
   • This new functionality will obviously need testing, but IIRC Cypress doesn't support mouse dragging, so that means we can't write reliable automated tests for the most important UX of this component, and will need to do more manual QA

[mdefazio]

@cee-chen How does our current resizable container perform? Have we noticed issues when using that component? If not, what makes that one different?

[cee-chen]

(Just to clarify that the performance/page reflow considerations are primarily for push flyouts)

The difference is in the amount of content. EuiResizablePanel inherently has content limited to what's inside the panel and doesn't reflow the entire page, which a push flyout does.

Again, this is all variable as well because EUI has no idea what kind of content the consumer is rendering either in the flyout or on the rest of the page, or how beefy the user's machine is. None of the perf concerns really matter if (e.g.) the consumer is rendering a simple "Hello world" on an M2 machine.

Where it gets into perf issue territory is if the there's a ton of content in either (or both) the flyout and the rest of the page. Discover is frankly a good worst case scenario: it's rendering a data grid on the page, and EuiDataGrid has its own set of very complex width and content observers and will be trying to reposition and resize a shit ton of cells at the same time that the flyout is being resized.

[mdefazio]

The difference is in the amount of content. EuiResizablePanel inherently has content limited to what's inside the panel and doesn't reflow the entire page, which a push flyout does.

Makes sense with vertical panels. But wouldn't horizontal resizeable panels behave the same as a resizeable push flyout? See the below example from Anomaly Explorer. (I would suspect this view is also a 'worst case scenario' for performance alongside Discover).

Screenshot--2023-10-17--Anomaly.Explorer.-.Machine.Learning.-.Elastic.2.mp4

[cee-chen]

Yep, the above would also totally qualify as a worst case scenario since the panel(s) do constitute the entire page, essentially, and are relatively complex. The push flyouts will just naturally tend to always be in that ballpark (as opposed to only sometimes) since by design they change the entire page. We should take our perf improvement findings back to EuiResizablePanel if possible to get them on the same page.

[davismcphee]

This new functionality will obviously need testing, but IIRC Cypress doesn't support mouse dragging, so that means we can't write reliable automated tests for the most important UX of this component, and will need to do more manual QA

It looks like Cypress has a recipe for doing this that uses mouse events to simulate dragging: https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/testing-dom__drag-drop. I wonder if EUI could take a similar approach to testing?

Discover is frankly a good worst case scenario: it's rendering a data grid on the page, and EuiDataGrid has its own set of very complex width and content observers and will be trying to reposition and resize a shit ton of cells at the same time that the flyout is being resized.

Yup, we're definitely a good worst case scenario and would be a good point of reference for how this may be used in Kibana. EuiDataGrid especially hurts our performance, although that's a challenge for another day 😅

[JasonStoltz]

In my mind, I suspected there could be a potential value for:

1. Flyouts that have a lot of content and a user simply wants some more screen real estate to work with. In a push flyout it could be on either side of the flyout -- primary content area or flyout area.
2. Content is covered by a non-push flyout and the user needs to see a value behind it

[davismcphee]

Content is covered by a non-push flyout and the user needs to see a value behind it

This is the exact scenario we're trying to solve for 🙂 There's a strong need from users in Discover to see both main and flyout content at once, but without the flyout content obscuring any of the main view. We believe the solution is to move to a push flyout/side panel, but it's basically a non-starter for us if it can't be resized.

[mdefazio]

I'm perhaps going beyond what we hope to define here and getting too philosophical with this. But my concern is simply based around how to define (internally) how we direct teams to use these various options and for what use case/pattern.

The flyout should be used to focus the user's view on a task, or provide additional info about a selection, without losing context or a quick step back. The option for withoutOwnFocus keeps the content behind available. Right now, because it's not resizable, this is valuable only sometimes, depending on the view and the screen size, (and hopefully that value is towards the left of the screen). But if keeping the content available behind the flyout is a requirement for the user, we should then direct to use a push flyout, or a different pattern (ack that on smaller screens this changes to overlay anyway).

My concern is that if we provide the option to make this resizable for this specific need, we are diluting the purpose of the flyout in the first place.

Again, my comments are coming from a standpoint of how do we provide clear guidance on internal patterns and when to use one component vs the other.

Yes, I think there are situations when having an overlay flyout resizable makes sense. But I guess I'd also like a very clear story for explaining when and why we use a flyout, why you should make that flyout set to withoutOwnFocus, and then why you should set it to resizable.

[mdefazio]

To be clear, I think the resizable push flyout makes total sense.

[JasonStoltz]

Yes, I think there are situations when having an overlay flyout resizable makes sense. But I guess I'd also like a very clear story for explaining when and why we use a flyout, why you should make that flyout set to withoutOwnFocus, and then why you should set it to resizable

@mdefazio Can you queue this up as a patterns task?

[mdefazio]

https://github.com/elastic/eui-docs/issues/31

[CoenWarmer]

Speaking for the Observability Ai Assistant team here, we would definitely like to see this.

Sometimes the standard width we open the flyout with in Chat mode is too cramped to display chat content. At the same time being able to see the rest of the page where the flyout is opened in is beneficial to keep context. Cc @dgieselaar @boriskirov

[boriskirov]

Thanks @CoenWarmer, I'll share some of the thoughts here too: Especially in the AI Assistant world this would be helpful to have as a prop. Recently we've been exploring using the push prop for the flyout so this can stay in the context of the page where you initiate the conversation, as having everything while having a conversation sounds like a good idea (for now it's mainly a hypothesis). The problem is that the flyout has 3 sizes, and all of them are questionable in laptops and smaller screens, so having the ability to resize on our side first and then on the user side might be very interesting.

[kertal]

Let's start with the Discover use case, we made the sidebar and histogram scaleable and when evaluating push flyout style, which for expanding document totally makes sense, but in this case it should also be expandable, especially on wide screens.

Kapture.2023-10-19.at.09.38.59.mp4

Since there's not only Discover but also the Saved Search embeddable on a dashboard, where we could use the push style and also here for wide screens resizable would mean users can prevent the loss of screen estate

Kapture.2023-10-19.at.09.47.37.mp4

When users switch to ES|QL mode there's already a push flyout which would be convenient to adjust to the users need depending on the screen size:
t

tbc

[JasonStoltz]

Just to recap a bit:

Resizable push flyouts - If someone is using a push flyout, it's because users care about the main content area, and we don't want to obscure or lose focus on that content area. Often times this is useful to show additional tools that augment the main content area -- AI assistant and ES|QL mode are great examples of this. I think it's analogous to the Dev Tools in Chrome. I highly value the ability to resize Chrome Dev Tools and I would expect users of Kibana would feel the same way with some of these tools.

We already provide the ability to make width adjustments programmatically -- and resizing tools seem like the next natural evolution of this, allowing users to determine how much screen real estate is appropriate for themselves.

It's clear in my mind that there's value here and that we should do it.

Two questions remain:

• Would this be a default for all push flyouts, or an optional parameter? -- In my mind, it would be the default. However, this could be considered unexpected and breaking change, so we'd have to give that more thought.
• Would this be applicable to non-push flyouts also? - It's not clear to me that there is value here, but am open to other perspectives.

Resizable side panels vs push flyouts -- There's still some debate around what to use when. I don't want that to muddy the conversation around whether we should make push flyouts resizable or not. Longer term, guidance around what to use when would be really helpful, and I think we'll need to have this conversation particularly in context of what to use in the Discover use case.

[kertal]

Non-push flyout, I think I found a case, where I'd appreciate more screen space for the editing process, creating alerts ... here in Discover:

Kapture.2023-10-19.at.15.21.31.mp4

Imagine, having lot's of filters, a long query .. there's not much space available for this

[mdefazio]

We are currently in discussion for this to be in a page rather than a flyout. The crampedness is real for sure...but I think this should be designed to accommodate the content better by default, rather than asking the user to resize it.

Not to say we can't keep this on the table for reference. But this one may change in the (hopefully near) future.

[kertal]

I think a flyout here is fine , else users would loose context, leave Discover, wouldn't they? Or should it be a modal?

[JasonStoltz]

@mdefazio @kertal @davismcphee @CoenWarmer @boriskirov FYI, @cee-chen has added resizable flyouts to EUI: https://github.com/elastic/eui/releases/v92.0.0