Documentation

Appearance

Revue UI/UX concurrentielle du scanner ​

Date : 2026-05-13. Statut : direction produit pour le scanner lab et le futur scanner public.

Cette note résume les quatre captures concurrentes ajoutées dans /home/kael/skn-tcg/ui-ux autour de 18:25-18:26 heure française :

  • 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

Les références couvrent des apps mainstream de scan de cartes comme MonPrice, TCG CardScanner, Iestims et Zebradex. Le but n'est pas de les cloner. Le but est de comprendre pourquoi elles semblent plus rapides et plus simples que le scanner lab SKN actuel, puis de garder les bons patterns sans perdre notre workflow de diagnostic à cinq endpoints.

Scanner SKN actuel ​

Le scanner React Native actuel est volontairement un écran de lab :

  • il permet à Kael de tester tous les chemins de scan actifs depuis l'app Android ;
  • il fan-out sur cinq endpoints : Lab, Compat, Tormknd, Combined et Frame ;
  • il expose les noms d'endpoints, la confiance, les timings, les matchs et les erreurs ;
  • il est utile pour debugger l'accuracy, les crops et les désaccords entre endpoints.

C'est le bon outil pour la phase actuelle, mais ce n'est pas la bonne UX pour un scanner public. Aujourd'hui, l'écran montre trop d'état technique pendant le moment de scan : gros titre de page, chips TCG, tableau des endpoints, timings, badge debug, bottom navigation et contrôles caméra se disputent tous l'attention avec la carte.

Statut d'implémentation : 2026-05-14 ​

La première étape POC est maintenant implémentée dans poc-tcg-collector#173 :

  • le scanner garde Card comme chemin rapide par défaut ;
  • Slab et Sealed existent comme modes de guide visuel dans la même coque caméra ;
  • le guide slab réserve une bande label en haut et une fenêtre carte intérieure ;
  • le guide scellé utilise une frame package plus large ;
  • les cinq endpoints actuels tournent toujours pour chaque capture ;
  • les cellules endpoint et les diagnostics détaillés restent disponibles derrière un toggle Test au lieu d'être affichés en permanence dans la couche principale de scan.

C'est volontairement une fondation UI, pas la reconnaissance slab ou scellé finale. Le vrai OCR slab appartient à tcg-collector-backend#157 ; le matching produit scellé appartient à tcg-collector-backend#154.

Ce que les concurrents font bien ​

1. Surface camera-first ​

Les meilleurs écrans concurrents font de la caméra le produit. La majorité du viewport est utilisée par le flux caméra, et les contrôles restent sur les bords. La carte reste l'objet visuel dominant.

Pour SKN, le scanner ne doit pas ressembler à un dashboard avec un widget caméra. La caméra est l'espace de travail.

2. Feedback d'alignement immédiat ​

Plusieurs références affichent une frame forte, des coins, une grille ou un contour de carte détecté. Un écran met en évidence la carte détectée avec un contour coloré. Cela donne un retour rapide avant même que le backend ait répondu.

C'est important pour la performance perçue. Même si la reconnaissance prend deux à cinq secondes, l'app peut répondre en moins de 200 ms avec :

  • contour de carte détecté ;
  • avertissement flou ou reflet ;
  • état rapproche la carte / aligne la carte ;
  • état lecture en cours dès que le crop est acceptable.

3. Résultat en bottom sheet ​

Le pattern le plus solide est : la caméra reste ouverte, le résultat arrive dans une bottom sheet. L'utilisateur n'a pas l'impression d'être sorti du flow de scan.

Pour SKN, le panneau résultat doit pouvoir être repris :

  • replié : meilleur match, confiance/accord, prix si fiable ;
  • ouvert : détails, alternatives, paths debug, actions de correction ;
  • dismiss : continuer à scanner sans navigation.

4. Actions principales simples ​

Les concurrents gardent l'action principale évidente : déclencheur au centre, galerie d'un côté, flash de l'autre, parfois zoom ou langue.

SKN doit garder les contrôles avancés disponibles, mais ils ne doivent pas dominer l'action de scan.

5. Mode rapide comme option, pas comme promesse ​

Une référence expose un mode Fast. C'est utile, mais risqué si l'app laisse croire que ce mode est toujours aussi précis que le mode normal.

Pour SKN, les contrôles de vitesse doivent rester en lab ou dans des réglages avancés tant que le compromis vitesse/accuracy n'est pas mesuré. En UX publique, le défaut doit choisir automatiquement le meilleur chemin.

À ne pas copier ​

  • Ne pas bloquer la valeur principale du scan derrière une connexion obligatoire.
  • Ne pas mettre le prix comme signal principal avant que l'identité soit fiable.
  • Ne pas afficher trop de contrôles permanents sur la surface caméra.
  • Ne pas mélanger UX de production et debug endpoint dans la même couche visuelle.
  • Ne pas rendre Fast visible comme un bouton magique tant que le compromis vitesse/accuracy n'est pas documenté.

Cible scanner lab ​

Pour la phase actuelle de test Android-only, on garde les cinq endpoints. L'écran lab doit quand même être redesigné pour permettre à Kael de collecter de meilleures preuves plus vite.

Structure recommandée :

  • La caméra occupe la vue principale.
  • Une frame ou un contour live montre si l'entrée est exploitable.
  • Le premier résultat endpoint fiable peut apparaître immédiatement ; l'écran ne doit pas attendre les cinq endpoints avant d'afficher quelque chose.
  • Une bottom sheet résume le test :
    • meilleur guess ;
    • nombre d'accords, par exemple 3/5 ;
    • meilleurs candidats ;
    • cinq cellules endpoint avec match, confiance, timing et raison d'erreur ;
    • actions de correction : Correct, Wrong, Pick match, Save scan case.
  • Les noms d'endpoints restent visibles uniquement en mode lab.

Cela conserve la valeur scientifique actuelle des cinq paths, tout en rendant l'écran plus rapide à lire.

Cible scanner public ​

Le futur scanner public doit cacher la complexité des chemins de scan.

Structure recommandée :

  • Caméra plein écran.
  • Header minimal : fermer/retour, flash, galerie, aide optionnelle.
  • Frame de carte live avec feedback qualité.
  • Un résultat principal dès que la confiance est suffisante.
  • Alternatives derrière More matches, pas affichées par défaut.
  • Prix et actions collection seulement après une identité crédible.
  • Timings endpoint et détails modèles cachés derrière un mode debug.

L'objectif produit n'est pas "montrer tous les moteurs". L'objectif produit est "identifier l'objet rapidement et permettre à l'utilisateur d'agir".

Modes de reconnaissance ​

Le scanner de cartes actuel doit évoluer vers plusieurs modes d'objet. Ils peuvent partager la même coque caméra, mais pas les mêmes hypothèses de détection.

Carte ​

Le mode carte brute utilise une frame au format carte et optimise pour :

  • détection du quad de carte ;
  • perspective warp ;
  • embedding visuel carte complète ;
  • OCR footer / collector number pour le reranking.

Slab / carte gradée ​

Un slab n'est pas juste une carte dans un cadre plus grand. Le scanner doit inclure la zone de label.

Le mode slab doit détecter :

  • rectangle du slab ;
  • zone de label ;
  • organisme de grading, par exemple PSA, BGS ou CGC ;
  • grade, par exemple PSA 10 ;
  • numéro de certification quand il est visible ;
  • crop de la carte intérieure pour matcher l'identité de carte normale.

L'identité finale doit combiner OCR du label et reconnaissance de la carte. Si le label dit PSA 10 mais que le crop carte est peu fiable, l'UI doit montrer l'incertitude au lieu de faire semblant que le scan est complet.

Produit scellé ​

Les produits scellés ont besoin d'un index produit séparé. Une booster box, ETB, tin, blister, bundle, display ou pack ne doit pas être forcé dans l'index des cartes.

Le mode scellé doit optimiser pour :

  • frame objet plus large ;
  • retrieval sur image de packaging frontal ;
  • OCR du nom produit ;
  • code-barres quand disponible ;
  • langue et région ;
  • classification du type de produit.

Implications performance ​

Le fan-out actuel à cinq endpoints crée une vraie contention backend. Lab, Combined et Frame tapent tous le sidecar embeddings DINOv2, tandis que Combined peut aussi déclencher une logique multi-signal plus lourde. L'UX doit en tenir compte.

Court terme :

  • publier les résultats endpoint progressivement ;
  • afficher le feedback qualité d'entrée immédiatement ;
  • afficher le premier match crédible avant que l'endpoint le plus lent finisse ;
  • garder les timings visibles en mode lab.

Moyen terme :

  • ajouter une couche de consensus pour montrer l'accord plutôt que cinq réponses séparées ;
  • prioriser le chemin fiable le plus rapide ;
  • lancer les rerankers coûteux seulement après le top-k retrieval ;
  • stocker les scans échoués ou disputés comme cas labellisés pour les tests de régression.

Long terme :

  • OCR ciblé pour collector number, set code, label slab et texte de produit scellé ;
  • embeddings multi-crop pour footer, artwork, zone de set et carte complète ;
  • reranking après retrieval ANN ;
  • index séparé pour les produits scellés.

Principes de design pour l'implémentation ​

  • Le mode lab sert à produire des preuves, le mode public sert à agir.
  • Le scanner doit réagir visuellement avant la fin du backend.
  • Le désaccord technique doit être résumé, pas dumpé.
  • Le prix est secondaire par rapport à la confiance d'identité.
  • Carte, slab et scellé sont trois problèmes de reconnaissance différents.
  • Le debug est précieux, mais seulement derrière un affordance explicite lab/debug.

Docs liées ​