Terminal UX: activity indicator conflates "waiting on background tasks" with working or idle
Summary
The terminal activity indicator has two states, but users are in three. The missing one -- Claude is idle and available, but background work is still running -- is currently indistinguishable from either neighbour, and a wrong read costs the user real time.
Current behaviour
◐(cycling◓ ◑ ◒) -- Claude is working✻-- Claude is done
I'm proposing adding a third indicator
✢-- Idle, backgrond task pending
Why it matters
The three states imply different user actions, which is what makes them worth distinguishing at the indicator level rather than in prose output:
| State | What the user generally wants to do |
|---|---|
| Working | Wait for completion; interrupt if needed |
| Idle, background task pending | Engage Claude and drive other work in parallel |
| Done | End the session, review work, or queue new work |
The middle row is where the current design fails hardest: it's the only state where the user could be productively doing something with Claude, and the UI gives them no signal that they can.
Proposal
Add a third indicator: ✢ (U+2722, four teardrop-spoked asterisk).
Rationale:
- Same Dingbats block as the existing
✻(U+273B) -- any font that renders today's idle glyph renders this one, so there's no new font-coverage risk. - Reads as
✻attenuated. Fewer spokes on the same shape says "idle, with a qualifier," which is exactly the semantic relationship: this state is a variant of done, not of working. - Not a frame of the
◐◓◑◒cycle, so it can't be misread as a stalled spinner. - Static. Any animation reads as "Claude is working" and would reintroduce the ambiguity.
Alternative if a shape closer to the spinner is preferred: ◉ (U+25C9), same Geometric Shapes block as ◐, with the same coverage guarantee.
Non-glyph alternatives that would also address the gap, if a third symbol is unwanted: keep ✻ and differentiate by colour, or suffix a count (✻ 2 running).
3 Comments
A user story to explain where this comes from.
As a user when I see '*' I interpret that as claude is no longer doing anything, and needs my help. Often, I find claude is actually waiting on a process to complete, but is available to chat.
So I've engineered it so claude blocks on process completion, so instead I see ◐.
However, as a result, I've made claude less interactive. Claude isn't blocking for any good reason, it's just so I don't unnecessarily "check in".
✢ would let me differentiate the behavior. I know like in ◐ that claude has work to do, but I also know that claude is available to take on more work, discuss the problem at hand, etc.
I just wish they had a designer in their team (UX, UI... anything would be better than nothing!), I don't see any evidence that they do or that they've ever done any UX research or tests. I guess Claude is their designer and it just knows what is best for us and doesn't need to do any tests🙄
Strong +1 — the middle state is the one that costs real time.
Supporting data point from outside the process: it's also the hardest state to
infer externally. Tailing ~/.claude/projects/*.jsonl, the three states collapse
into two:
something (which may not be until it finishes)
So "no writes for N seconds" can't separate "free, something else is running"
from "hung". The process knows; the transcript doesn't. Which is a reason to
surface it in the indicator rather than expecting tooling to reconstruct it.
Your ✻ 2 running variant is also the only option that conveys more than one
background task at a time.
(I ended up building a local dashboard around reading those transcripts, which
is how I ran into this — happy to share if useful.https://github.com/zonion088-design/workflow-fishbowl)