Place Action Rich UI BELOW the assistant text - or have it be configurable #21482

Classic298 · 2026-02-16T15:34:47Z

Classic298
Feb 16, 2026
Collaborator

Follow up discussion for: #21419

I am vouching for the placement of the Rich UI to be changed to BELOW the assistant message OR to be configurable if you'd want to place it above or below the assistant's message

Why?

Because

if the answer is very long, users will press the action button - seemingly nothing will happen if the placement is at the beginning of the message because it's out of view. You don't see it. You'd need to scroll all the way up to the beginning of the message
the rich UI should be placed near it's invocation point.
2.1) The Tool Rich UI is also placed exactly at it's invocation point, which is directly after the tool call.
2.2) So therefore, Action Rich UI should also be placed near the action button (which invoked the Rich ui)

@Fu-Jie additional reasons would be wanted here for vouching for this

CC @tjbck discussion created as demanded

Fu-Jie · 2026-02-16T17:24:28Z

Fu-Jie
Feb 16, 2026

@Classic298

Here are two additional reasons for supporting the "Bottom" placement, focusing on logical flow and user behavior:

Derivation Logic (Source → Artifact)
Conceptually, an Action usually performs a transformation based on the message content (e.g., visualizing data, summarizing text). The text is the source, and the iframe is the derived artifact. It is logically more coherent for the result to follow the source data, rather than preceding it.
The "Verify-Then-Act" Workflow
Users typically read the text first to verify its accuracy before deciding to trigger an Action. The workflow is linear: Read Content -> Decide -> Click Action.
Placing the UI at the top forces a regressive eye movement (jumping back to the start), breaking the linear workflow of consuming the chat.

0 replies

Classic298 · 2026-02-17T20:34:12Z

Classic298
Feb 17, 2026
Collaborator Author

@Fu-Jie we need more opinions here - if you know some people who might be interested in Rich UI and can share an opinion here that would be wanted and needed please 🙏

CC @ShirasawaSama in case you use rich ui?

7 replies

ShirasawaSama Feb 18, 2026

So is this achieved by the LLM calling OpenWebUI's tool? Does the LLM now trigger this during the conversation rather than calling the tool at the very beginning?
For example, if the LLM decides mid-conversation to call the tool to create a rich UI for the user to see, and then proceeds with the explanation after creation.

Classic298 Feb 18, 2026
Collaborator Author

Yes - if LLM calls tool mid conversation (native tool calling) and this tool uses Open WebUI's rich UI functionality (see docs) then you can have it display cool stuff

you could have the LLM call the tool with csv or json data and the tool takes the data and outputs a beautiful UI with the data in it

ShirasawaSama Feb 19, 2026

In that case, I would be more inclined to display the rich UI when the tool is actually invoked. Just like Cursor/Trae or other agents.

Classic298 Feb 19, 2026
Collaborator Author

@ShirasawaSama for tools thats already the case. its directly underneath the tool call

for actions its currently above the message - we are discussing here if we should place it below the message (near the action button) instead

ShirasawaSama Feb 19, 2026

I agree with you that in this situation, the rich UI should appear below the message.

Classic298 · 2026-02-17T20:35:20Z

Classic298
Feb 17, 2026
Collaborator Author

CC @Ithanil are you interested in Rich UI for actions in general? If yes: what do you think about the current placement ON TOP of the message instead of at bottom (where the action button is)?

3 replies

Classic298 Feb 17, 2026
Collaborator Author

CC @gaby in case you use Rich UI in actions also

Ithanil Feb 17, 2026

CC @Ithanil are you interested in Rich UI for actions in general? If yes: what do you think about the current placement ON TOP of the message instead of at bottom (where the action button is)?

Tbh I had no idea what you were talking about, but having it as seen in #21419 seems logical.

gaby Feb 19, 2026

I'm currently not using it, but it should be configurable either above/below.

pkeffect · 2026-02-17T22:50:26Z

pkeffect
Feb 17, 2026

Tossing in my two cents.

I 100% agree with @Classic298 and @Fu-Jie here—the current way the Action UI works is actually hurting the user experience, especially when we’re dealing with long-context responses.

Here’s my breakdown of why we need to change this, or at the very least, make it a configurable setting.

The Main Problem: The "Did It Work?" Factor
Right now, if I ask the AI for a complex breakdown or a long coding solution, it spits out a huge block of text. Naturally, I read down to the bottom. When I click the action button down there, the UI renders at the very top.

If I’m on a laptop/phone or scrolling through a long thread, I literally can’t see the change. It feels like the button is broken. I have to manually scroll all the way back up just to see the visualization. In UX design, this breaks the "Visibility of System Status" principle. If I click something, I should see the reaction immediately, right where my eyes are focused.

The Logical Flow: Context $\rightarrow$ Result
It just makes more sense for the artifact to live at the bottom.

Read: I read the assistant's explanation (the context).
Act: I decide I want to see the visual/artifact.
View: The artifact appears after the explanation.

Putting the result before the explanation (at the top) forces me to work backward. It’s like reading the punchline before the joke.

The Compromise: Give us a Toggle
I get that for short, chatty responses, having the UI at the top might look cleaner for some people. I don't want to ruin their workflow if they’re used to it.

My Proposal:
Can we add a simple selector in the Settings > Interface menu?

Option A (Default?): Top of Message (Current behavior)
Option B: Bottom of Message (Proposed behavior)

This way, power users who are dealing with massive outputs don't have to play the "scroll up and down" game, but we keep the flexibility for everyone else.

This seems like a solid QoL (Quality of Life) update that would make the tool feel much more responsive. +1 from me on getting this implemented!

1 reply

Classic298 Feb 17, 2026
Collaborator Author

Otherwise also, besides being a selector in the interface, have the developer decide the placement?

Giving devs the option where to place the rich ui

Fu-Jie · 2026-02-18T02:48:16Z

Fu-Jie
Feb 18, 2026

@Classic298
Adding to the points above, I’d like to speak from the perspective of a plugin developer.

1. The "Artifact" Nature & Evolution
Technically, using an iframe is an improvement over the older method of directly appending HTML to the message content. It solves the issue of cluttering the chat history with raw HTML. However, the logic remains the same: whether it's appended HTML or an embedded iframe, it is an Artifact—a result derived from the text. Instinct and intuition dictate that the result follows the cause.

2. Community Precedent
In the existing ecosystem, major data visualization plugins have naturally adopted the "bottom" placement because "top" placement feels unreasonable in practice.

Smart Mind Map (My plugin): When I developed this, I never even considered placing the mind map before the text. It would have felt completely unnatural to show a summary diagram before the user reads the content.
- Turn any text into beautiful Mind Maps
Visualize Data (Community plugins): Other popular visualization tools also strictly follow the pattern of outputting the chart/HTML after the analysis.
- Visualize Data Plugin 1
- Visualize Data Plugin 2

If we change this to the top now, it goes against the established and intuitive flow that the community has already built.

0 replies

Classic298 · 2026-02-21T20:38:16Z

Classic298
Feb 21, 2026
Collaborator Author

Something else, which i think is acceptable, is now implemented: #21698

0 replies

Uh oh!

Place Action Rich UI BELOW the assistant text - or have it be configurable #21482

Uh oh!

Classic298 Feb 16, 2026 Collaborator

Replies: 6 comments · 11 replies

Uh oh!

Uh oh!

Classic298 Feb 17, 2026 Collaborator Author

Uh oh!

Uh oh!

Classic298 Feb 18, 2026 Collaborator Author

Uh oh!

Uh oh!

Uh oh!

Classic298 Feb 19, 2026 Collaborator Author

Uh oh!

Uh oh!

Classic298 Feb 17, 2026 Collaborator Author

Uh oh!

Classic298 Feb 17, 2026 Collaborator Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Classic298 Feb 17, 2026 Collaborator Author

Uh oh!

Uh oh!

Classic298 Feb 21, 2026 Collaborator Author

Classic298
Feb 16, 2026
Collaborator

Replies: 6 comments 11 replies

Classic298
Feb 17, 2026
Collaborator Author

Classic298 Feb 18, 2026
Collaborator Author

Classic298 Feb 19, 2026
Collaborator Author

Classic298
Feb 17, 2026
Collaborator Author

Classic298 Feb 17, 2026
Collaborator Author

Classic298 Feb 17, 2026
Collaborator Author

Classic298
Feb 21, 2026
Collaborator Author