Designing a Desktop Floating Progress Panel for AI Coding Tasks

1. Background: AI Coding Enters the Multitasking Stage

Early AI coding assistants mostly worked in single rounds of question and answer. A developer asked a question, waited for a reply, and then moved on to the next step. As these tools became more capable, the execution time of a single task grew from tens of seconds to several minutes or longer. A task might involve reading a codebase, editing several files, running tests, and generating a patch, all as a chain of steps.

This change has a direct consequence: developers often have several tasks pending at once. One thread is refactoring a module, another is investigating a build failure, and a third is waiting for the user to confirm a proposed approach. The tasks are independent of each other, but each one needs a person to step in at the right moment.

Running tasks in parallel raises throughput, but it also adds management overhead. How developers can track the status of every task without interrupting their current work is a problem worth designing for on its own.

2. Core Pain Point: The Hidden Cost of Context Switching

Context switching is one of the main sources of cognitive load. When developers move between the editor, the browser, documentation, and chat tools, they must rebuild their understanding of the problem each time. Research often uses the term “re-entering flow” to describe this process, and the cost is usually measured in minutes.

In AI-assisted work, the pain points are more specific:

1. Status is not visible: Whether a task is still running or stuck waiting for input can only be checked by switching to its window.
2. Polling is expensive: Switching back frequently to check progress is itself an interruption.
3. Missed events are likely: A task may have finished or failed without anyone noticing, which delays the next steps.
4. Prioritization is hard: When several tasks need attention at once, there is no single view that shows which one to handle first.

The solution can be summed up in one sentence: move key status out of the application windows and into the developer’s peripheral vision.

3. Design: A Persistent Status Overlay

A persistent status overlay is a small window that stays on top and shows only the most important information. It does not replace the main application. Instead, it acts as a status notifier and a shortcut entry point.

3.1 Status Information Model

The overlay should show a limited and clear set of information, usually in three categories:

• Task identifier: The name of the thread or task currently being handled.
• Run state: Running, waiting for input, ready for review, failed, completed, and so on.
• Progress description: A one-line progress text, for example, “Running tests.”

The following illustrative data structure describes task status in a uniform way:

from dataclasses import dataclass
from enum import Enum
class RunState(Enum):
    IDLE = "idle"                    # Idle, not started yet
    RUNNING = "running"              # Running
    WAITING_INPUT = "waiting_input"  # Waiting for user input
    READY_FOR_REVIEW = "ready"       # Result ready for review
    FAILED = "failed"                # Execution failed
@dataclass
class TaskStatus:
    task_id: str
    title: str
    state: RunState
    progress_text: str
    updated_at: float  # Unix timestamp, used to determine whether the status has expired

A shared data structure decouples the status source from the display layer. No matter which module produces the status, the overlay only needs to consume this structure.

3.2 Status Priority

When several tasks exist at once, the overlay must decide which one to show. The common priority rules are as follows:

1. Tasks waiting for user input have the highest priority, because they block further progress.
2. Failed tasks come next and need to be investigated quickly.
3. Tasks ready for review come after that and suit a short break in the workflow.
4. Running tasks come last, since they usually need no immediate action.

PRIORITY = {
    RunState.WAITING_INPUT: 0,
    RunState.FAILED: 1,
    RunState.READY_FOR_REVIEW: 2,
    RunState.RUNNING: 3,
    RunState.IDLE: 4,
}
def pick_focus(tasks: list[TaskStatus]) -> TaskStatus | None:
    """Return the task that needs attention most. For equal priority, pick the most recently updated task."""
    if not tasks:
        return None
    return min(tasks, key=lambda t: (PRIORITY[t.state], -t.updated_at))

The overlay can show only the focus task and use a badge number to indicate how many other tasks exist. This keeps global awareness without overloading the user.

3.3 Interaction Design

Interaction should follow one principle: the user understands the state at a glance and can act with one click.

• Click to jump: Clicking the overlay returns the user to the task view in the main application, which reduces the time spent searching.
• Drag to position: Users can move the overlay anywhere on the screen, and the app remembers that position.
• Hover to expand: Hovering expands the overlay to show the full progress description. Moving the pointer away collapses it.
• Status alerts: When a task changes to “waiting for input” or “failed,” use color or a subtle animation to draw attention. Avoid continuous flashing.

4. Implementation Notes

4.1 Window Layering and Cross-App Display

The overlay must stay visible when other apps go full screen or change focus. When implementing this:

• Use the always-on-top window level that the operating system provides, rather than relying on the app’s foreground state.
• Do not take keyboard focus, so the overlay does not interrupt what the user is typing.
• Do not cover common system controls. The default position should avoid the taskbar and the notification area.
• Support multiple monitors, and fall back to the primary display automatically when a monitor is disconnected.

4.2 State Sync and Refresh Frequency

State updates do not need high-frequency pushes. For most tasks, refreshing every few hundred milliseconds to one or two seconds is enough to keep the user aware of progress. The recommended approach:

1. Push updates when the state changes, for example when a task moves from running to waiting for input.
2. Update running progress text at a lower frequency to avoid flooding the display.
3. When the overlay loses its connection, show “status unknown” instead of keeping stale information.

The updated_at field serves this purpose. A status that has not been updated for a certain period should be marked as expired, so developers do not make decisions based on old information.

4.3 Resource Usage

The overlay should use very few resources. It performs no computation of its own and handles only rendering and a small amount of event processing. Common controls include:

• Use simple frame switching for animations to avoid continuous redrawing.
• Stop the animation loop when no state changes.
• Pause refreshing when the window is hidden or minimized.

5. Presentation Layer: Limits of Anthropomorphic Characters

Some products give the overlay an anthropomorphic character to improve recognition and make it more appealing. This design has some value, but several boundaries should be respected:

1. The character serves the information: Its posture or expression should map to the real state. For example, show a prompting pose when input is needed and a warning pose on failure. The character must never change in a way that drifts from the actual task state.
2. Keep text short and controlled: Any lines the character speaks should be brief so they do not take up much attention.
3. Make it optional: Users should be able to hide the character and keep only plain text or solid color indicators.
4. Protect performance and accessibility: The character’s animation should not interfere with screen readers or cause lag on low-performance devices.

6. Privacy and Security Considerations

The overlay displays task information on screen continuously, so data exposure needs special attention:

• Redact progress text. Do not show full code snippets, keys, file paths, or personal information.
• Let users customize task titles, so sensitive project names are not shown by default.
• Provide a one-key shortcut to hide the overlay when sharing the screen or recording.
• Sync local and remote state over an encrypted channel, following the principle of least privilege.

7. Use Cases and Benefits

A persistent status overlay is most useful in these scenarios:

• Several long-running tasks run at once and need a unified progress view.
• The user often switches between documents, design files, and meetings, and needs to respond promptly to tasks waiting for input.
• In team work, someone needs to confirm quickly whether an automated task has finished.

The benefits can be assessed with a few measurable metrics:

1. The average wait time between a task finishing and someone handling it.
2. The number of times users switch back to the main app because the status is unclear.
3. The average delay before a failed task is noticed.

Record baseline data for these metrics before launch, then compare the results after release.

8. Rollout Checklist

When implementing this design, check each item on the list:

1. The state model is unified, and every task source maps to the same structure.
2. The priority rules are explicit and covered by tests.
3. The overlay supports always-on-top, dragging, click-to-jump, and hiding.
4. When a status times out, it shows as unknown rather than keeping the old value.
5. Progress text has been redacted.
6. The character or animation matches the real state and can be turned off.
7. Resource usage drops to a minimum when idle.

9. Summary

The core challenge of multitasking AI coding is the visibility of task state. A persistent status overlay reduces the cost of frequent window switching by keeping key information in peripheral vision. Implementation should center on a unified state model, clear priority rules, a restrained refresh strategy, and strict privacy boundaries. When these basics are solid, the overlay works reliably as a dependable status entry point in the developer’s workflow.