Norme de Structure d'Interface

Que fait Norme de Structure d'Interface ?

Les interfaces deviennent difficiles à utiliser à cause de la structure, pas de la taille. Une application avec 300 paramètres peut être facile à naviguer et une application avec 30 peut être un labyrinthe. Les causes sont toujours les mêmes : le même contrôle qui vit à plusieurs endroits, des menus qui reflètent le code ou l'équipe, des actions mélangées avec des préférences, des icônes non étiquetées, une portée invisible, et rien n'est jamais supprimé.

La solution est de faire ce que les grandes plateformes font déjà, de la même manière dans chaque application, afin que les gens puissent utiliser ce qu'ils connaissent déjà :

• Une mise en page familière. Une liste de catégories consultable à gauche, la page ouverte à droite, des lignes avec l'étiquette à gauche et le contrôle à droite.
• Un ensemble de noms de catégories. Compte, Notifications, Confidentialité et sécurité, Accessibilité, Apparence, Langue et région, Données et stockage, puis les propres sujets du produit. Sept questions classent n'importe quel paramètre dans exactement une catégorie.
• Moins de contrôles. Le meilleur paramètre est celui qui n'est jamais publié car une meilleure valeur par défaut l'a rendu inutile.
• Un seul emplacement pour chaque contrôle qui reste. Chaque paramètre, destination et commande est un enregistrement dans un registre, chaque enregistrement a exactement un emplacement, et l'interface est tirée des enregistrements. Quand personne ne place un contrôle manuellement, la structure ne peut pas dériver.

Choisir la tâche

Trouvez la demande dans ce tableau et lisez uniquement cette section, ainsi que les fichiers qu'elle nomme.

La demande	Section	Lire aussi
« Ajouter un paramètre / élément de menu / bouton »	Ajouter un contrôle	Rien de plus, généralement
« Cette interface est un désastre », « révisez ceci », « les utilisateurs ne trouvent pas les choses »	Auditer une interface existante	references/audit.md, references/rules.md
« Construire / concevoir / reconcevoir un écran de paramètres, une barre latérale ou une barre d'outils », ou une liste de fonctionnalités à transformer en une seule	Construire une nouvelle surface	references/categories.md, references/visual-design.md, references/record-schema.md
« Organiser nos paramètres », « quelles catégories devrions-nous avoir »	Les catégories standard	references/categories.md
« Configurer ceci pour notre projet »	Adopter le registre	references/record-schema.md

Quelle que soit la tâche, respectez le projet dans lequel vous vous trouvez. Si la base de code a déjà un registre de paramètres, une bibliothèque de composants ou ses propres règles concernant le balisage, étendez-les ; n'introduisez pas de système parallèle. La norme décrit la structure, pas la technologie.

Le dossier evals/ contient des cas de test pour cette compétence. Ce n'est pas un document de référence ; ne le lisez pas pendant que vous effectuez une tâche.

Ajouter un contrôle

Posez ces cinq questions dans l'ordre et arrêtez-vous à la première réponse oui. Dites à l'utilisateur cette décision et la raison ; ne leur faites pas parcourir des questions qui ne s'appliquent plus.

1. Une meilleure valeur par défaut le rendrait-elle inutile ? Si le besoin peut être satisfait pour tout le monde en changeant la valeur par défaut, en détectant la situation, ou simplement en supprimant le comportement que les gens n'aiment pas (une confirmation dont personne n'a besoin, une invite pour quelque chose qui s'enregistre automatiquement), faites cela. Il n'y a pas de paramètre.
2. Le système ou un administrateur le décide-t-il déjà ? Le thème, la taille du texte, l'autorisation de notification et autres appartiennent à la couche inférieure. Suivez-la. Si le produit a une vraie raison d'offrir son propre choix, le choix inclut « Utiliser le paramètre système » et c'est la valeur par défaut ; ce n'est jamais un simple interrupteur marche/arrêt.
3. Est-ce fait une fois, pas un choix durable ? Alors c'est une action : un bouton, tenu à l'écart des bascules, en contexte ou dans un groupe étiqueté au pied de sa page.
4. Est-ce modifié chaque semaine ou plus souvent ? Alors le contrôle vit en contexte, à côté de la fonctionnalité qu'il modifie, avec un lien vers sa page d'accueil. La page d'accueil le liste toujours.
5. Moins d'environ 1 personne sur 20 le-changerait-elle jamais ? Alors son niveau est avancé. Une page avec trois éléments avancés ou plus les montre dans un pli Avancé ; avec moins, c'est une ligne ordinaire placée en dernier.

Sinon, c'est une ligne standard sur sa page thématique.

Si la réponse à la question 1 ou 2 était oui, dites-le clairement et proposez ce changement au lieu du paramètre. Chaque paramètre a un coût en tests, en support et dans la capacité des autres à trouver les choses, donc l'utilisateur devrait entendre l'option la moins chère en premier. Ils peuvent toujours vouloir le paramètre ; c'est leur choix. Proposez-le comme solution de repli en quelques lignes.

Choisir l'emplacement. Utilisez les sept questions sous Les catégories standard, mappées sur les pages qui existent. Si le contrôle ne correspond à aucune, c'est la preuve d'un sujet manquant : dites-le et proposez-en un. Ne créez pas de page appelée Général, Divers, Autre ou Avancé. Quand l'interface existante a déjà une telle page, placez le nouveau contrôle sur la page spécifique la mieux nommée à la place et mentionnez le fourre-tout en une ligne comme quelque chose à corriger plus tard. Une demande d'ajout d'un contrôle n'est pas une demande d'audit.

Contrôles qui posent une question. Une confirmation avec « Ne plus demander » est un contrôle contextuel pour un paramètre (question 4) : la case à cocher et la ligne de paramètres sont le même enregistrement, donc le choix peut être trouvé et annulé plus tard. N'offrez jamais « Ne plus demander » sans une ligne quelque part qui l'annule.

Combien montrer à l'utilisateur. Si le projet a un registre, écrivez l'enregistrement complet (champs ci-dessous) et vérifiez que la page sur laquelle il atterrit est toujours dans les limites. Si ce n'est pas le cas, ou si l'utilisateur a seulement demandé des conseils, répondez en termes simples : quoi ajouter, où, comment cela s'appelle, quelle est sa valeur par défaut et pourquoi, et si cela s'applique à cet appareil ou à l'ensemble du compte. Les champs tels que id, tier, owner et reviewed sont de la comptabilité ; laissez-les de côté dans une réponse conversationnelle. Quand vous ne savez pas quelque chose dont l'enregistrement a besoin (si les paramètres se synchronisent entre les appareils, quelles pages existent), énoncez votre hypothèse dans une clause et continuez.

Auditer une interface existante

L'objectif est une liste de constats concrets et corrigeables liés à des numéros de règle, et une structure proposée. Lisez references/rules.md d'abord pour que les constats puissent citer des règles, et utilisez le modèle de rapport dans references/audit.md.

Un audit peut couvrir les paramètres, la navigation, les barres d'outils, ou les trois. Auditez ce que l'utilisateur a demandé et ce que vous pouvez voir. Si l'écran n'a pas de paramètres, sautez les parties du modèle concernant les paramètres ; ne les étirez pas pour qu'elles correspondent.

1. Inventaire. Listez chaque endroit où une personne peut modifier ou déclencher quelque chose : écrans de paramètres, menus de compte, menus contextuels, boîtes de dialogue par élément, listes de navigation, barres d'outils, bandes d'icônes, indicateurs de ligne de commande, fichiers de configuration. Dans une grande base de code, déléguez le balayage ou recherchez les modèles (étiquettes, bascules, constructeurs de menus) ; ne lisez pas des fichiers entiers. Pour chaque contrôle, enregistrez son étiquette telle qu'affichée, son type, où il vit et comment on y accède. Quand un contrôle n'a pas d'étiquette du tout, dites-le, décrivez-le par sa position, et marquez toute supposition sur ce qu'il fait comme une supposition.
2. Mesurez. Comptez ce que les règles limitent : endroits pour modifier les choses, entrées de navigation de premier niveau, paramètres par page, profondeur, boutons par barre d'outils, contrôles iconiques uniquement, contrôles sans nom accessible, boîtes de recherche, et combien d'ensembles de commandes distincts des objets du même type montrent.
3. Trouvez les symptômes.
   • le même paramètre ou la même commande accessible à plusieurs endroits, ou deux contrôles qui s'empilent ou se contredisent
   • un sujet dispersé sur plusieurs pages
   • une chose avec plusieurs noms ; un lien dont l'étiquette diffère du titre de sa cible ; des noms quasi-identiques côte à côte
   • des pages nommées Général, Divers, Autre, Avancé
   • des actions (exporter, supprimer, se déconnecter) assises parmi les préférences ou parmi les destinations
   • une portée expliquée uniquement dans le texte d'indice, ou pas du tout
   • un vocabulaire de constructeur dans les étiquettes
   • des groupes avec un seul élément et des listes plus longues que leur limite
   • des icônes sans mots visibles ; une icône utilisée pour deux significations
   • des barres d'outils de plus de cinq boutons ; des ensembles de commandes qui diffèrent entre des objets du même type
   • aucun marqueur pour l'emplacement actuel
   • plus d'une boîte de recherche sur un écran
   • des contrôles Afficher, Masquer ou Réorganiser offerts comme remède au fouillis
4. Proposez. Pour les paramètres : les catégories standard qui s'appliquent plus jusqu'à deux sujets produit, au maximum neuf au total, avec chaque contrôle mappé à exactement un. Pour la navigation : au maximum neuf entrées de premier niveau, le reste sous des groupes étiquetés. Pour les barres d'outils : un ensemble de commandes par type d'objet, cinq sur la barre, le reste sous Plus. Listez ce qui quitte la surface complètement et où cela va. Dites que les regroupements sont des propositions à confirmer avec un tri de cartes et un test d'arbre (cinq personnes trouvent les gros problèmes ; visez 80% de réussite des tâches), car les regroupements doivent correspondre à la façon dont les utilisateurs pensent et cela ne peut pas être lu à partir du code.
5. Ordonnez les changements de sorte que ceux que personne n'a à réapprendre viennent en premier : des mots sur les icônes et un marqueur d'emplacement actuel, puis la réduction des doublons et l'unification des noms, puis des barres d'outils cohérentes, puis le regroupement. Déplacer les choses vient tard car cela coûte quelque chose aux utilisateurs existants. Si l'adoption d'un registre est justifiée, elle vient en dernier et est proposée, pas imposée ; l'utilisateur a demandé quoi changer à l'écran.

Ordonnez les constats par combien ils nuisent à un nouvel utilisateur. Créditez ce qui fonctionne déjà : un registre existant, une recherche, une réinitialisation ou un mécanisme d'adresse est la fondation sur laquelle la correction s'appuie, et le dire évite une réécriture dont personne n'a besoin.

Construire une nouvelle surface

1. Appliquez les cinq questions à chaque élément d'abord. Une liste de souhaits de produit contient toujours des choses qui devraient être une meilleure valeur par défaut, appartenir au système, ou être des actions plutôt que des préférences. Laissez les éléments coupés en dehors du registre et listez-les dans votre résumé avec la raison, afin que l'utilisateur puisse vous contredire.
2. Écrivez les enregistrements avant tout balisage, en suivant references/record-schema.md. Si un registre existe, ajoutez-y.
3. Classez chaque enregistrement avec les sept questions (section suivante). Laissez de côté les catégories qui seraient vides. Une catégorie avec un ou deux paramètres est acceptable quand les gens la cherchent par son nom (Notifications) ; sinon, fusionnez-la avec sa voisine. Le statut d'un sujet reste sur la page de ce sujet ; seules les informations à l'échelle de l'application vont dans À propos.
4. Vérifiez les limites (ci-dessous), manuellement ou avec le vérificateur.
5. Dessinez la mise en page standard à partir des enregistrements, en suivant references/visual-design.md pour l'agencement, les tailles, les contrôles et les états, et references/patterns.md pour le comportement. En bref : liste de catégories à côté de la page sur les grands écrans et avant sur les petits ; une colonne plafonnée à environ 1 100 px ; étiquette à gauche, contrôle ou valeur actuelle à droite ; lignes connexes dans des groupes contenus ; interrupteurs pour on et off, boutons radio pour deux à cinq options, pas de bouton Enregistrer ; cibles d'au moins 24 px et 44 à 48 px pour le tactile ; contraste de texte 4.5:1 ; rien montré par la couleur seule. Chaque ligne montre sa portée et, quand elle diffère de la valeur par défaut, un marqueur de modification avec Réinitialiser. La recherche se trouve en haut. Chaque enregistrement a une adresse stable. Les actions sont séparées des préférences, les actions destructrices encore plus.
6. Dites ce que vous avez supposé : les valeurs par défaut, les portées et les propriétaires que vous avez dû deviner sont à confirmer par l'utilisateur. Utilisez unassigned pour un propriétaire inconnu ; n'inventez pas de noms d'équipe.

Les catégories standard

Posez celles-ci dans l'ordre et arrêtez-vous à la première réponse oui. L'ordre est l'arbitre.

#	La question	Catégorie
1	Est-ce à propos de qui vous êtes, comment vous entrez, ou ce que vous payez ?	Compte
2	Est-ce que cela décide quand ou comment le produit vous interrompt ?	Notifications
3	Est-ce que cela contrôle ce que d'autres personnes, d'autres applications ou le service peuvent voir, garder ou faire ?	Confidentialité et sécurité
4	Est-ce que cela existe pour qu'une personne ayant un besoin particulier puisse voir, entendre ou utiliser le produit ?	Accessibilité
5	Est-ce que cela change seulement l'apparence des choses ?	Apparence
6	Est-ce à propos de la langue, de l'heure ou des formats ?	Langue et région
7	Est-ce à propos de l'endroit où les données sont stockées, combien, ou sur quel réseau ?	Données et stockage
	Sinon : quelle fonctionnalité cela modifie-t-il ?	Un des deux sujets produit maximum (Messages, Éditeur, Lecture)

À propos (version, aide, mentions légales) est un lien au pied et n'est pas compté. Les paramètres qu'un administrateur définit pour tout le monde sont une surface séparée. Une petite application avec moins d'environ 15 paramètres utilise une seule page avec ces noms comme titres de groupe.

Ainsi, une sonnerie pour les appels est Notifications, pas Appels ; « réduire le mouvement » est Accessibilité, pas Apparence. Quand un paramètre pourrait se trouver dans deux catégories, classez-le par la première réponse oui et mettez les mots de l'autre catégorie dans ses termes de recherche. references/categories.md couvre les grands produits, les suites, la dénomination et le raisonnement.

Ces noms sont ceux que les systèmes d'exploitation utilisent déjà. Commencez par eux et ne les modifiez que lorsque les propres utilisateurs du produit, dans un tri de cartes, regroupent les choses différemment.

L'enregistrement

Champ	La question à laquelle il répond	Valeurs autorisées
id	Quel est son nom permanent ?	Un chemin en pointillés tel que chat.notifications.sound. Jamais réutilisé ou renommé.
kind	De quel type de chose s'agit-il ?	preference, action, status, list, destination, command
subject	De quel nom unique s'agit-il ?	Exactement un sujet. C'est son emplacement.
scope	Qui ou quoi cela modifie-t-il ?	item, device, account, organization
tier	Combien de personnes en ont besoin ?	everyday, standard, advanced
label, summary	Comment cela s'appelle-t-il et que fait-il ?	Une étiquette simple ; une phrase sur le résultat
search	Que taperait une personne pour le trouver ?	Synonymes, l'ancien nom, le terme de jargon
value	Quel type de valeur cela contient-il ?	Un type, avec des options ou une plage
default, default_reason	Que se passe-t-il si personne n'y touche ?	La valeur que la plupart des gens choisiraient, et pourquoi
risk	Qu'est-ce qui se casse si cela est modifié ?	safe, care (récupérable), destructive (perdu pour de bon)
owner, reviewed	Qui décide quand cela disparaît ?	Un propriétaire et la date à laquelle cela a été justifié pour la dernière fois

Les destinations et les commandes utilisent un ensemble de champs plus court. Le schéma complet se trouve dans references/record-schema.md, et assets/registry.example.json est un exemple fonctionnel.

Les limites

| Limite | Valeur | D'où cela vient |

...

[tronqué pour la traduction]