Files
ss-tools/specs/018-task-logging-v2/ux_reference.md
2026-02-07 12:42:32 +03:00

52 lines
2.7 KiB
Markdown

# UX Reference: Task Logging System (Separated Per-Task Logs)
**Feature Branch**: `018-task-logging-v2`
**Created**: 2026-02-07
**Status**: Draft
## 1. User Persona & Context
* **Who is the user?**: System Administrator / DevOps Engineer / Developer.
* **What is their goal?**: Monitor task execution in real-time, debug failures by isolating logs from specific components (e.g., Superset API vs. Git operations), and review historical logs of completed tasks.
* **Context**: Using the web dashboard to run migrations, backups, or LLM analysis.
## 2. The "Happy Path" Narrative
The user starts a migration task and immediately sees the log panel. As the task progresses, logs appear with clear color-coded tags indicating their source (e.g., `[superset_api]`, `[git]`). The user notices a warning from the `superset_api` source, clicks the "Source" filter, and selects "superset_api" to isolate those messages. The view instantly updates to show only API-related logs, allowing the user to quickly identify a rate-limiting warning. Once the task finishes, the user refreshes the page, and the logs are still there, fully searchable and filterable.
## 3. Interface Mockups
### UI Layout & Flow
**Screen/Component**: TaskLogPanel (within Task Details)
* **Layout**: A header with filter controls, followed by a scrollable log area.
* **Key Elements**:
* **Level Filter**: Dropdown (All, Info, Warning, Error, Debug).
* **Source Filter**: Dropdown (All, plugin, superset_api, storage, etc.).
* **Search Input**: Text field with "Search logs..." placeholder.
* **Log Area**: Monospace font, alternating row backgrounds.
* **Progress Bar**: Inline bar appearing within a log row when a component reports progress.
* **States**:
* **Default**: Shows all logs for the current task.
* **Filtering**: Log list updates as filters are changed (live for running tasks via WS).
* **Auto-scroll**: Enabled by default; a "Jump to Bottom" button appears if the user scrolls up.
## 4. The "Error" Experience
### Scenario A: Log Loading Failure
* **User Action**: Opens a historical task with thousands of logs.
* **System Response**: A small inline notification: "Failed to load full log history. [Retry]".
* **Recovery**: Clicking "Retry" re-triggers the REST API call.
### Scenario B: WebSocket Disconnect
* **System Response**: The log panel shows a "Reconnecting..." status indicator.
* **Recovery**: System automatically reconnects; once back, it fetches missing logs since the last received timestamp.
## 5. Tone & Voice
* **Style**: Technical, precise, and informative.
* **Terminology**: Use "Source" for component identification, "Level" for severity, and "Persistence" for saved logs.