Skip to content

Scan UI/UX competitive review ​

Date: 2026-05-13. Status: product direction for the lab scanner and the future public scanner.

This note summarizes the four competitor screenshots added under /home/kael/skn-tcg/ui-ux around 18:25-18:26 France time:

  • Screenshot_2026-05-13-18-25-19-67_f33a1edee32b60b2fc25235628dfc32b.jpg
  • Screenshot_2026-05-13-18-25-34-97_535fb16245272e120f303bb6d23d56dd.jpg
  • Screenshot_2026-05-13-18-26-07-10_dfe5b25f37b22d084c23b794380aa73c.jpg
  • Screenshot_2026-05-13-18-26-19-36_63ce71fa88bfbc070a24a65f32991883.jpg

The references include mainstream card scanner apps such as MonPrice, TCG CardScanner, Iestims, and Zebradex. The goal is not to clone them. The goal is to understand why they feel faster and easier than the current SKN lab scanner, then keep the useful patterns while preserving our five-endpoint diagnostic workflow.

Current SKN scanner ​

The current React Native scanner is intentionally a lab screen:

  • it lets Kael test all active scan paths from the Android app;
  • it fans out over five endpoints: Lab, Compat, Tormknd, Combined, and Frame;
  • it exposes raw endpoint names, confidence, timings, matches, and failures;
  • it is useful for debugging accuracy, crops, and endpoint disagreements.

That is the right tool for the current phase, but it is not the right public scanner UX. It currently shows too much technical state during the scan moment: large page title, TCG chips, endpoint table, timing data, debug badge, bottom navigation, and camera controls all compete with the card.

Implementation status: 2026-05-14 ​

The first POC step is now implemented in poc-tcg-collector#173:

  • the scanner keeps Card as the default fast path;
  • Slab and Sealed are available as visual guide modes in the same camera shell;
  • the slab guide reserves a top label band and an inner card window;
  • the sealed guide uses a broader package frame;
  • all five current endpoints still run for every capture;
  • endpoint cells and detailed diagnostics are preserved behind a Test toggle instead of living permanently in the main scan layer.

This is intentionally a UI foundation, not final slab or sealed recognition. Real slab OCR belongs to tcg-collector-backend#157; sealed-product matching belongs to tcg-collector-backend#154.

What competitors do well ​

1. Camera-first scan surface ​

The best competitor screens make the camera view the product. They use most of the viewport for the live camera feed, then keep controls at the edges. The card remains the dominant visual object.

For SKN, this means the scanner should not feel like a dashboard with a camera widget. The camera is the workspace.

2. Immediate alignment feedback ​

Several references show a strong frame, corner guides, grid, or detected card outline. One screen highlights the detected card with a colored contour. This gives the user fast feedback before the backend has answered.

This matters for perceived performance. Even if recognition takes two to five seconds, the app can respond within 200 ms with:

  • detected card outline;
  • blur or glare warning;
  • "move closer" / "align card" state;
  • "reading" state once the crop is acceptable.

3. Result as a bottom sheet ​

The strongest reference pattern is: camera stays open, result appears as a bottom sheet. The user does not feel kicked out of the scanning flow.

For SKN, the result panel should be resumable:

  • collapsed: best match, confidence/agreement, price if reliable;
  • expanded: details, alternatives, debug paths, correction actions;
  • dismissed: continue scanning without navigation.

4. Simple primary actions ​

Competitors keep the primary scan action obvious: shutter in the center, gallery on one side, flashlight on the other, sometimes zoom or language controls.

SKN should keep advanced controls available, but not let them dominate the scan action.

5. Speed mode as an option, not a promise ​

One reference exposes a Fast mode. That is useful, but risky if the app implies that fast mode is always as accurate as normal mode.

For SKN, speed controls belong in lab or advanced settings until we have measured the tradeoff. In public UX, the default should choose the best path automatically.

What not to copy ​

  • Do not block core scan value behind a sign-in prompt.
  • Do not show a price as the main trust signal before identity confidence is clear.
  • Do not expose too many permanent controls on the camera surface.
  • Do not mix production UX and endpoint debugging in the same visual layer.
  • Do not make Fast visible as a magic toggle until the speed/accuracy tradeoff is documented.

Lab scanner target ​

For the current Android-only testing phase, keep the five endpoints. The lab screen should still be redesigned so Kael can collect better evidence faster.

Recommended structure:

  • Camera fills the main view.
  • A visible card frame or live contour shows whether the input is usable.
  • The first reliable endpoint result can appear immediately; the screen should not wait for all five endpoints before showing anything.
  • A bottom sheet summarizes the test:
    • best guess;
    • agreement count, for example 3/5;
    • top candidates;
    • five endpoint cells with match, confidence, timing, and error reason;
    • correction actions: Correct, Wrong, Pick match, Save scan case.
  • The endpoint names remain visible in lab mode only.

This keeps the current scientific value of the five paths while making the screen faster to read.

Public scanner target ​

The future public scanner should hide scan-path complexity.

Recommended structure:

  • Full-screen camera.
  • Minimal header: close/back, flash, gallery, optional help.
  • Live card frame with quality feedback.
  • One main result as soon as confidence is good enough.
  • Alternatives available behind More matches, not shown by default.
  • Price and collection actions shown only after the identity is credible.
  • Endpoint timing and model details hidden behind a debug mode.

The product goal is not "show every engine." The product goal is "identify the object quickly and let the user act."

Recognition modes ​

The current card scanner should evolve into multiple object modes. They should share the camera shell but not the same detection assumptions.

Card ​

The raw-card mode uses a card-shaped frame and optimizes for:

  • card quad detection;
  • perspective warp;
  • full-card visual embedding;
  • footer/collector-number OCR for reranking.

Slab / graded card ​

A slab is not just a card in a larger frame. The scanner must include the label area.

The slab mode should detect:

  • slab rectangle;
  • label region;
  • grader brand, such as PSA, BGS, or CGC;
  • grade, for example PSA 10;
  • certificate number when visible;
  • inner card crop for normal card identity matching.

The final identity should combine slab OCR and card recognition. If the label says PSA 10 but the card crop has low confidence, the UI must show uncertainty instead of pretending the scan is complete.

Sealed product ​

Sealed products need a separate product index. A booster box, ETB, tin, blister, bundle, display, or pack should not be forced through the card index.

The sealed mode should optimize for:

  • wider object frame;
  • front packaging image retrieval;
  • product name OCR;
  • barcode when available;
  • language and region;
  • product-type classification.

Performance implications ​

The current five-endpoint fan-out creates real backend contention. Lab, Combined, and Frame all hit the DINOv2 embeddings sidecar, while Combined can also involve heavier multi-signal logic. The UX must account for that.

Short-term:

  • publish endpoint results incrementally;
  • show input-quality feedback instantly;
  • show the first credible match before the slowest endpoint finishes;
  • keep timing visible in lab mode.

Medium-term:

  • add a consensus layer so the app can surface agreement rather than five separate answers;
  • prioritize the fastest reliable path first;
  • run expensive rerankers only after top-k retrieval;
  • store failed or disputed scans as labeled cases for regression tests.

Long-term:

  • targeted OCR for collector number, set code, slab label, and sealed-product text;
  • multi-crop embeddings for footer, artwork, set area, and full card;
  • reranking after ANN retrieval;
  • separate sealed-product index.

Design principles for implementation ​

  • Lab mode is for evidence, public mode is for action.
  • The scanner must react visually before the backend finishes.
  • Technical disagreement should be summarized, not dumped.
  • Price is secondary to identity confidence.
  • Card, slab, and sealed are different recognition problems.
  • Debug information is valuable, but only behind an explicit lab/debug affordance.