Panel overflows

[nreese]

Placing forms inside of a grid layout can cause usability problems. There are two main problems whose solutions conflict with one another.

1. Form pop-ups - Need to overflow panel and be on-top of neighbor panels.
2. Form overflowing the panel size - Need to stay within the panel.
   • Solutions
     1. scrolling - not recommended because buttons and inputs are not displayed
     2. don't allow panel to be smaller than form dimensions.
   • What happens when form size changes with interaction. For example, a multiselect shows the selected items. As more items are selected, the multiselect grows in height to show all selections.

[stacey-gammon]

Here is a visual to show how 1. Need to overflow panel and be on-top of neighbor panels is important:

It's a really bad UX with input controls to not show this pop up above everything else.

The problem is that accomplishing this is actually pretty tricky. The easiest way to do this is to override the visualize css and set the overflow to visible, along with some z-index tweaks.

The downside to this approach is that it causes the input panel overflow contents to also be visible. Causing this:

This is a bad UX also.

However, we think that scrollable forms are bad UX, so maybe if we can prevent the panel from being sized smaller than the panel contents, we could get this to work?

We'd have to do a few things:

• Ensure the height won't change in view mode. It's currently possible:

• Ensure panels can't be resized smaller than embeddable contents. We'd probably have to come up with some API to offer to the embeddable. Also not super easy.

• Also, what would happen if you have an input control on a variety of dashboards. You go edit that panel and add an extra control. If we went with this minimum height route, it would change the layout of every dashboard with that control. Maybe this is acceptable? But it could be unexpected as well.

There is possibly another option, which we haven't really explored, and is pretty hacky, which is to somehow mount just the pop up portion of the control outside the visualization.

So there are quite a few UX issues here that aren't easy to solve technically. We wanted this issue filed so we could keep track of them. Our plan right now is to submit the input controls PR with the overflow issue. Since it's experimental, we have a little extra leeway with known bugs. Then we'll submit the gridster -> react PR. This actually has a similar, but much easier to solve problem, due to the fact that the pop up is outside the embeddable.

Then we'll go back and try to find a decent fix for this control. We just want to make sure we don't end up finding something that works with gridster, just to have to rework it when react gets here.

[nreese]

Tooltips provide an example of solving the problem by moving the overflowed element out of the visualization. Tooltips are implemented with a div element attached to the body with the class vis-tooltip. When the user hovers over something that requires a tooltip, the div is made visible and the position is fixed to the mouse location.

This type of solution would be much more difficult to implement in this case since the menu must align with the input to appear as a single element.

The menu is a react component from react-select. The menu is rendered here. Interestingly, there is a fork that attempts to do what we are trying. That implementation adds an additional prop, dropdownComponent . The menu is passed as a child to the component specified by dropdownComponent.

[cchaos]

This is solved now by using EUI (which uses portals).