Comment choisir entre cartes et listes dans une interface
Choisissez des cartes lorsqu’une personne doit reconnaître et explorer des éléments distincts. Choisissez une liste lorsqu’elle doit parcourir des attributs réguliers, retrouver un élément connu ou traiter une séquence. Si elle doit comparer de nombreuses valeurs entre plusieurs fiches, un tableau sera peut-être le choix le plus juste.
C’est un point de départ utile pour choisir entre cartes et listes en conception d’interface. Cela ne signifie pas que les produits riches en images exigent toujours des cartes, ni que les applications métier doivent toujours présenter des lignes. Une même collection peut servir plusieurs tâches, et la meilleure mise en page dépend de celle que l’écran doit faciliter.
Prenons une bibliothèque de projets web. Un designer à la recherche d’une direction visuelle reconnaîtra peut-être le bon projet grâce à sa miniature. Un chef de projet qui cherche une revue en retard a besoin du responsable, du statut et de l’échéance. Ils consultent les mêmes données, mais se posent des questions différentes. Modifier le rayon des angles d’une carte ne résoudra pas cette différence.
Identifiez ce que la personne cherche
Commencez par une action plutôt que par un composant. « Parcourir les projets » laisse trop d’éléments indéfinis. « Trouver un projet dont le style visuel convient à un client hôtelier » et « Trouver la revue prévue aujourd’hui » donnent des priorités d’information différentes et un moyen d’évaluer la présentation.
La première tâche bénéficie d’un aperçu reconnaissable. Un grand titre ne suffit pas forcément à révéler si le projet privilégie la photographie, une typographie sobre ou des illustrations colorées. La seconde exige des dates et des statuts fiables, à des emplacements prévisibles. Une miniature décorative peut occuper de la place sans aider à décider.
Notez le premier indice qu’une personne utilisera probablement. Ce peut être une image, un nom, une catégorie, un responsable ou une date. Identifiez ensuite le deuxième indice nécessaire pour confirmer la correspondance. Ces indices doivent être visibles sans ouvrir l’élément. Si l’utilisateur doit ouvrir chaque candidat uniquement pour l’identifier, la vue de collection n’en fait pas assez.
Dans son article sur les cartes, Nielsen Norman Group distingue utilement leur capacité à regrouper des contenus hétérogènes du parcours de lecture prévisible offert par une liste. L’article souligne aussi que les cartes occupent davantage de place et peuvent rendre le classement moins explicite. Examinez ces compromis plutôt que de considérer l’un des modèles comme toujours supérieur. Les cartes d’interface selon Nielsen Norman Group.
Pinterest et un exemple d’oculométrie révèlent des coûts différents
L’interface Pinterest présentée dans l’article de NN/G regroupe images, titres et informations complémentaires dans des conteneurs de hauteurs variables. Cela convient à une collection où l’image sert de repère et où chaque élément contient une quantité de matière différente. La capture ci-dessous montre cette interface historique.
Le même article présente une séance d’oculométrie durant laquelle une personne cherchait un article intéressant dans une présentation en cartes. Le tracé du regard montre des déplacements répétés entre les contenus possibles. NN/G rapproche ce comportement d’une présentation sans ordre de classement évident et où les informations comparables ne se trouvent pas toujours au même endroit.
Ces exemples révèlent deux tâches différentes. Si un visiteur choisit une image qui lui convient, l’exploration fait partie du travail. Si un opérateur cherche la fiche en retard la plus récente, retrouver la date sur chaque carte constitue un effort supplémentaire. Appeler ces deux activités « parcourir » masque la distinction qui devrait guider la présentation.
Avant de tester le style, testez l’information. Masquez les miniatures dans votre proposition de grille. Si la tâche principale devient impossible, les images apportent probablement des éléments indispensables. Si elle devient plus facile parce que les dates et les statuts ressortent mieux, les images font peut-être concurrence au travail.
Déterminez ce qui doit être visible avant d’ouvrir un élément
| Tâche | Indice décisif | Première présentation à tester | Échec à surveiller |
|---|---|---|---|
| Reconnaître une direction visuelle | Aperçu significatif | Cartes | Images décoratives ou trop petites pour identifier le contenu |
| Trouver la prochaine revue en retard | Échéance et statut | Lignes alignées | Champs essentiels à des emplacements variables ou nécessitant l’ouverture de chaque élément |
| Retrouver un projet connu | Nom et champ permettant de lever l’ambiguïté | L’une ou l’autre, avec des repères textuels clairs | Troncature rendant des noms distincts identiques |
| Sélectionner plusieurs fiches pour une même action | Identité et état de sélection | Lignes avec sélection explicite | Clic qui ouvre l’élément au lieu de le sélectionner |
Pour comparer les possibilités, utilisez les mêmes fiches, filtres et actions disponibles. Demandez à une personne de trouver un élément en retard et à une autre de reconnaître une direction visuelle, en alternant la présentation montrée en premier. Relevez les sélections erronées, les visites inutiles dans les fiches détaillées et la perte de repères au retour. Préférer l’écran le plus beau fournit une information utile sur son apparence, mais ne dit pas quelle présentation sert le mieux la tâche.
Lisez le contenu avant de choisir son conteneur
Prenez un petit échantillon de vraies fiches, y compris les moins pratiques. Dans notre bibliothèque, il pourrait comprendre un titre court, un titre long, une miniature manquante, un projet archivé et un projet sans responsable. Le contenu vous en apprendra davantage sur la bonne présentation qu’un écran rempli de rectangles factices identiques.
Une collection au contenu très variable peut bénéficier de cartes, car chaque élément y forme un résumé cohérent. Une collection où les mêmes champs se répètent sur chaque élément plaide davantage pour une liste. Aucune de ces observations ne suffit à trancher, mais elles indiquent ce que le design doit accueillir.
Prêtez particulièrement attention aux médias manquants. Si la plupart des fiches ne possèdent pas d’image significative, une grille de cartes devient souvent une galerie de substituts répétitifs. La présentation promet une reconnaissance visuelle, tandis que le contenu impose une recherche textuelle. Envisagez une liste donnant la priorité au texte ou de petites miniatures facultatives plutôt qu’une variation décorative artificielle.
À l’inverse, une liste qui réduit un portfolio visuel à des noms de fichiers peut retirer des informations nécessaires. « Project 14 » et « Project 15 » peuvent être des noms exacts, mais de mauvais repères. Ajouter un aperçu utile pourrait être plus important qu’augmenter le nombre de lignes affichées à l’écran.
Exemple détaillé : une bibliothèque, deux vues initiales
Imaginons six projets fictifs : Cedar Lodge, Harbor Rooms, Studio North, Maple Clinic, Archive House et Lumen Shop. Chaque fiche possède une miniature, un responsable, un statut de revue et une échéance de revue. Aucun de ces champs ne change avec la présentation.
Pour l’exploration visuelle, mettez la miniature en évidence, avec le nom du projet juste en dessous. Ajoutez une catégorie courte et un statut discret. Le responsable peut rester visible avec moins de poids s’il aide à déterminer qui contacter. Ne remplissez pas la carte de toutes les métadonnées du projet simplement parce qu’elles existent.
Pour gérer les revues, commencez par une ligne compacte. Placez le nom du projet et éventuellement une petite miniature au début, puis le statut et l’échéance à des positions constantes. Une action précise, comme ouvrir la revue, peut rester visible. Une description décorative du style visuel est moins utile dans ce contexte.
Les deux vues n’ont pas besoin de montrer exactement les mêmes champs. Elles doivent en revanche décrire les mêmes objets de manière cohérente. Si un statut s’appelle « Prêt pour la revue » dans une vue et « En attente » dans l’autre, on peut croire que le changement de vue a modifié l’état du projet.
La vue initiale doit correspondre à l’objectif principal de l’écran. Une page de découverte peut commencer par des cartes. Une file de revues peut commencer par des lignes. Proposer un sélecteur ne dispense pas de choisir une valeur par défaut pertinente : beaucoup de personnes utiliseront la première présentation rencontrée.
Faites en sorte que chaque vue serve sa tâche
Cartes : établissez un ordre interne clair
Une carte a besoin d’un parcours de lecture. Décidez quel élément identifie le contenu, lequel l’explique et lequel déclenche une action. Lorsque miniature, titre, pastille, auteur, liste d’étiquettes et bouton réclament tous autant d’attention, la carte devient un petit tableau de bord plutôt qu’un résumé utile.
Dans la version d’exploration de la bibliothèque, la miniature et le titre doivent établir l’identité. La catégorie facilite l’interprétation. Le statut et le responsable sont des informations complémentaires. Vous pouvez exprimer cet ordre par la taille, la graisse, la proximité et la sobriété, sans attribuer une couleur différente à chaque champ.
Placez les informations comparables à des endroits comparables. Même lorsque les cartes sont conçues pour l’exploration, les utilisateurs peuvent vouloir vérifier un même détail sur plusieurs candidats. Gardez le statut dans la même zone et adoptez un format de libellé constant. Une description légèrement plus courte constitue souvent un meilleur compromis qu’un déplacement imprévisible des métadonnées importantes.
L’image doit justifier sa place. Une capture trop petite pour révéler la mise en page n’est pas nécessairement plus utile qu’une absence d’image. Recadrez autour d’un détail distinctif, utilisez un rapport largeur/hauteur stable lorsque c’est pertinent et évitez des cadrages arbitraires qui donnent à la grille un aspect plus chargé que les projets eux-mêmes.
L’absence d’image doit être un état prévu. Utilisez une solution discrète qui préserve l’identité grâce au titre et à la catégorie. Ne la rendez pas si voyante que les fiches sans image deviennent les éléments les plus remarquables de la collection.
Les cartes ont aussi besoin de limites perceptibles, mais un contour épais et une ombre profonde sur chacune sont parfois inutiles. L’objectif est de rattacher l’information à son élément. Laissez les espacements et un traitement de surface modeste faire ce travail avant d’ajouter des décorations. Examinez toute la collection : un traitement réussi sur une carte peut devenir répétitif sur vingt.
Listes : conservez un parcours de lecture fiable
On perd facilement l’avantage d’une liste lorsque chaque ligne possède une structure différente. Gardez l’élément d’identification à une place stable et définissez l’ordre des champs complémentaires. Une personne doit pouvoir descendre dans la collection sans réapprendre la structure à chaque ligne.
Dans la file de revues, placez le nom du projet en premier. Disposez le statut et l’échéance de façon à pouvoir les retrouver sans effort répété. Si le tri repose sur l’échéance, laissez-la visible. Trier selon un champ masqué pousse les lecteurs à chercher une logique qu’ils ne peuvent pas voir.
La densité concerne la lecture et l’interaction ; ce n’est pas un concours du plus grand nombre de fiches à l’écran. Les lignes ont besoin d’assez de place pour distinguer les noms et utiliser les commandes confortablement. Si une densité accrue fait fusionner responsable et statut dans une même ligne grise, les fiches supplémentaires visibles n’apportent peut-être rien.
Utilisez la seconde ligne à bon escient. Elle peut porter une description courte ou une information distinctive, comme le nom de l’espace de travail. Évitez de reformuler le titre. Dans une bibliothèque de projets, « Projet web pour Cedar Lodge » sous « Site web Cedar Lodge » ajoute de la longueur, mais peu d’information pour reconnaître le projet.
Une liste peut contenir des images. Une petite miniature significative peut aider à reconnaître une fiche tout en conservant une structure de ligne prévisible. La question est de savoir si l’image doit dominer l’élément, pas si une liste a le droit d’en contenir une.
Lorsqu’une ligne accumule plusieurs champs alignés que les utilisateurs comparent activement, demandez-vous si vous avez conçu un tableau. Ce n’est pas un échec. Un tableau peut rendre les relations explicites grâce aux en-têtes et faciliter directement la comparaison. L’appeler liste ne fait pas disparaître les relations entre ses colonnes.
Définissez le comportement au clic avant de tout rendre cliquable
Une carte peut ouvrir un élément, proposer un menu, comporter un bouton de favori et afficher un lien de catégorie. Chaque action supplémentaire complexifie la surface. Le designer doit expliquer ce qui se passe lorsque l’on sélectionne l’image, le titre, une zone vide ou une commande secondaire.
Prévoyez une destination principale claire. Si le titre ouvre le projet tandis que la miniature ouvre une visionneuse d’images, cette différence doit avoir une raison et être compréhensible. Sinon, deux éléments visuellement liés se comportent comme des liens sans rapport. Le même problème existe dans une ligne dont le nom et le fond conduisent à des écrans différents.
Le design system du W3C documente des cartes à liens distincts et des cartes dont toute la surface sert de lien ; il rappelle aussi que le niveau de leurs titres doit s’intégrer à la page environnante. Un rappel utile : une carte visuelle n’impose pas un modèle d’interaction unique. Les modèles de cartes du W3C.
Pour notre exemple de projets, un titre lié et un menu séparé constituent un point de départ compréhensible. Si l’implémentation étend la zone cliquable principale, vérifiez que le menu fonctionne toujours indépendamment et que le texte peut être sélectionné au besoin. Ne créez pas de liens imbriqués et ne transformez pas chaque fragment de texte en arrêt supplémentaire au clavier.
Sélectionner et ouvrir sont deux actions différentes. Une personne qui choisit plusieurs projets pour une action a besoin d’un état de sélection visible et d’un moyen clair d’en sortir. Ne faites pas du premier clic une sélection dans une vue et une ouverture dans l’autre sans changement de mode explicite. Changer de vue doit modifier la présentation, pas redéfinir discrètement le comportement de base.
Notez les attentes au clavier en même temps que celles au pointeur. Où va le focus ? Quel élément ouvre la fiche ? Comment atteint-on le menu secondaire ? Une capture ne peut pas répondre à ces questions : intégrez-les à la revue d’interaction plutôt que de supposer qu’une hiérarchie visuelle claire garantit des commandes claires.
Proposez un changement de vue seulement si les deux vues sont utiles
Un sélecteur cartes/liste apporte de la valeur lorsque le même public alterne réellement entre reconnaissance visuelle et lecture rapide. Il apporte peu si une vue n’est qu’une version moins bonne de l’autre. Maintenir deux vues double aussi le nombre d’états de contenu et de détails d’interaction à traiter.
Si vous ajoutez un sélecteur, conservez les filtres, le tri et la collection sélectionnée. Une personne qui limite la bibliothèque aux projets en attente de revue ne doit pas retrouver tous les projets après avoir choisi la liste. Le sélecteur modifie la représentation des résultats, pas les critères auxquels ils répondent.
Préservez la sélection lorsque cela a du sens et rendez les limites explicites. Si les actions groupées n’existent qu’en liste, expliquez-le plutôt que d’abandonner silencieusement les éléments sélectionnés. Mieux encore, examinez si l’action peut rester cohérente dans les deux présentations.
Utilisez une commande avec un libellé et un état actif visible. Les icônes de grille et de lignes peuvent aider, mais leur forme seule n’explique pas toutes les présentations. Un libellé court comme « Cartes » ou « Liste » clarifie le choix, surtout lorsque les vues deviennent visuellement proches sur un écran étroit.
Pensez aux personnes qui reviennent. Mémoriser leur préférence de vue peut être utile dans le produit implémenté, mais ne doit pas prendre le pas sur un changement de tâche. Une file de revues et une galerie publique d’inspiration n’ont pas nécessairement besoin d’une préférence globale commune. Définissez sa portée plutôt que de laisser la persistance produire un comportement accidentel.
Préservez la tâche sur un écran étroit
Sur téléphone, une grille devient souvent une seule colonne. Cela n’en fait pas automatiquement une liste utile. La carte peut continuer à consacrer presque tout l’écran à une image, tandis que le champ nécessaire à la tâche se trouve bien plus bas. Réexaminez la hiérarchie de l’information après le changement de disposition.
Pour l’exploration, un aperçu généreux peut rester approprié. Pour la file de revues, un résumé compact avec une date lisible peut être plus utile. Ne masquez pas le champ décisif pour la tâche simplement parce qu’il se trouvait dans la dernière colonne à droite sur ordinateur.
Laissez les champs secondaires passer à la ligne ou se déplacer sur une seconde ligne dans un ordre défini. Un statut ne doit pas devenir un point coloré sans explication uniquement pour gagner de la place. Si un champ doit être révélé à la demande, déterminez si les personnes peuvent encore accomplir la tâche principale sans ouvrir chaque élément.
Les noms longs sont particulièrement révélateurs. Utilisez deux noms de projets réalistes qui commencent par les mêmes mots et diffèrent vers la fin. S’ils sont tronqués en textes identiques, la présentation étroite a perdu sa capacité à identifier les fiches. Ajustez les retours à la ligne, la largeur disponible ou le champ d’identification visible avant de réduire la taille des caractères.
Vérifiez séparément la zone d’action. Un bouton de menu facile à utiliser dans une ligne large peut se retrouver coincé contre un titre ou une case à cocher. Une carte à trois petites commandes devient particulièrement malcommode quand sa largeur diminue. Retirez les actions facultatives de la surface immédiate si cela simplifie la tâche, tout en conservant un accès clair à ces actions.
Comparez liste et grille avec de vraies tâches de recherche
Ne demandez pas seulement quelle présentation les participants préfèrent. Donnez-leur une tâche dont la réponse est observable. Dans la bibliothèque, l’exploration visuelle pourrait consister à trouver un projet hôtelier à la direction sobre. La recherche d’un élément connu pourrait viser Archive House. La consultation administrative pourrait demander la revue à l’échéance la plus précoce parmi celles attribuées à une personne donnée.
Utilisez un contenu équivalent dans les deux présentations. Si l’une propose de meilleures miniatures, des textes plus courts ou des filtres plus utiles, vous comparez davantage que la disposition. Ces améliorations peuvent valoir la peine, mais elles ne prouvent pas que les cartes ou les listes sont intrinsèquement meilleures.
Observez les hésitations. Ouvrir sans cesse les fiches pour découvrir un statut absent suggère un problème de contenu. Perdre sa place en revenant d’une fiche suggère un problème de navigation. Sauter la deuxième rangée d’une grille peut signaler un problème d’ordre visuel. Chaque observation appelle une modification différente.
Ajoutez une tâche qui met votre proposition préférée à l’épreuve. Si vous privilégiez les cartes, testez une recherche portant sur un champ répété. Si vous privilégiez les listes, testez la reconnaissance visuelle parmi des éléments aux noms proches. L’objectif est de révéler le coût de votre choix pour décider s’il est acceptable, pas de faire approuver la première maquette.
Vous pouvez construire et examiner des variantes de mise en page HTML dans OpenDesign, utiliser les formats de fenêtre prédéfinis pour observer leur comportement visuel et rattacher des commentaires à une carte ou une ligne précise. Conservez les fiches et les exigences dans le contexte du design afin que les modifications reposent sur une base stable. Testez la recherche, les préférences enregistrées et la persistance de sélection dans le parcours implémenté.