App Screenshot Showcase (Aperçu de captures d'écran d'application)
Les vraies captures d'écran sont la source de vérité. Ne jamais fabriquer, redessiner, retoucher ou "améliorer" l'interface utilisateur de l'application. Ne jamais modifier le texte à l'intérieur des captures d'écran.
Deux types d'appareils. Report, Review et Resolve sont des écrans d'application mobile citoyenne
(device: "mobile", rendu dans PhoneFrame, portrait). Assign et Respond se déroulent dans la
vue web du centre d'opérations, pas dans l'application mobile (device: "web", rendu dans
BrowserFrame, paysage) — voir sos-content-accuracy "Faits vérifiés sur le produit".
Assurez-vous de cela dès la réception : une capture d'écran d'un tableau de bord web forcée dans un cadre de téléphone représente mal le produit.
Où placer les fichiers
| Quoi | Emplacement de dépôt (utilisateur) | Sortie (générée) |
|---|---|---|
| Captures d'écran d'application (PNG/JPG, pleine résolution) | assets/screenshots-raw/ | public/screenshots/<id>.webp (+ .avif) |
| Logo, icône d'application, marques déposées | assets/brand-raw/ | public/brand/ |
| Image Open Graph (1200×630) | assets/brand-raw/og-image.png | public/brand/og-image.jpg |
assets/ n'est pas déployé. Seuls les fichiers optimisés dans public/ sont livrés.
Convention de nommage
<ordre>-<objectif-écran>.png, en minuscules avec kebab-case, par exemple
01-home.png, 02-category-select.png, 03-report-form.png, 04-report-submitted.png, 06-welcome.png, 07-register.png, 08-verify.png, 09-login.png.
Si les fichiers de l'utilisateur sont nommés arbitrairement, inspectez chacun et renommez par objectif.
Identifiants actuels du manifeste et ce que chacun doit contenir :
| id (base du nom de fichier) | Appareil | Écran |
|---|---|---|
hero-primary | mobile | Écran d'accueil |
hero-secondary | mobile | Écran de sélection de catégorie |
how-report | mobile | Formulaire de signalement (capture/soumission d'un incident) |
how-review | mobile | Écran de confirmation après soumission |
how-assign | web | Vue web du centre d'opérations — signalement en cours d'attribution |
how-respond | web | Vue web du centre d'opérations — itinéraire/localisation du répondant |
how-resolve | mobile | Écran de statut montrant un signalement résolu |
register-welcome | mobile | Écran de bienvenue / première ouverture |
register-form | mobile | Écran des détails d'inscription |
register-verify | mobile | Écran de vérification (omettre si l'application n'en a pas) |
register-home | mobile | Écran de connexion |
Captures d'écran mobiles : portrait, directement depuis le téléphone, non recadrées. Captures d'écran web
(how-assign, how-respond) : captures paysage du navigateur de la vue du centre d'opérations, non recadrées.
Flux de réception (chaque nouveau lot)
- Inspecter chaque image (l'ouvrir). Identifier l'objectif : bienvenue, inscription, vérification, connexion, accueil, sélecteur de catégorie, formulaire de signalement, appareil photo/capture, confirmation, statut/suivi, notifications, vue répondant, carte/itméraire, autre.
- Vérification de la vie privée — rechercher les vrais noms, numéros de téléphone, emails, adresses, visages, plaques d'immatriculation, emplacements précis du domicile, identifiants, jetons. Si trouvé : arrêter et demander à l'utilisateur une version épurée. Ne PAS flouter/éditer vous-même sauf si l'utilisateur le demande explicitement, et alors seulement flouter, ne jamais modifier l'interface utilisateur.
- Enregistrer les dimensions et le rapport hauteur/largeur. Ne jamais recadrer l'interface utilisateur ni étirer. La barre d'état peut rester telle quelle.
- Optimiser :
npm run optimize:screenshots(sharp) : sortie WebP q≈82 et AVIF q≈60 à une largeur maximale de 1080px, conserver le rapport d'aspect d'origine, supprimer les métadonnées (EXIF/GPS). Garder le texte lisible — zoomer pour vérifier le petit texte de l'interface utilisateur après compression. - Enregistrer dans
src/config/screenshots.ts(voir le schéma ci-dessous). - Placer à l'aide du tableau de correspondance ; proposer le placement à l'utilisateur dans une courte liste en cas d'ambiguïté.
- Vérifier la disposition à 320/768/1440, pas de CLS, texte alternatif présent, seul hero utilise
priority. - Mettre à jour le journal de réception dans
docs/assets-guide.md.
Schéma du manifeste
// src/config/screenshots.ts
export type ScreenPurpose =
| "welcome" | "register" | "verify" | "login" | "home"
| "category" | "report-form" | "capture" | "submitted"
| "status" | "notifications" | "responder" | "map" | "other";
export type Slot =
| "hero-primary" | "hero-secondary"
| "how-report" | "how-review" | "how-assign" | "how-respond" | "how-resolve"
| "showcase" | "register-welcome" | "register-form" | "register-verify" | "register-home"
| "tracking";
export type Device = "mobile" | "web"; // mobile → PhoneFrame, web → BrowserFrame
export interface Screenshot {
id: string; // "03-report-form"
src: string | null; // "/screenshots/03-report-form.webp" ; null = espace réservé
width: number; height: number; // px intrinsèques du fichier optimisé
alt: string; // décrit ce que l'écran montre, de manière factuelle
purpose: ScreenPurpose;
slots: Slot[];
device: Device;
caption?: string;
privacyChecked: boolean; // doit être true avant que src ne soit non null en production
}
export const screenshots: Screenshot[] = [ /* ... */ ];
export const bySlot = (slot: Slot) => screenshots.filter(s => s.slots.includes(slot));
- Ratio d'espace réservé par défaut : 1179×2556 (≈ 9:19.5) pour
device: "mobile"; 1600×1000 (≈ 16:10) pourdevice: "web"— jusqu'à ce que les vraies tailles soient connues. - La construction devrait avertir (console en dev) si une capture d'écran a
srcmaisprivacyChecked: false.
Correspondance de placement
| Objectif de l'écran | Emplacement(s) | Appareil |
|---|---|---|
| home | hero-primary, register-home, showcase | mobile |
| category | hero-secondary, how-report, showcase | mobile |
| report-form / capture | how-report, showcase | mobile |
| submitted | how-review, showcase | mobile |
| status | tracking, how-resolve, showcase | mobile |
| notifications (assign) | how-assign | web |
| map/route (respond) | how-respond | web |
| welcome | register-welcome | mobile |
| register | register-form | mobile |
| verify | register-verify (omettre complètement l'étape si un tel écran n'existe pas) | mobile |
| login | register-home | mobile |
showcase ne contient que des écrans d'application mobile (Report, Review, Resolve) — c'est la
vitrine de l'application citoyenne, pas un endroit pour la vue web du centre d'opérations.
Règles de texte alternatif
Décrivez ce qui est visible, pas des affirmations marketing. Bon : "Écran de sélection de catégorie listant les types de signalement Secours, Police, Pompiers et autres." Mauvais : "Signalement rapide et facile !" Les doublons décoratifs (par exemple, un reflet) reçoivent alt="".
Composants PhoneFrame / BrowserFrame / DeviceFrame
PhoneFrame: cadre CSS pur, rectangle arrondi (ink-raised), surbrillance intérieure de 1px, fine encoche d'écran, pilule dynamique optionnelle. Pas de maquettes d'appareil PNG.BrowserFrame: cadre de fenêtre de navigateur CSS pur (même langage de surface), trois points chromés simples, pas de barre d'URL factice ni d'interface utilisateur de navigateur fabriquée. Utilisé pour les écransdevice: "web"(Assign, Respond).DeviceFrame: choisitPhoneFramevsBrowserFrameà partir descreenshot.device— utilisez-le dans les sites d'appel qui rendent un emplacement/de manière générique (Comment ça marche) au lieu de coder en dur un type de cadre.- Enfants :
next/imageavecwidth/heightexplicites du manifeste,sizesdéfini (par exemple(min-width:1024px) 320px, 70vw),loading="lazy"sauf pour hero-primary (priority,fetchPriority="high"). - Mode espace réservé (
src === null) : écran dégradé neutre, petit libellé "Emplacement de capture d'écran : — en attente de l'écran réel de l'application", bon rapport hauteur/largeur. Pas d'éléments d'interface utilisateur factices, pas de boutons ou de texte factices. - Le contenu de l'écran doit rester droit et lisible : max rotateY 18°, jamais en miroir.
- Mobile (< 1024px) : pas de rotation 3D ; téléphones à plat, galerie de défilement horizontal natif (
snap-x snap-mandatory,scroll-padding), indicateur de défilement visible, région focalisable au clavier avecaria-label.
Liste de contrôle par lot
- Chaque image inspectée et objectif identifié
- Aucune donnée personnelle visible (ou l'utilisateur a confirmé qu'il s'agit de données factices)
- Fichiers optimisés < ~180 Ko chacun, texte toujours lisible
- Entrées du manifeste complètes : dimensions, texte alternatif, objectif, emplacements, appareil, privacyChecked
- Une seule image
prioritysur la page - Pas de changement de mise en page ; rapports hauteur/largeur intacts
- Les emplacements d'espace réservé inutilisés continuent de s'afficher avec un libellé honnête
- Réexécution Lighthouse mobile après intégration