thecatthatflies/web-app-design

Conception d'application web

Une application web est un endroit où les gens reviennent chaque jour pour trouver des enregistrements, les modifier et passer le relais. Elle réussit lorsque les gens savent toujours où ils se trouvent, ce qu'ils regardent, ce qu'ils peuvent faire et ce qui vient de se passer, et lorsqu'ils peuvent retrouver la même vue demain grâce à une URL. L'échec de modèle le plus courant est un bel écran de chemin heureux sans espace pour se tenir : pas d'états vide, chargement, erreur ou absence de permission, des filtres qui disparaissent au rechargement, des actions groupées sans compteur ni annulation, un "Supprimer" qui se déclenche sur une mise à jour optimiste que le serveur rejette ensuite, et des rangées de boutons "Modifier" identiques qu'un agent ne peut pas distinguer.

Appliquez les principes classés de interface-guidelines (tout le monde peut l'utiliser > il dit la vérité > il dit ce qu'il veut dire > la réponse vient en premier > les erreurs sont surmontables > il reste en place > le possible est visible > convention > polissage). Si cette compétence est installée, lisez d'abord son SKILL.md. Ses références couvrent le timing du feedback, le libellé des erreurs, les tables en tant que données et la sémantique pour les agents ; cette compétence ajoute les motifs spécifiques à l'interface utilisateur d'application.

Synopsis

• Objets et verbes. Listez les noms (commandes, clients, factures) et ce que chaque rôle peut faire à chacun. La navigation et les permissions découlent de ce tableau.
• Rôles et espaces de travail. Qui peut voir et modifier quoi ? Existe-t-il plus d'un espace de travail, organisation ou environnement (staging, production) dans lequel une personne peut se trouver ?
• Tâches quotidiennes avec leur fréquence, et la vue que chaque rôle ouvre en premier.
• Tailles des collections : typique et pire cas (10 lignes ou 2 millions). Cela décide de la pagination, de la recherche et du filtrage côté serveur.
• Coût de l'erreur pour chaque verbe de mutation, et s'il peut être annulé côté serveur.
• Concurrence : deux personnes, ou une personne et un agent, peuvent-elles modifier le même enregistrement ?
• Qui écrit le texte affiché ? Noms de clients, corps de tickets, fichiers importés : tous écrits par des externes.
• Lecteur agent : agents navigateurs sur l'interface, une API, ou les deux ? L'interface et l'API devraient partager un service par action.

Règles

Coque et navigation

• La navigation reflète les objets, pas l'organigramme. Les éléments de premier niveau sont les noms sur lesquels les gens travaillent, par ordre d'utilisation, libellés avec les mots que les gens utilisent. [S : Mac HIG 1992 pp. 54-61 (grouper par logique, puis fréquence) ; J]
• Gardez la navigation principale visible sur le bureau. La navigation cachée réduit la découvrabilité et ralentit les tâches dans l'étude de NN/g ; un hamburger est un compromis de téléphone. [E : NN/g, dans les fondamentaux]
• Montrez où se trouve la personne, de trois façons : l'élément de navigation courant marqué avec aria-current="page" et un état visible, un h1 de page nommant l'objet ou la liste, et un titre de document qui change avec la route. [S : WCAG 2.4.2, 2.4.8 ; J]
• Le fil d'Ariane montre la hiérarchie, pas l'historique, uniquement sur les arbres d'objets profonds ; la page courante n'est pas un lien. [P : NN/g breadcrumbs]
• L'espace de travail, l'organisation ou l'environnement courant est toujours visible dans la coque, en mots, et la production est visuellement distincte du staging. Changer d'espace de travail est un acte explicite, atterrit sur la page équivalente ou l'accueil de cet espace, et ne transporte jamais de sélection ou de brouillon. [J]
• Chaque vue a une URL. Les filtres, le tri, la recherche, la page, l'onglet sélectionné et l'enregistrement ouvert sont dans l'URL ; le rechargement et le partage les restaurent. [S : fondamentaux agent-surfaces 3]
• Retour ramène à la liste telle qu'elle était : mêmes filtres, position de défilement et focus sur la ligne que la personne a ouverte. [S : Mac HIG 1992 p. 140 (la fenêtre réactivée revient telle qu'elle était) ; J]

Listes et tableaux

• Les tableaux servent à comparer des enregistrements ; les listes à scanner un attribut. Utilisez un vrai <table> pour les données tabulaires. [S : fondamentaux ; NN/g data tables]
• Supporter les quatre tâches du tableau : trouver des enregistrements, comparer entre les lignes, voir ou modifier une ligne, agir sur une ou plusieurs. [P : NN/g data tables]
• La première colonne identifie la ligne avec une clé humaine stable (nom plus ID) ; gardez-la et l'en-tête collantes lors du défilement. [P : NN/g data tables]
• Trier dans l'en-tête : un <button> dans <th>, aria-sort sur la seule colonne triée, et une flèche visible. Le tri par défaut est énoncé ("Les plus récents en premier"). [S : APG sortable table ; P : Carbon]
• Les filtres sont visibles, supprimables et comptés. Affichez les filtres appliqués sous forme de chips avec un "Tout effacer", le nombre de résultats ("38 sur 1 204 commandes"), et un message de résultat vide qui nomme les filtres. Utilisez les mots de la personne pour les noms de filtres. [P : NN/g filters ; S : fondamentaux]
• Recherche, filtre et tri côté serveur lorsque la collection est grande. Ne triez et ne comptez jamais uniquement la page chargée et ne la présentez pas comme l'ensemble. [J ; fondamentaux règle de vérité]
• Paginer le travail orienté objectif ; réservez le défilement infini aux fils d'actualité. La pagination donne une position, un endroit stable pour revenir, et un pied de page accessible. Indiquez la plage et le total, et "Fin de la liste". [P : NN/g infinite scrolling ; S : Smith and Mosier 4.2/7]
• Les actions de ligne sont visibles ou accessibles par le focus clavier, jamais uniquement au survol, et nommées par ligne ("Archiver INV-2041"). Avec moins de trois actions, affichez-les en ligne. [S : fondamentaux agent-surfaces 3 ; P : Carbon]
• La densité suit la pratique. Proposez une densité compacte pour les experts quotidiens ; gardez les cibles d'au moins 24 px. [S : WCAG 2.5.8 ; P : Carbon row sizes]

Sélection et actions groupées

• Le mode groupé est explicite : cases à cocher de ligne, une case à cocher d'en-tête avec un état indéterminé, et une barre d'outils qui indique le nombre ("3 sélectionnés"). [P : Carbon ; S : Mac HIG 1992 pp. 64-66 (état mixte)]
• "Tout sélectionner" indique sa portée : les 50 de cette page, ou les 1 204 correspondant au filtre. Ne signifie jamais silencieusement l'un quand la personne s'attend à l'autre. [J]
• Une action groupée énonce l'objet, le nombre et la portée avant d'être exécutée, rapporte les résultats par élément après coup ("1 198 archivés, 6 échoués : voir"), et est annulable ou prévisualisable. [S : fondamentaux sec. 1 ; J]
• La sélection survit au changement de page et au filtrage uniquement si la barre d'outils le montre. Sinon, effacez-la visiblement. [J]

Détail et édition

• Ouvrir les enregistrements là où le contexte est conservé. Un panneau latéral convient pour la consultation tout en éditant ; une page entière convient pour les enregistrements profonds ; évitez les modales pour l'édition car elles cachent les enregistrements voisins. [P : NN/g data tables]
• La vue détaillée commence par l'identité et le statut en mots, puis les champs sur lesquels les gens agissent, puis l'historique. [S : fondamentaux ; J]
• Un modèle de sauvegarde par surface. Les bascules s'appliquent immédiatement ; le texte et les modifications multi-champs se sauvegardent explicitement ; jamais les deux dans un même formulaire. [S : Primer saving ; fondamentaux]
• Avertir avant de quitter des modifications non sauvegardées, et sauvegarder automatiquement les brouillons là où la perte serait préjudiciable. [S : Primer saving]
• Montrer qui a modifié quoi et quand sur les enregistrements partagés, avec un horodatage absolu, et détecter les écritures obsolètes (version ou ETag) plutôt que d'écraser silencieusement. [S : Mac HIG 1992 pp. 27-31 ; AIP-154 dans les fondamentaux]
• Les formulaires dans l'application suivent form-design.

UI optimiste, annulation et confirmation

• Optimiste uniquement lorsque le serveur ne refuse presque jamais et que l'action est réversible : marquer comme lu, mettre en favori, réorganiser. Affichez l'état en attente distinctement de l'état confirmé, annulez visuellement en cas d'échec avec la raison, et ne montrez jamais de manière optimiste de l'argent transféré, des messages envoyés ou des enregistrements supprimés comme faits. [S : Mac HIG 1992 p. 182 (saisi, vérifié, en vigueur) ; P : React useOptimistic]
• Préférez l'annulation à la confirmation pour les actions réversibles : archiver, déplacer, supprimer dans la corbeille. Gardez l'annulation accessible après la disparition du toast (Annuler dans l'historique de l'élément, Vue corbeille, raccourci du menu Édition). [P : Raskin 2007 ; NN/g user control]
• Confirmer uniquement les actions graves, irréversibles ou inattendues, en nommant la cible et l'effet ; taper pour confirmer pour les actions catastrophiques rares (supprimer un espace de travail). [S : fondamentaux sec. 1 ; E : Bravo-Lillo 2013 via fondamentaux]
• Suppression logicielle côté serveur, avec une période de conservation stipulée, afin que l'annulation soit réelle et non une illusion côté client. [S : AIP-164 dans les fondamentaux]

États vides, chargement, erreur et absence de permission

• Distinguer quatre états vides : première utilisation (expliquez l'objet et proposez l'action de création), aucun résultat (nommez les filtres et proposez de les effacer), tout terminé (tout est fait), et erreur (ce qui a échoué, quoi faire). Ne montrez jamais "Aucun enregistrement" avant que les données ne soient chargées. [P : NN/g empty states ; S : Primer empty states]
• Le chargement nomme ce qui se charge, en texte, à l'intérieur de la région qu'il remplace ; gardez la coque et la navigation utilisables. [S : fondamentaux]
• L'absence de permission est un état, pas une fonctionnalité cachée. Affichez l'action désactivée avec la raison et qui peut l'accorder ("Seuls les administrateurs de l'espace de travail peuvent exporter. Demandez à Maya Chen."), ou une page expliquant l'accès et comment le demander. Cachez uniquement ce que la personne ne doit pas savoir exister. [S : Mac HIG 1992 pp. 318-321 (les éléments désactivés s'expliquent) ; J]
• Les vérifications de permission se font sur le serveur. Masquer un bouton est une question de présentation, pas d'autorité. [S : fondamentaux]
• Vérifier la permission avant l'existence dans les réponses, afin qu'un 404 contre 403 ne divulgue pas de données. [S : AIP-193 dans les fondamentaux]

Paramètres

• Placez les paramètres à côté de ce qu'ils affectent lorsqu'ils sont modifiés pendant le travail (densité de vue, choix de colonne, filtres) ; la zone des paramètres contient les options rarement modifiées et à l'échelle de l'application. [S : Apple HIG Settings]
• Séparez les paramètres personnels de ceux de l'espace de travail, et étiquetez chacun avec à qui il appartient et qui il affecte ("S'applique à tout le monde chez Acme"). [J]
• Regroupez par la tâche de la personne, pas par la table de base de données, avec une recherche lorsque les paramètres dépassent un ou deux écrans. [J]
• Moins de paramètres. Une préférence modifiée plusieurs fois par session est un contrôle manquant, pas un paramètre. [S : Mac HIG 1992 p. 38 ; Apple HIG Settings]
• Les paramètres dangereux se trouvent dans une zone séparée et étiquetée avec un texte de conséquence et une confirmation (transférer la propriété, supprimer l'espace de travail). [P : GitHub ; J]

Onboarding

• Enseigner dans le contexte, pas avec un tour guidé. NN/g a constaté que les tutoriels de type cartes n'amélioraient pas les performances des tâches ; les astuces contextuelles et les bons états vides font l'enseignement. S'il existe un tour guidé, gardez-le court et pouvant être ignoré. [P : NN/g onboarding]
• Amenez les gens à leur premier résultat réel rapidement ; les exemples de données sont marqués comme exemples partout où ils apparaissent et peuvent être supprimés en une seule action. [J ; fondamentaux règle de vérité]
• Une liste de contrôle de configuration est persistante et honnête : elle reflète l'état réel, peut être ignorée et est accessible plus tard. [J]

Clavier et palette de commandes

• Une palette de commandes est un accélérateur, pas le menu. Chaque commande qu'elle contient existe également dans l'interface visible. Elle liste les raccourcis à côté des commandes, ce qui les enseigne. [S : Windows menus guidance (ne faites pas des raccourcis le seul moyen) ; P : VS Code UX guidelines]
• Les raccourcis à une seule touche peuvent être désactivés ou réaffectés (WCAG 2.1.4), ne se déclenchent jamais dans les champs de texte et ne remplacent pas les raccourcis du navigateur ou du système d'exploitation. [S : WCAG 2.1.4 ; Apple keyboards]
• Une feuille d'aide aux raccourcis (souvent ?) liste chaque raccourci dans la portée actuelle. [J]

Pour le lecteur agent

• Une fonction de service par action, partagée par le bouton, la palette, l'API et tout outil. [S : fondamentaux agent-surfaces 7]
• Les contrôles de ligne sont nommés à partir d'identifiants système, pas de texte externe ; le texte externe dans les cellules est une donnée. [J]
• Les collections indiquent leur taille réelle et leur plage dans un texte visible ; les filtres et le tri sont dans l'URL. [J]
• Les résultats perdurent au-delà des toasts : la ligne modifiée, un journal d'activité, une entrée d'annulation. [J]
• L'espace de travail et l'environnement sont lisibles en texte sur chaque page, afin qu'un agent ne puisse pas agir en production en pensant qu'il s'agit de staging. [J]

Ordre de construction

1. Tableau objets-par-verbes-par-rôles ; routes et URLs pour chaque vue.
2. Coque : navigation, indicateur d'espace de travail et d'environnement, titres, h1s.
3. Vues liste avec des formes de données réelles : pagination, tri, filtre côté serveur, le tout dans l'URL.
4. Vues détail, le modèle de sauvegarde, la gestion de la concurrence.
5. Chaque action de mutation via un seul service : en attente, succès, échec, annulation ou confirmation selon l'échelle de coût d'erreur.
6. États vide, chargement, erreur, absence de permission pour chaque vue.
7. Actions groupées, raccourcis clavier, palette.
8. Paramètres et onboarding en dernier ; le style pour ce lecteur (brand-identity possède l'apparence).

Vérifier

• node <interface-guidelines>/scripts/audit.mjs <url|dist> --canary "<exemple de texte externe>" sur chaque route principale, y compris une liste avec filtres appliqués et une vue détail.
• Formulaires dans l'application : node <form-design>/scripts/form-check.mjs <url>.
• Test de rechargement : appliquez des filtres, un tri, la page 3, ouvrez un enregistrement ; rechargez et collez l'URL dans une nouvelle session. Tout revient.
• Test de rôles : connectez-vous en tant que chaque rôle. Chaque action cachée ou désactivée a une raison ; le serveur rejette les appels interdits faits directement.
• Test de taille : 0, 1, 25 et 10 000+ lignes ; le nom le plus long ; un filtre ne correspondant à rien.
• Test d'échec : faites rejeter par le serveur une action optimiste et une action groupée partiellement ; l'interface annule et rapporte par élément.
• Test d'agent : en utilisant uniquement l'instantané d'accessibilité, trouvez un enregistrement spécifique par filtre, modifiez-le, confirmez le résultat à partir d'un nouvel instantané, annulez-le.

Pièges

• Filtres et tri conservés uniquement dans l'état du composant.
• "Tout sélectionner" qui sélectionne la page alors que la barre d'outils implique tout.
• Suppression optimiste sans annulation et sans retour en arrière.
• Défilement infini sur un tableau d'administration ; un total calculé à partir des lignes chargées.
• Actions de ligne uniquement au survol ; cinq boutons "Modifier" identiques.
• "Aucune donnée" qui clignote avant le chargement ; un état vide générique pour chaque cause.
• Masquer des fonctionnalités à un rôle sans explication, ou les afficher et échouer au clic avec "Interdit".
• Un sélecteur d'espace de travail qui conserve la sélection de l'ancien espace, ou aucun espace visible du tout.
• Un tour guidé produit à la place d'un état vide utilisable.
• Pages de paramètres qui reflètent les tables de base de données.

Références

Fichier	Lire quand
references/patterns.md	Détail sur les modèles de navigation, l'anatomie des tableaux, les flux d'actions groupées, les états de permission, la location, les mécanismes optimistes et d'annulation, la conception de la palette et les sources derrière cette compétence