A job can be accepted, queued, processing, ready on the server, and still not be saved on the user’s device. Those are different facts. A single animated percentage can hide all of them.
I am the developer of Y2MP3 Convert, a browser tool for converting one permitted YouTube recording to MP3. This note explains the progress-display decisions in the project and a few rules that also apply to export jobs and media processing. It was prepared with AI assistance from the project’s current code and published constraints. It does not present a speed benchmark or an independent product review.
Separate the stages users can act on
The interface distinguishes finding the source, receiving source audio, and encoding the MP3. Waiting for an encoding slot is different from waiting for source access: the audio may already have arrived.
A useful status message answers two questions: what is known to have happened, and what is the job waiting for now? “Audio received; waiting to encode” communicates more than a progress bar stuck halfway through. It also avoids implying that all waiting is a failed download.
Unknown progress is a valid state
If the source has not reported a total size, a meaningful byte-based percentage is unavailable. The UI can still report the bytes received and show indeterminate activity. It should not convert elapsed time into invented completion.
In the project, unknown progress has its own representation. A numeric progress value appears only when the current stage has a finite measurement. Estimated totals are described as approximate. This keeps “we do not know the total yet” separate from “nothing has happened.”
The same distinction should reach accessibility text. The interface removes the current numeric ARIA value while progress is indeterminate, and describes the stage in text. An animated bar’s visual position is not evidence of a measured percentage.
Leave room for final validation
A worker finishing its main loop is not necessarily the same as a usable output file being ready. The current progress display caps an active measured stage below 100 percent. Completion comes from the job advancing to a later stage or reaching the ready state, rather than from a browser timer.
This avoids a misleading “100%” while a job is still being finalized. It also makes the terminal state responsible for declaring success.
Keep “ready” separate from “saved”
When the server has a file ready, the browser still has to transfer it. The frontend cannot infer that the user has saved the complete file merely because they clicked the download button.
The project therefore tells users to check their browser’s download progress and keep the server copy until the download finishes. A click is an interaction event, not proof of a completed transfer. This distinction matters even if ordinary conversions work: a slow or interrupted final transfer is a separate failure mode.
Explain the limits before a long wait
Published limits are part of the workflow. For this tool, they include a 4.5-hour duration ceiling, 512 MiB source audio, 700 MiB output, one job per browser session and five attempts per source connection per hour, including failed and cancelled attempts. A shared connection can share that allowance. Ready files expire after 15 minutes.
These figures describe limits, not guarantees that every source will work. Playlists, live streams, restricted videos, trimming and MP4 are outside the tool’s scope. A higher MP3 bitrate also cannot restore information missing from the original audio.
Review the awkward transitions
When reviewing a similar interface, inspect cases where the source total is unknown, an estimate changes, a job waits between stages, the user cancels, the output expires, or the final browser transfer is interrupted. Check what the screen claims at each transition.
The question I find useful is: what observation makes this message true? If the only answer is that a timer elapsed or a button was clicked, the message probably claims too much.
Top comments (0)