[RFC] support a new layout in OSD

[raintygao]

We prepare to support a new layout in OSD, which can be a container for plugin. This layout support to dock to three regions. When docked to right or left, it should render as a sidecar, when takeover it render as a modal.

UX

Desktop

Sidecar (dockedRight or dockedLeft)

This should be rendered as a resizable panel to the right or left of the entire chrome, because there are cases where plugin and a flyout must co-exist. We may need to add sidecarLeft and sidecarRight regions that the plugin can dock to, that render as a sibling to the main center section. The plugin should be able to trigger flyouts or interact with the main context, and get context from the main window.

Modal (docked takeover)

It will cover on top when docked takeover.

In desktop mode, we want users to be able to dynamically resize the chat window in desktop.

Mobile

For mobile, it should basically work similar to a modal and be on top.

We can split the implementation into several steps.

1. Support basic layout.
2. Support resizable.
3. Support mobile view.

Tech

Overview

The body structure of OSD is composed of header and wrapper. Due to the historical DOM structure, we cannot control overall style by directly modifying the style of the body, so we should control the styles of the header and wrapper respectively.

The sidecar is resizable, when docked to right or left, the OSD body should also be resizable according to the distance of sidecar drag.

When in dock takeover mode, the sidecar will be a separate layer above OSD, and mouse event on sidecar will not affect the style of the OSD.

Implementation

As a new layout, like modal and flyout, sidecar should be added to the overlay service as a new service. At the same time, due to the need to support resizable, the size of the sidecar should be linked with the header and wrapper to achieve dynamic modification of the both size during dragging. Overlay service is already the dependency of rendering service, therefore, we should also add it as the dependency of chrome service. In core system, overlay service will be passed to chrome and rendering service when start hook execute so that this two service can get real-time sidecar config to dynamically update style to support resizable.

Configuration

SidecarConfig is defined as an interface to describe the configuration of sidecar. This common structure is as follows:

• dockedMode(type enum): left ,right,takeover current docked mode of sidecar ;
• paddingSize(type number): current padding size of sidecar, this value will be updated when dragging.
• isHidden(type boolean): Represents whether the sidecar panel is shown or hidden.

Sidecar service provides several functions as follows:

• open: Opens a sidecar panel with the given mount point inside. User can call this function to init the sidecar and open.
• setSidecarConfig: Override the default support config. User can call this function to set and update sidecar config like dockedMode.
• getSidecarConfig$(): Get an observable of the current locked state of the nav drawer.
• hide: Hide side car. It is not recommended to hide the sidecar panel directly through css, because not only need to deal with the DOM of the panel, but also to clear the size of the header and wrapper padding.So this function is provided. The same is true for show.
• show: Show side car.

[kavck]

UX for sidecar

Overview

The sidecar has 3 variations: Docked left, right, and takeover.

Dock right and Dock left mode

By default, the sidecar launches in Dock right mode. We have an indicator in header that reflects the current state. Additionally, notice that the resizable container element on the panel. When the user makes a change to the size of the panel, the panel should remember it’s new sized location.

• When the user selects the dock icon, they reveal the context menu with their dock options available
  

• If the user makes a selection like “Dock left”, then the sidecar will switch to that selected position. The dock mode icon shown in the header is updated to reflect the selected current position.
  

Dock takeover mode

When the assistant is in Dock takeover mode, the user will be able to view the details with a larger viewport. Additionally, notice that the resizable container element to the top of the panel. When the user makes a change to the size of the panel, the panel should remember it’s new sized location.

• Notice that in Dock takeover mode, the conversation elements are aligned left. This matches the layout for notebooks as well.
  

Dock takeover spacing

Note that the spacing for the Dock takeover will be 40px below the navigation bar (see screen below):

[ahopp]

@kavck, if implemented, do expect plugins or components to always respect the user's previous selected behavior (i.e., selected option within the context menu with their dock options). For example, if the user selects docked left out of the options (docked left, right, and takeover), will the components or plugins always respect that selection?

[kgcreative]

Yes. We should call this "Full-width" in the UI, even if the icon & the component use "takeover" as an implementation shorthand. The expectation is that this should save to the user's settings, and failing that, it should save to session/local storage and persist across log-ins and plugins. Part of the reason we want this as a sidecar existing outside the current layout is that this should allow for plugins to make the least amount of changes in order for this to work globally across the surface of the product. cc: @kavck

[ahopp]

Makes sense! Thanks @kgcreative

[raintygao]

Hi @kavck @kgcreative , i think there should be at most one plugin using sidecar in the dashboard page at the same time, currently it is used by chatbot. This may be similar to there can be at most one modal in the page at the same time, right?

[kgcreative]

I would agree. If we want multiple plugins to use sidecar, we will have to develop some sort of tabbed/switch interface to allow for switching between them. For now, let's start with one, and if we find a need for more we can incrementally think about it.

[raintygao]

Hi @kavck , it seems that dropdown button already contains some buttons. What is the relationship between them and the button in the above message your replied? Should it be merged?

[kgcreative]

I think that's a prototype bug. Those actions should be on the button to the left of the "close" button, where the "dock right" indicator is.

[kgcreative]

@kavck, can we aligh all icons to be together? (history, dock position, close ?)

[kavck]

@kgcreative Here's the updated icons with examples of the menu's appropriately aligned to their correct positions.

[kgcreative]

@kgcreative Here's the updated icons with examples of the menu's appropriately aligned to their correct positions.

@raintygao see Kyle's response above re: the different elements and their positioning

[raintygao]

Hi @kgcreative @kavck , this RFC has been completed and released with assistant in 2.13, thank you for your help!

In the future we will try to extract some reusable components in sidecar and support them to the OUI, will follow up in this new issue opensearch-project/oui#1257.