One Series, Multiple Watch Orders: Designing Flexible Viewing Lists

A collection app lets someone browse a film series in release order. Later, it adds a chronological view. If “sequence number” lives directly on the film record, the second feature immediately raises a question: whose sequence does that number describe?

The useful separation is between the work, the list, and the work's membership in that list. This article proposes a conceptual model for a viewing app. It does not describe a feature currently implemented in our store.

Keep identity separate from placement

Give each work a stable identifier and its own descriptive metadata. Store a viewing list separately, with a name, an owner or editor, and a stated scope. “Main films, release order” and “Main films, story chronology” are two lists that can reference the same works.

A list entry connects one work to one list and carries its position. If the product allows one appearance per work in a list, enforce uniqueness for that pair. If repeats are a deliberate feature, give each occurrence its own entry identity instead. Make that decision explicit before implementing completion counts.

Primary keys, foreign keys, and uniqueness constraints are standard tools for expressing these relationships. PostgreSQL's constraints documentation describes their roles. The exact schema still depends on whether repeats, deleted works, and private lists are part of the product contract.

Store an ordering rule, not just a label

“Release order” is underspecified when the catalog contains several release events. A list should identify the event it uses, such as US theatrical release, and define how it treats missing dates or works without that release type.

If two works have the same relevant date, use a deterministic tie-breaker for display. Do not imply that an arbitrary tie-break establishes a meaningful historical precedence. Keep unknown dates visible as unknown, with manual placement available where the list's policy allows it.

Story chronology may require editorial judgment when a work spans multiple periods. An explicitly maintained list can be a better fit than pretending every work has one authoritative fictional timestamp. Record the rationale for ambiguous placements in editor-facing notes.

Separate a work from the edition watched

A work can have multiple cuts or physical editions. A viewing list may reference the work generally, while an optional edition preference points to a particular version. Avoid copying the whole work record just to support that preference.

For progress, decide whether “watched” means the user has seen any version or the requested version. A useful interface can distinguish “work previously watched” from “specified cut not recorded.” That is more informative than silently converting one fact into the other.

Keep viewing history outside the list

Store viewing events against the user and work, with an edition reference when known. A list position is not a durable identity for a viewing event: position four can become position five when the editor inserts a prequel.

Derive the list's completion display from those events and the list's completion policy. Switching between two lists then changes presentation without erasing or duplicating the underlying history.

For a planned rewatch, create a separate session with its own progress. Lifetime history should not mark the entire new session complete before the user starts. If repeated entries are allowed, session progress also needs to distinguish the individual occurrences.

Treat a saved place as a reference

Store a session's next entry by entry ID, not by its displayed row number. When that entry moves, the reference still identifies the intended work. When it is removed, tell the user the plan changed and offer the remaining entries rather than guessing a replacement.

For shared plans, consider pinning a session to a list revision. A newly added optional film should not silently change what the group agreed to finish. Offer an explicit update that shows additions, removals, and changed positions before adopting the revision.

Give reordering a concurrency rule

If two editors change the order, an update based on an older list revision should trigger a conflict or a deliberate merge process. Silently accepting the last full list can erase the other editor's work.

For a modest list, saving the complete new order atomically can be easier to reason about than updating positions one by one. Check that the submitted entry IDs belong to the list and match the intended membership, then apply the order against the expected revision. A larger collaborative system may need a different strategy.

Test the meaning, not only the sorting

Review a work in two lists, a missing release date, two same-day releases, an edition-specific recommendation, a repeated entry, and a session whose next item was removed. Also check that starting a rewatch leaves lifetime history intact and that adopting a new revision makes changes visible.

Our DVDWholesaleShop catalog supplies the domain context for this example; the viewing-list design is hypothetical. The broader lesson applies to reading lists, course sequences, and guided tours: stable item identity should survive changes to the path through those items.