This is a public-interface design note. It does not claim knowledge of private source code, codecs, queues, storage, or performance. A visible workflow is still enough to describe the states a frontend should make legible.
Start with the user-visible state
The public Video Trimmer page presents a local browser workflow: choose a file, move range handles, then export. A user should be able to answer three questions at any point: which file is selected, what range will remain, and whether an export is ready.
Model the trim separately from the media
type TrimRange = { startMs: number; endMs: number };
type ClipDraft = { fileName: string; durationMs: number; range: TrimRange };
type ExportState = 'idle' | 'editing' | 'exporting' | 'ready' | 'failed';
These are proposed contracts, not observed implementation details. Separating range from fileName matters because a handle movement should be reviewable without implying that the source file changed.
Test the edges people actually touch
| Case | Expected behavior |
|---|---|
| Start at zero | The left handle remains selectable and its value is announced. |
| End at duration | The final frame can be retained without an off-by-one surprise. |
| Handles meet | Export is blocked or explains the minimum allowed range. |
| Keyboard adjustment | A focused handle moves predictably with a visible value. |
| Failed export | The UI preserves the chosen range and offers a safe retry. |
Keep private claims out of the test plan
The site says work happens in the browser and that files are not uploaded. That is a user-facing promise worth verifying with a documented network test in the actual product, not an assumption a UI review can prove. Likewise, supported formats and export behavior need browser-level test coverage.
A useful acceptance question
Can a person recover after accidentally moving one handle? If the answer is clear, the interface has probably exposed enough state. Good trimming UX is not a fancy timeline; it is a reversible, readable decision about what stays.
Define invariants before styling the timeline
The central invariant is 0 <= startMs < endMs <= durationMs. It affects dragging, numeric entry, keyboard control, labels, validation, and export enablement. Put it in one domain function instead of reproducing a slightly different rule in each component.
function isValidRange(range: TrimRange, durationMs: number) {
return range.startMs >= 0 && range.startMs < range.endMs && range.endMs <= durationMs;
}
The function does not decide a product policy such as minimum clip length. That policy belongs in an explicit parameter that a person can understand.
Separate preview time from committed time
While a pointer moves, a UI may display an optimistic preview value. On release, it can commit a rounded value and announce it. This prevents a screen-reader label, thumbnail, and export payload from silently disagreeing. Cancellation becomes testable too: Escape should restore the committed range, not a half-dragged value.
Automated tests should cover ordering, focus, error recovery, and responsive labels. A human should still check touch targets and whether duration labels make sense for a long file.
Top comments (0)