[✨ Triage] microsoft/aspire#15648 by davidfowl - Dashboard: Use persistent notification pattern for command results ...

[MihuBot]

Triage for microsoft/aspire#15648.
Repo filter: area-dashboard issues.
MihuBot version: 246635.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

microsoft/aspire#15648: Dashboard: Use persistent notification pattern for command results instead of modal dialog by davidfowl
Extracted 5 search queries: Replace automatic TextVisualizerDialog modal with persistent notification center for command results, Dashboard command results opening modal unexpectedly during long-running operations, Persistent notification icon and unread badge for async command results in dashboard, Notification list to view command output on demand instead of immediate modal, Persist notifications across page navigation and integrate with existing toast system
Found 25 candidate issues

• Pull Request #6922 (Dec 2024) - Improve command notification to show result if toast has closed
  Summary: merged UI change that shows a toast when a command starts, updates it when the command finishes, and if the original toast has already closed a new toast is shown with the result. Purpose was to avoid losing command results when the transient toast times out.
  Takeaways for this issue: confirms the team has already moved away from always-opening a modal for command results and improved toast behavior. The new proposal (notification center / persistent list) is a natural next step on top of this: keep transient toasts for immediate feedback and surface results in a persistent notification list for on-demand viewing.

• Issue #10748 (Jul 2025) - Allow command results to be displayed when success
  Summary: feature request to allow successful command results (text/JSON) to be shown in the UI. Discussion pointed authors to the new interaction service (message boxes / message-bar notifications) as a potential replacement. The issue was closed after recommending the interaction service; author can reopen if unsuitable.
  Takeaways: there is precedent for wanting successful-results visibility (not only errors). Interaction service is an existing API; the dashboard should consider whether to use that for immediate user-visible messages vs. a notification center for persisted results.

• Issue #454 (Oct 2023) - Dashboard dialogs should use a splitter view instead of modal dialogs
  Summary: early discussion about moving away from modal dialogs in the dashboard toward a splitter/side-pane pattern. The immediate implementation deferred the actual splitter work and used a similar layout.
  Takeaways: there's historical momentum away from modals in the dashboard UI. The notification + on-demand visualizer approach aligns with that direction (notifications list → open visualizer only when requested, rather than forcing modal on completion).

• Pull Request #6230 (Oct 2024) - Show exception details in text visualizer dialog
  Summary: merged change that replaced hover/tooltips for exception details with an explicit clickable control that opens the TextVisualizerDialog. Discussion included UX tweaks (button sizing, menu entry) and a suggestion to add a menu item to launch the visualizer. The PR intentionally changed behavior from hover/tooltip to click-to-open.
  Takeaways: this is precedent for “show details on demand” and for reusing the TextVisualizerDialog only when the user chooses to inspect results. The new notification pattern should follow the same on-demand behavior: notifications act as a discoverable affordance to open the existing dialog.

• Pull Request #11446 (Sep 2025) - Fix text visualizer dialog max height
  Summary: merged CSS fix for the TextVisualizerDialog’s layout after the dialog logic was refactored into a reusable control.
  Takeaways: minor but relevant — if the proposed notification list will open the TextVisualizerDialog on demand, confirm dialog styling/size/behavior works well when launched from multiple contexts (notification panel vs. grid/action menu).

• Issue microsoft/vscode-dotnettools#2469 (Nov 2025) - Unusable stream of modal dialogs
  Summary: external (VS Code) bug report where repeated modal dialogs made the app unusable; maintainers fixed it and recommended using notifications instead of modal popups.
  Takeaways: real-world precedent that modal dialogs can be disruptive and catastrophic when they appear unexpectedly or in rapid succession. Reinforces the new issue’s rationale to prefer persistent notifications over automatically-opened modals for command results.

• Issue #8653 (Apr 2025) - Persistent Dashboard
  Summary: request to keep the dashboard process/data persistent between launches to retain traces/metrics/logs and improve responsiveness. Discussion pointed to related persistence work already tracked elsewhere.
  Takeaways: when designing notifications, consider the scope of persistence you want: the proposal asks for persistence across page navigation within a session — but there’s an existing conversation about longer-lived persistence. Clarify whether notifications should survive dashboard restarts or only navigation within the current session.

• Issue #7255 (Jan 2025) - Show docker pull progress in dashboard
  Summary: request to show progress for image pulls; discussion suggested adding structured progress fields (or parsing console output) and a general “progress” property on resources.
  Takeaways: shows appetite for surfacing asynchronous operation state beyond simple toasts. The notification list could be a place to surface ongoing/finished async operation state (including progress), but doing so likely requires protocol model changes (resource-level progress fields) rather than purely UI work.

Overall conclusions for triage:

• There is already work (PR #6922) to avoid losing command results when toasts close; the proposal to add a persistent notification center is a logical next step and aligns with prior UX direction (avoid auto-modals, show details on-demand per PR #6230 and #454).
• Consider integration points: the existing toast/update behavior, the interaction service (mentioned in #10748), and the TextVisualizerDialog (styling fixes in #11446). Decide whether notifications are purely a client-side UI feature, or whether you need small protocol additions (e.g., a persistent notification API or resource progress fields) to support progress and richer metadata.
• UX guidance from past discussions: prefer non-modal, on-demand access to details; provide clear success/failure status and unread indicators; avoid opening modals automatically for long-running tasks.