Give home maintainers a way to use Assist without losing their place

[nielsrowinbik]

Problem statement

Assist is a modal dialog. Opening it blocks everything behind it, which is fine for quick (voice) commands, but increasingly limiting as we plan for the assistant to take on more complex (management) tasks. A maintainer who wants help while editing an automation would not be able to see the automation while talking to the assistant. Additionally, when they close the dialog, the conversation is gone, and they have to start over.

These two problems will only grow as Assist's management capabilities expand. Addressing it now, before those capabilities deepen, avoids compounding a structural problem and sets up a better foundation for what comes next.

In this opportunity, we will address the first part of the problem: the fact that whatever is being talked about is being obscured by the chat itself rather than remaining visible. Keeping the conversation around will be addressed separately in #159.

Community signals

There are no direct feature requests specifically for a non-blocking Assist surface. But the frustration that motivates it shows up in adjacent places.

A March 2026 forum post titled "Too easy to swipe away Assist window while scrolling" describes a user who keeps accidentally closing Assist while trying to read a long response, losing the conversation entirely each time. The poster explicitly proposed persistent conversation history as a solution, a workaround for the underlying problem that the dialog is fragile and disposable. This is a concrete signal that the current modal interaction model is limiting as conversations get longer and more substantive.

More broadly: the entire pattern of users turning to external tools like Claude or ChatGPT (with their persistent chat interfaces) for HA management help, rather than using Assist, reflects a preference for a surface that stays open, remembers context, and allows back-and-forth.

Scope & Boundaries

In scope

• Redesigning the Assist surface from a blocking modal dialog to a non-blocking form, such as a side panel or overlay that allows interaction with the UI behind it
• Preserving the conversation as long as it is open so that it is not lost when the maintainer switches focus (e.g. to change something in an automation)
• Ensuring the redesign works well for both control and management use cases

Not in scope

• Persistent session storage across page loads or devices, that is a separate opportunity (Make Assist remember #159)
• Any changes to the assistant's capabilities or the context-passing architecture
• Changes to the voice input or Assist pipeline behaviour

Foreseen solution

Replace the modal dialog with a collapsible side panel on desktop, a X on tablet, and a bottom sheet on mobile that allows the user to interact with the rest of the UI while the assistant is open. The conversation persists as long as the panel is open. This design is based upon established patterns around the industry.

Desktop:

Tablet (left) and mobile (right):

In terms of interaction:

• We keep the A shortcut to open this view. When the chat input is not focused, pressing A again might close it again (this is not current behaviour for the Assist modal dialog).
• Clicking the X closes the view.
• The + button will start a new conversation in the future, this will be implemented in Make Assist remember #159.
• The hamburger button will open up a menu where the user can view and manage previews conversation settings, this too will be implemented in Make Assist remember #159.

Risks & open questions

• Layout impact: A persistent side panel changes the layout of every page it can appear on. This needs to be designed carefully to avoid crowding the main interface.
• Mobile: A side panel pattern may not translate well to smaller screens. Mobile behaviour needs its own consideration.
• Voice interaction: The existing dialog has a strong association with voice input. The redesign should not degrade that experience for users who rely on it.

Appetite

Small, 2 weeks. This is a relatively small front-end change that does need careful testing around the application, but it is not a large departure in terms of functionality from the current behaviour.

Execution issues

No response

Decision log

Date	Decision	Outcome