A product comparison becomes misleading when an empty field turns into a cross mark. In a DVD and Blu-ray catalog, an unlisted commentary track might mean the edition has no commentary. It might also mean nobody has checked the package yet.
Those states lead to different buying decisions. A useful comparison feature needs to preserve the difference from data entry through filtering, presentation, and later corrections. This article sketches that design without assuming a particular database or frontend framework.
Separate the feature value from the evidence state
Consider a feature such as “includes an audio commentary.” Its value can be present, absent, or unknown. Separately, record whether the claim has been reviewed, when it was reviewed, and what evidence supports it.
“Present but awaiting review” is not the same as “verified present.” Similarly, “unknown” is not a cautious spelling of “absent.” A single boolean cannot express the distinctions this interface needs.
A practical record can carry an edition identifier, feature identifier, asserted value, review status, evidence reference, and checked date. Define which combinations are valid. A claim marked verified should require supporting evidence; an unknown value should not silently become a verified negative during an import.
Keep confidence and truth separate as well. An editor's confidence score may help prioritize review, but a high score is not a substitute for knowing which edition an assertion describes.
Attach claims to the exact edition
A film title is usually too broad a key for edition-level features. Different territories, distributors, packages, or cuts may have different contents. Establish a stable internal edition identifier and store external identifiers, such as catalog numbers, where available.
Do not copy a feature to every edition of the same film just because one release has it. Even apparently matching packages need evidence before their feature records are merged.
Suppose a fictional Edition A has a confirmed commentary, Edition B has a confirmed absence, and Edition C has not been checked. These are three different comparison outcomes. The example is illustrative; it does not describe any particular commercial release.
Make the comparison say what is known
Render the three outcomes in plain text: “Included,” “Not included,” and “Not confirmed.” Icons can support those labels, but the icon should not carry the meaning alone. Include a legend if the table contains additional review states.
A second line can show “Checked on [date]” for reviewed claims or “Awaiting review” for provisional ones. Keep evidence details available near the value, for example through a details control, rather than requiring the user to find a separate explanation page.
Reserve “Not applicable” for a genuine applicability rule. It should not become a convenient replacement for missing data. If that fourth state is needed, document why the feature cannot apply and keep it distinct in storage and display.
Define filtering before adding a checkbox
What should “Has commentary” mean? For a strict filter, include only verified positive claims. Do not include unknown records merely because they have not been ruled out.
If the product team wants broader discovery, offer an explicit option to include unconfirmed candidates. Show how many additional results that introduces and label them individually. A user should not have to guess which interpretation the filter uses.
The inverse filter also needs care. “No commentary” should match verified negative claims, not every record that fails the positive filter. Unknown records belong in neither strict set.
Sorting by feature completeness should count confirmed features separately from missing evidence. Otherwise, a well-documented edition can look worse than a sparsely described one simply because the system penalizes explicit negatives while ignoring blanks.
Show conflicts instead of quietly overwriting them
Two sources can disagree. Preserve the competing assertions and flag the feature for review rather than allowing the most recent import to overwrite a verified record without explanation.
An editor resolving the conflict should record the selected value and the reason for the decision. Keep enough history to explain why yesterday's comparison differs from today's. A timestamp tells you when something changed; it does not explain why.
A reviewed claim can also become questionable when new information arrives. Mark it for rechecking rather than automatically flipping its truth value. Verification age and feature value are different concerns.
Test the decisions, not just the labels
Useful acceptance cases cover unknown values staying unknown during import, a strict positive filter excluding unreviewed claims, and the negative filter excluding missing data. Also check that a disputed claim remains visibly disputed until a review resolves it.
Test an edition identifier change or mistaken merge: evidence attached to one release must not migrate to another merely because their display titles match. Finally, check that a comparison still communicates all states without color and on a narrow screen.
Our DVDWholesaleShop US catalog provides the retail context for these design questions. It is our store, not a claim that the proposed comparison system is implemented there or that its listings already form a verified feature dataset.
The design goal is straightforward: make the interface no more certain than its evidence. A comparison that admits what remains unknown gives the user a better basis for deciding what to verify next.
Top comments (0)