New UI results in unclear expectations in large monorepo where the task you actually want to run (at the very end) is hidden at the very bottom about turbo

[anthonyshew]

Appreciate the feedback, folks. Have a smaller PR here to better surface the "active" tasks to the top of the list: #8632

This doesn't necessarily answer to everything shared above but a small step forward.

[wagenet]

Limitations of terminal rendering aside (a big aside, I know!) my inclination would be to have the sidebar scroll to show the current running tasks.

Thinking through use cases, there are possibly three different views I'd prefer:

• For CLI and other places we're writing to a log, you'd use the traditional view
• For jobs that have interactivity or run indefinitely the current new UI
• For local jobs that are not interactive and have a definite end, a progress-based UI which doesn't currently exist.

IIRC an early version of the new UI had a progress bar. I imagine it was removed due to space concerns.

Anyway, I want to reiterate that I love the great work you're all doing here! These are just my suggestions and not complaints.

[anthonyshew]

I've had this happen to me as well but couldn't strictly decide what would be "better"?

Trying to bake down this feedback into actionables, what heuristic would you think makes the most sense for the list? What "belongs" at the top? What "belongs" at the bottom? Are there situations where you would want those heuristics to flip?

I think I've formulated my opinion on what an improved list order would look like, but want to hear your opinion first.

[jaswilli]

Adding my experience with the new layout and the reasons I ultimately switched back to the old (streaming) output. Also want to stress that these aren't complaints but just personal preferences that made me decide the new shiny layout wasn't worth it for me:

• I immediately missed the ability to use the terminal buffer to scroll back or search.
• Since the new layout is always sending output to the terminal (via the spinner, etc.) it messed with my terminal's status indicator (screenshot below) so if I had the tab in the background I never actually knew if there was "real" output or not.

Showing the spinner that never goes away with the new layout:

[sacrosanctic]

it would benefit to actually explain the task list order, because currently, it looks random

can you also update the task list checkmark to show cache hit/miss?
miss for green check
hit for blue check

[anthonyshew]

can you also update the task list checkmark to show cache hit/miss?

This is on our minds but not sure yet how we want to implement. I'm not sure that blue/green is enough since a) color alone is not enough for colorblind users and b) blue/green doesn't inherently carry that meaning of "hit/miss". We'll be able to think of something to express this surely, just not sure what yet.

[anthonyshew]

We just shipped a refactor in 2.0.7 (#8650) that puts in-progress tasks at the top of the list, which it appears addresses the issues of the original Issue comment.

I do see other bits of feedback here in the comments (and some side-feedback in original) that are also things on our mind as we continue to iterate. If anyone feels strongly enough that you feel a separate Issue is worth creating, we're happy to take those on as well.

Thank you!

[sacrosanctic]

Would you consider letting the user provide a custom fn, I'll open an issue for this if it is viable.

({name,cacheHit,type})=>fn(...)

name: name of the task
cacheHit: boolean
status: "fail"|"success"|"running"|"long running"