Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Improve chat and dashboard UX as a connected investigation workspace

Aperta
  • Qualcosa non va?
#154 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
accessibility, frontend, observability

Direzione di ricerca

Inizia mappando i flussi rilevanti in ui/host/src/App.tsx, ui/host/src/dashboard.tsx, ui/host/src/mcp-app-frame.tsx, ui/apps/src/* e negli endpoint /api/agent e /api/dashboards. Procedi attraverso le fasi di delivery proposte invece di trattare il lavoro come un’unica modifica. Il lavoro è considerato completato quando sono coperti i criteri di accettazione elencati relativi a conversazione, dashboard, drill-down, aggiornamento, responsive, accessibilità e test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

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
Lingua principale
HTML
Stelle
6
Fork
0
Merge medio
2h 25m
PR unite (30g)
25

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di labstack/fanout

Tutte le issue di labstack/fanout

Issue simili

Altre issue su Accessibility

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.