[UX] Add embeddable preview drawer to library editors

[andreadelrio]

Summary

This is the design counterpart to #288490. The implementation proof of concept is in #288213.

#288490 proposes a preview drawer attached to library editors so users can see a live rendering while editing a saved library item from outside a dashboard. This issue tracks the UX and visual design for that experience so the design work can be assigned and tracked on its own.

What needs design

The POC establishes the plumbing (openLazySystemFlyout and EmbeddableEditorPreview) and proves the interaction is possible. The layout it produces still has open questions. Settling them matters now rather than later, because #288490 explicitly intends other embeddable types (Vega, ES|QL) to adopt the same primitives, and those editors are larger and more complex than Links and Markdown.

Observations from the POC

Preview open (Markdown)	Preview closed (Links)

1. The proportions are inverted. The preview is roughly 510px wide and full height, while the editor is roughly 320px. The read only surface dominates the surface the user is actually working in, and the Markdown toolbar is compressed as a result.
2. The preview does not look like a dashboard panel. Content renders on a bare surface with no panel framing, title, or padding, so it does not answer the main question a preview exists to answer: how will this look once it is placed on a dashboard?
3. Most of the preview is empty space. For Links and for short Markdown, the content occupies a small fraction of the drawer.
4. Two competing preview affordances. "Open preview" sits in the editor header and "Run preview" sits in the footer. The same word describes two different actions, and it is not obvious which one a user should reach for.
5. Live versus manual refresh is ambiguous. Add embeddable preview drawer to library editors #288490 states the drawer "reflects unsaved editor state in real time", but a "Run preview" button implies a manual step. These two need reconciling, and the button set follows from the answer.
6. Two close buttons. Each surface has its own dismiss control in the top right, with nothing to indicate which one closes the preview and which one ends the editing session.
7. Combined footprint. Together the two surfaces cover most of the viewport and obscure the library list behind them.
8. Placement. The preview currently sits to the left of the editor, while Add embeddable preview drawer to library editors #288490 describes the drawer as attaching to the right side of the editor. Worth deciding deliberately rather than by default.

Design questions to resolve

• What is the right size relationship between editor and preview? Should the preview be content sized, fixed, or user resizable?
• Should the preview render inside panel chrome so it matches dashboard rendering, and should it represent a realistic panel size?
• Live preview or explicit refresh? If it is live, does "Run preview" go away entirely?
• What is the responsive behavior, and what is the affordance for reopening the preview at narrow breakpoints?
• How should dismissal work: a single control for the editing session, or separate controls per surface?
• Does the pattern generalize to Vega and ES|QL, whose editors need considerably more room?
• What are the empty, loading, and error states for the preview?

Deliverables

• Mockups of the editor and preview layout at wide and narrow breakpoints
• Sizing, spacing, and panel framing specs using EUI tokens
• A recommendation on live versus manual preview, and the resulting button set
• A view on whether the pattern is safe to generalize to other embeddable types

[infra-vault-gh-plugin-prod]

Pinging @elastic/kibana-presentation (Team:Presentation)

[kibanamachine]

🤖 Automated triage

This issue has been automatically assigned the Team:SharedUX team label.

Reason

The issue is a design request for a new, reusable "embeddable preview drawer" component to be used across various library editors (Markdown, Links, potentially Vega, ES|QL). The problems described relate to general UI/UX design, such as layout, proportions, interaction affordances, and visual consistency (e.g., "dashboard panel framing"). The deliverables include mockups and specs using "EUI tokens." This aligns strongly with the SharedUX team's ownership of global UI components, layout, design system integration, and overall user experience patterns in Kibana. The explicit exclusion of the Presentation team further suggests this is a cross-cutting UI/UX concern rather than a specific dashboard feature bug.

---

_{This team label was applied automatically by the Kibana automated triage system. If incorrect, remove it and apply the correct team label. To improve future triaging accuracy, consider updating the team description file. Feedback and questions → #kibana-automated-triage Slack channel.}

[infra-vault-gh-plugin-prod]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[nickpeihl]

We might also need a Unified Search bar and at least a time picker in the preview drawer to avoid visualizations generating unbounded queries. 🤔