Improve chat and dashboard UX as a connected investigation workspace

Summary

Improve Fanout's chat and dashboard experience so users can move naturally from a question, to an investigation, to a persistent operational view. The goal is to make Fanout feel like one investigation workspace rather than separate chat and dashboard surfaces.

Current UX gaps

• Chat retains only one thread locally; starting a new chat reloads the application.
• The composer is disabled during a run, with no visible Stop or Retry action.
• Streaming progress is represented by a generic “Analyzing your system” state.
• Interactive results cannot be pinned to a dashboard or opened in a focused view.
• Dashboard widgets are always draggable/removable on desktop, without an explicit edit mode or undo.
• Widget summaries are largely passive and do not support progressive drill-down.
• Dashboard freshness is ambiguous: the product says “Live,” dashboard records poll, widget data generally does not continuously refresh after success, and a manual Refresh action is also present.
• Widget configuration exists in the model but has no user-facing editor.

Proposed scope

1. Conversation management

• Add a collapsible conversation-history panel.
• Show generated title, last-updated time, and active state.
• Support opening, renaming, deleting, and searching conversations.
• Replace the full-page reload used by “New chat” with an in-app reset and focus the composer.

2. Agent run controls and recovery

• Add a visible Stop action while a run is active.
• Preserve composer text while a run is active.
• Show concise, user-facing progress such as “Checking service health” or “Reviewing traces”; do not expose protocol or tool names.
• Add Retry/regenerate for failed runs and preserve the failed prompt.
• Add copy and feedback actions to completed assistant messages.

3. Chat-to-dashboard actions

For interactive views returned in chat, add:

• Pin to dashboard
• Open full screen
• Ask about this view
• Navigate to related service, logs, or trace when applicable

When opening chat from a dashboard or widget, pass the selected dashboard, time window, namespace, service, and originating widget as context.

4. Dashboard view/edit modes

• Default dashboards to a stable view mode.
• Add an explicit “Edit layout” mode.
• Show drag handles, resize affordances, widget settings, and removal actions only in edit mode.
• Provide undo after widget removal.
• Add keyboard-accessible alternatives for reorder/resize operations.

5. Dashboard management and configuration

• Add direct create, rename, duplicate, set-default, and delete actions.
• Add widget configuration for supported fields such as service, severity, log search, and trace ID.
• Improve the empty state with “Add a view,” “Use a template,” and “Create with AI.”

6. Drill-down and freshness

• Make service, endpoint, trace, and log rows actionable.
• Preserve the active time window and namespace when drilling down.
• Define one refresh model with live refresh on/off, last-updated time, manual refresh, and an optional interval.
• Replace free-text namespace entry with selection/autocomplete when namespace data is available.
• Persist shareable filters in the dashboard URL.

7. Loading, responsive, and accessibility refinements

• Add widget-level skeletons instead of blank metric placeholders.
• Replace loader-style error states with an error card and Retry action.
• Avoid forced auto-scroll when the user has scrolled away from the latest message; show a “New response” control instead.
• Avoid announcing every streamed token through aria-live; announce meaningful progress or message completion.
• Respect reduced-motion preferences.
• Propagate the active light/dark theme into embedded MCP views.
• Reconsider the fixed product footer on small screens to reclaim workspace height.

Acceptance criteria

• Users can create and switch conversations without a page reload.
• An active run can be stopped, and failed runs can be retried without retyping the prompt.
• Chat progress communicates meaningful state without exposing internal implementation details.
• At least one interactive chat result can be pinned to a selected dashboard.
• Dashboard-originated chat includes the active dashboard and filter context.
• Widgets cannot be accidentally moved or removed in normal view mode.
• Widget removal provides an undo path.
• Widget configuration supports relevant service/log/trace filters.
• Summary rows offer drill-down actions and preserve global filters.
• Dashboard data clearly communicates whether it is live and when it was last updated.
• Loading, error, keyboard, responsive, reduced-motion, and screen-reader behavior are covered by tests.

Suggested delivery phases

1. Conversation history plus Stop/Retry controls.
2. Dashboard edit mode, widget settings, and undo.
3. Chat ↔ dashboard context and pinning.
4. Drill-downs, freshness controls, responsive polish, and accessibility validation.

Relevant implementation areas

• ui/host/src/App.tsx
• ui/host/src/dashboard.tsx
• ui/host/src/mcp-app-frame.tsx
• ui/apps/src/*
• Agent thread API under /api/agent
• Dashboard APIs under /api/dashboards

Start by mapping the relevant flows in ui/host/src/App.tsx, ui/host/src/dashboard.tsx, ui/host/src/mcp-app-frame.tsx, ui/apps/src/*, and the /api/agent and /api/dashboards endpoints. Work through the proposed delivery phases rather than treating this as one change. Done means the listed conversation, dashboard, drill-down, freshness, responsive, accessibility, and test acceptance criteria are covered.