Problem
Export progress is easy to miss. It renders as small text plus a 96px bar tucked into the top-right of the TopBar (packages/ui/app/components/TopBar.tsx), competing for attention with the save buttons next to it. On a large display it's easy to start an export and not realise anything is happening.
This got slightly worse with the removal of the green Download button (#TBD): that button was doubling as the completion signal, and it's now a small "Exported ✓" label that lingers for EXPORT_DONE_LINGER_MS (4s) before the bar returns to idle.
Considered and rejected: a blocking modal
A centred modal over a dimmed backdrop was considered. Rejected because a video render is long, and a blocking modal says "the app is unusable until this finishes" - users should be free to browse looks or line up the next file while a render runs.
Worth revisiting only if it turns out the UI is not actually usable during an export (e.g. the GPU sidecar saturates the device and previews stall). If that's the case, a modal is the honest thing to show. Someone should check this.
Suggested direction
- Give the progress bar real presence: full-width, percentage, and elapsed/remaining if available.
- A toast on completion naming the output file, with a "Show in Finder" action in the desktop shell (
isDesktop()), which is what people actually want after a save and is something the browser build can't offer.
- Keep it non-blocking, and keep the Cancel button reachable throughout.
Not in scope
Cancel itself is done - see the export-cancel work.
Problem
Export progress is easy to miss. It renders as small text plus a 96px bar tucked into the top-right of the
TopBar(packages/ui/app/components/TopBar.tsx), competing for attention with the save buttons next to it. On a large display it's easy to start an export and not realise anything is happening.This got slightly worse with the removal of the green Download button (#TBD): that button was doubling as the completion signal, and it's now a small "Exported ✓" label that lingers for
EXPORT_DONE_LINGER_MS(4s) before the bar returns to idle.Considered and rejected: a blocking modal
A centred modal over a dimmed backdrop was considered. Rejected because a video render is long, and a blocking modal says "the app is unusable until this finishes" - users should be free to browse looks or line up the next file while a render runs.
Worth revisiting only if it turns out the UI is not actually usable during an export (e.g. the GPU sidecar saturates the device and previews stall). If that's the case, a modal is the honest thing to show. Someone should check this.
Suggested direction
isDesktop()), which is what people actually want after a save and is something the browser build can't offer.Not in scope
Cancel itself is done - see the export-cancel work.