Comment concevoir des tableaux responsive

Concevoir un tableau responsive consiste à préserver ses relations utiles lorsque la largeur disponible change. Faire tenir toutes les colonnes n’est qu’une solution possible. Un tableau lisible à défilement peut mieux servir une comparaison qu’une pile de cartes bien rangées qui sépare les valeurs à comparer.

Commencez par la tâche. Faut-il comparer plusieurs fiches, en trouver une, examiner ses détails ou agir sur un groupe ? La réponse détermine les informations qui doivent rester ensemble et celles qui peuvent être accessibles derrière une commande. Sans cela, les décisions responsive deviennent souvent une succession de polices réduites, de colonnes masquées et de boutons toujours plus serrés.

Les exemples détaillés utilisent une file de revues fictive comprenant nom du projet, responsable, statut, échéance et nombre de commentaires ouverts.

Trouvez la relation à préserver

Un tableau est utile parce que la position porte du sens. Vous pouvez descendre dans une colonne pour comparer des valeurs ou parcourir une ligne pour relier une fiche à ses attributs. Une transformation responsive peut préserver l’une de ces relations tout en affaiblissant l’autre.

Dans l’exemple des revues de projets, un responsable peut chercher le projet à l’échéance la plus proche qui possède encore des commentaires non résolus. La date et le nombre de commentaires doivent être visibles ensemble, avec l’identité du projet. Masquer le nombre de commentaires parce qu’il se trouve dans la dernière colonne empêche cette tâche, même si l’écran paraît plus épuré.

Une personne qui ouvre le projet dont elle doit faire la revue a un autre besoin. Le nom du projet, le statut et une action claire peuvent lui suffire, les autres détails étant disponibles ensuite. Un résumé compact avec dépliage peut fonctionner. Les données sous-jacentes sont identiques, mais la vue initiale nécessaire diffère.

Marquez ensuite les informations nécessaires à chaque tâche. Une colonne utilisée par toutes les tâches appartient à la vue principale. Un champ consulté seulement après le choix d’un élément peut être candidat à un affichage à la demande. C’est une décision éditoriale sur le travail de l’utilisateur, pas une consigne de suppression des données moins importantes.

Séparez la largeur du tableau de celle de la page

Un tableau large n’a pas besoin de faire défiler toute la page latéralement. En CSS, un conteneur overflow-x: auto peut lui donner sa propre zone de défilement, pendant que titre, description, filtres et texte environnant s’adaptent à la fenêtre. Ce conteneur doit lui-même pouvoir rétrécir dans la mise en page ; un enfant pleine largeur dans une colonne de grille rigide peut encore élargir toute la page. La zone bidimensionnelle reste ainsi limitée au contenu qui en a besoin.

L’explication du critère de redistribution du W3C prévoit une exception pour les contenus dont le sens ou l’utilisation exige deux dimensions, notamment les tableaux de données. Elle distingue aussi le tableau du contenu de ses cellules, qui doit toujours se redistribuer correctement. L’exception ne justifie pas le débordement de tous les libellés et paragraphes voisins. L’explication du critère Reflow par le W3C.

Concrètement, laissez un nom de projet long passer à la ligne dans une cellule de largeur raisonnable. Ne préservez pas une immense largeur vide simplement parce que le design de bureau l’utilisait. Un tableau peut nécessiter un déplacement horizontal pour les relations entre colonnes tout en bénéficiant de cellules dimensionnées avec soin.

Le conteneur a besoin d’une limite reconnaissable. Si la dernière colonne visible se termine exactement au bord de l’écran sans signaler la suite, on peut croire le tableau complet. Un fragment de colonne suivante, une barre de défilement visible lorsque l’environnement le permet ou une indication concise peuvent clarifier la continuation. Ne faites pas d’un fondu décoratif la seule explication.

Gardez si possible le titre du tableau et le contexte de la tâche hors de la zone défilante. Un titre comme « Projets en attente de revue » explique le point commun entre les fiches. Une note courte peut préciser le tri initial ou un fuseau horaire pertinent. Ce sont des repères, pas des colonnes supplémentaires qui devraient se disputer la place.

USWDS montre deux modèles responsive réellement différents

Le composant tableau du U.S. Web Design System propose des variantes défilantes et empilées. L’exemple défilant préserve une matrice ; l’exemple empilé présente des valeurs accompagnées de libellés au sein de chaque fiche aux largeurs étroites. Les exemples fonctionnels rendent la différence visible.

Cette différence compte davantage que le nom des composants. Une matrice rend la relation entre deux colonnes disponible par la position. Une fiche empilée répète les libellés pour permettre une lecture autonome de l’élément. Les données peuvent être identiques alors que l’effort nécessaire pour les comparer change fortement.

Essayez avec la file de revues : trouvez l’échéance la plus tardive parmi les projets qui ont plus de cinq commentaires. Dans un tableau, vous pouvez examiner ensemble les colonnes de nombre et de date. Avec des cartes, vous devrez peut-être parcourir chaque fiche en gardant le candidat précédent en mémoire. Changez maintenant la tâche en « lire le responsable et l’échéance de Cedar Lodge ». La version empilée peut être confortable, car la comparaison n’est plus centrale.

Choisissez la transformation selon son coût pour le lecteur

Pour la transmission à l’implémentation, précisez quelques invariants : l’identifiant de ligne reste disponible, l’unité reste attachée à la valeur, le champ de tri est compréhensible et la sélection garde le même périmètre après redimensionnement. Ces règles sont plus durables qu’une exigence de faire tenir toutes les colonnes de bureau sur un téléphone. Elles permettent de changer la présentation sans modifier silencieusement la tâche.

Testez les extrêmes inconfortables du modèle. Faites défiler jusqu’à droite avec un libellé de ligne long. Dépliez des fiches voisines dont les contenus ont des longueurs différentes. Sélectionnez un élément, changez la fenêtre et poursuivez la même action. Une capture initiale propre ne révélera ni un compteur de sélection périmé, ni une colonne fixe qui recouvre des valeurs, ni un panneau de détail attaché à la mauvaise fiche.

Quatre modèles responsive et leurs compromis

1. Conserver le tableau et défiler horizontalement

Le défilement horizontal est un bon candidat lorsque la tâche principale consiste à comparer des valeurs alignées et que chaque colonne reste pertinente. Il préserve la matrice au lieu de la transformer en une autre structure d’information. Il impose de naviguer dans la largeur ; rendez donc ce déplacement délibéré.

Pour le tableau de revues, placez le nom du projet près du début et gardez-le visible si l’implémentation permet une première colonne fixe fiable. Sinon, une personne qui atteint la date peut perdre l’identité de la ligne qu’elle lit. La colonne de nom fixe doit être assez étroite pour laisser de la place utile aux autres données.

Ne figez pas la moitié du tableau. Sur écran étroit, deux ou trois colonnes fixes peuvent consommer presque toute la fenêtre et laisser une mince bande pour le contenu mobile. Commencez par l’identifiant le plus petit qui préserve le contexte. Si les noms sont longs, autorisez les retours à la ligne ou utilisez judicieusement un identifiant secondaire, plutôt que de figer un bloc surdimensionné.

Les intersections fixes demandent un traitement visuel attentif. La cellule supérieure gauche peut passer au-dessus d’une ligne d’en-tête fixe et d’une première colonne fixe. Sans ordre de superposition clair et fond opaque, les valeurs peuvent transparaître ou se chevaucher. C’est un détail qui peut sembler correct sur une image et échouer pendant le défilement.

Vérifiez la navigation au-delà des gestes tactiles. Une personne au clavier doit pouvoir atteindre et utiliser la zone lorsque nécessaire, et le focus doit rester visible autour des contenus interactifs. Vérifiez le comportement implémenté dans les navigateurs et technologies d’assistance pertinents ; ajouter un contour dans une maquette ne prouve pas l’accès au clavier.

2. Afficher les colonnes prioritaires et révéler le reste

Les colonnes prioritaires conviennent lorsque la plupart des décisions courantes reposent sur un petit sous-ensemble de champs. Gardez-les visibles, puis proposez un moyen clair d’examiner les autres données. Cela peut réduire la largeur sans sacrifier la tâche principale, mais seulement si la priorité est bien choisie.

Pour une personne chargée d’une revue, le nom du projet, le statut et l’échéance peuvent constituer une vue compacte utile. Le responsable et le nombre de commentaires peuvent figurer dans une ligne dépliée. Pour un manager qui repère le travail en retard avec des commentaires non résolus, masquer ce nombre serait un mauvais choix. Il n’existe pas de liste universellement correcte de « colonnes mobiles » indépendante de la tâche.

Utilisez une commande de dépliage dont l’état ouvert est clair. Le contenu révélé doit appartenir visiblement à la bonne fiche, surtout lorsque les lignes voisines se ressemblent. Répétez le nom du projet dans un panneau de détail si son emplacement rend l’association incertaine. Évitez les libellés vagues qui laissent deviner si la commande ouvre des détails, un menu ou une nouvelle page.

N’imposez pas de dépliage pour une action nécessaire sur presque chaque fiche. Dans une file de revues, ouvrir la revue mérite peut-être une commande visible. L’enfouir parmi des métadonnées rarement consultées économise de la largeur au prix d’un travail répété. Évaluez les interactions fréquentes, pas seulement la place occupée par les champs.

Soyez explicite sur les colonnes omises. Si les utilisateurs de bureau s’attendent à un champ responsable qui disparaît en largeur étroite, l’interface doit proposer un chemin compréhensible pour le retrouver. Une vue détaillée accessible, un sélecteur de colonnes ou un résumé déplié peuvent convenir. Une suppression silencieuse change l’information disponible.

3. Transformer chaque fiche en carte avec libellés

Les fiches empilées sont utiles lorsque l’on lit un élément à la fois. Chaque valeur reçoit un libellé visible et la ligne devient un petit résumé vertical. Cela peut convenir à une liste de détails de commande ou à des rendez-vous où la comparaison entre fiches est secondaire.

Dans le tableau de projets fictif, une carte peut avoir Cedar Lodge pour titre, suivi du statut, de l’échéance, du responsable et des commentaires ouverts. C’est facile à lire comme une fiche. Mais comparer les nombres de commentaires de dix projets exige maintenant de retrouver le même libellé sur une page beaucoup plus haute.

Avant de choisir ce modèle, demandez à quelqu’un de comparer un attribut entre plusieurs fiches. S’il doit faire des allers-retours pour se rappeler les valeurs, les cartes ont échangé un déplacement horizontal contre un effort de mémoire vertical plus important. Cela peut rester acceptable, mais le compromis doit être voulu.

Gardez le même ordre libellé-valeur entre les cartes. Ne placez pas le statut en haut d’une carte et après le responsable dans une autre simplement parce qu’une valeur manque. Représentez cette absence par un texte significatif pour préserver une structure prévisible.

Évitez d’ajouter les libellés uniquement comme du contenu généré décoratif sans vérifier le résultat accessible. Un libellé « Échéance » visible et une relation disponible dans le code sont deux sujets distincts. Le balisage final doit communiquer les données de manière cohérente aux personnes qui ne regardent pas la carte visuelle.

Si la version de bureau est un tableau sémantique et que la version étroite change son affichage visuel, vérifiez que les relations du tableau restent disponibles comme prévu. S’il existe des présentations séparées dans la page, assurez-vous que le contenu masqué ne produit ni commandes en double ni lectures répétées. La transformation mérite une revue d’implémentation, pas seulement du style responsive.

4. Laisser choisir les éléments à comparer

Certains tableaux possèdent de nombreuses colonnes légitimes, mais une personne en a rarement besoin simultanément. Un sélecteur de colonnes peut aider à construire une vue utile. Un mode de comparaison dédié peut permettre de choisir quelques fiches et d’examiner ensemble les attributs pertinents.

Ces commandes ajoutent leur propre travail. Une nouvelle personne peut ignorer quelles colonnes comptent ou penser que la vue par défaut est complète. Proposez une vue initiale sensée et signalez clairement les colonnes masquées. La personnalisation doit soutenir l’expertise, pas faire dépendre la compréhension de base d’un paramétrage.

Pour le tableau de revues, la vue par défaut peut inclure projet, statut, échéance et commentaires. Un coordinateur peut ajouter le responsable, tandis qu’une personne chargée de sa propre revue peut le retirer. L’identifiant du projet doit rester disponible pour éviter des lignes de nombres sans lien.

Un mode de comparaison convient mieux au choix entre quelques alternatives qu’au traitement d’une longue file. Sélectionner trois produits pour les comparer est raisonnable. Sélectionner chaque projet pour découvrir lequel est en retard serait un détour inutile. N’ajoutez pas une commande de comparaison simplement parce que le tableau est large.

Si les utilisateurs peuvent enregistrer une vue, définissez ce qui est enregistré. Visibilité et ordre des colonnes, tri et filtres sont des préférences distinctes. Une disposition enregistrée ne doit pas conserver de manière inattendue un ancien filtre et masquer de nouvelles fiches. Dans un prototype visuel, consignez ces comportements comme exigences plutôt que de suggérer qu’une persistance existe parce qu’un bouton Enregistrer a été dessiné.

Préservez le sens des libellés, des nombres et des cellules vides

Les changements responsive révèlent souvent des conventions de contenu fragiles. Une date comme « 04/05 » est ambiguë même sur grand écran, mais le problème ressort lorsqu’il n’y a plus de place pour l’expliquer. Préférez un format adapté au public et donnez le fuseau horaire ou le contexte des dates relatives lorsqu’ils affectent la tâche.

Utilisez des unités cohérentes dans les colonnes numériques. Un nombre de commentaires ne doit pas partager son champ avec un statut textuel sans que l’en-tête et le format expliquent la différence. Alignez régulièrement les nombres comparables pour faciliter l’examen de leurs écarts. Ne réduisez pas la précision et ne supprimez pas les unités uniquement sur écran étroit sans vérifier que les valeurs gardent le même sens.

Décidez comment représenter les données absentes. « Non attribué », « Aucun commentaire » et « Indisponible » décrivent des états différents. Une cellule vide ne le fait pas. Dans l’exemple des revues, un responsable non attribué ne doit pas ressembler à un champ dont le chargement a échoué.

Les libellés longs doivent passer à la ligne si cela préserve leur sens. Les infobulles peuvent compléter le contexte, mais remplacent mal un libellé nécessaire qu’il faut retrouver sans cesse. Si un titre de colonne est trop long pour fonctionner partout, voyez si une formulation plus précise est possible avant de le tronquer.

Le tutoriel du W3C sur les tableaux explique que les cellules d’en-tête et de données nécessitent un balisage structurel et des associations adaptées. Cela soutient une navigation qui conserve le contexte au-delà de l’alignement visuel. Utilisez ces recommandations pour implémenter le modèle choisi, particulièrement lorsque les en-têtes de lignes et de colonnes contribuent tous deux au sens. Le tutoriel du W3C sur les tableaux accessibles.

Rattachez les commandes au bon périmètre

Le tri concerne une collection ; ouvrir des détails concerne une fiche ; une action groupée concerne les fiches sélectionnées. Ces périmètres doivent rester distincts quand la présentation se resserre. Compresser toutes les commandes dans le même menu peut rendre l’effet de chaque action difficile à comprendre.

Gardez l’action de ligne visuellement liée à sa fiche. Un menu tout à droite d’un grand tableau peut sortir de la vue pendant le défilement horizontal. Si ouvrir le projet est la tâche principale, un nom lié peut offrir un accès stable tandis que le menu accueille les actions moins fréquentes. Le meilleur agencement dépend de l’action qui nécessite un accès immédiat.

La sélection demande une attention supplémentaire. Une case à cocher dans une première colonne fixe peut être pratique, mais elle ne doit pas chasser l’identité de la ligne. Lorsque plusieurs fiches sont sélectionnées, montrez le nombre et précisez si la sélection couvre la page actuelle ou tous les résultats filtrés. La version responsive ne doit pas en changer discrètement le sens.

Une commande de tri doit expliquer sa direction active sans reposer entièrement sur une petite flèche. Vérifiez que le champ trié reste compréhensible lorsque sa colonne est masquée. Déplacer le choix du tri dans une commande nommée au-dessus du tableau est parfois plus clair que de le laisser attaché à un en-tête invisible.

Examinez aussi les filtres et la pagination à largeur étroite. Le tableau peut être lisible alors que la barre de filtres déborde ou que les commandes de pagination se serrent. Elles appartiennent à la même tâche, même en dehors de la grille. Testez le parcours complet, de la recherche des fiches à l’action sur celles-ci.

Faites la revue avec des contenus difficiles et de vraies tâches

Utilisez du contenu qui met la disposition à l’épreuve : un nom de projet long, un responsable non attribué, un grand nombre de commentaires, une date manquante et un statut sur plusieurs lignes. Prévoyez assez de lignes pour imposer un déplacement dans la direction du modèle. Trois fiches parfaitement uniformes révèlent très peu de choses sur un tableau responsive.

Pour la version défilante, demandez de relier une échéance tardive au nom de son projet après un déplacement latéral. Pour la version dépliable, demandez de trouver un détail puis de revenir à la fiche suivante. Pour les cartes empilées, demandez de comparer une valeur sur plusieurs projets. Ces tâches révèlent si la relation préservée est bien celle dont l’utilisateur a besoin.

Testez le zoom du navigateur en plus des largeurs d’appareils étroites. Une personne sur ordinateur qui agrandit le contenu peut rencontrer la même disposition contrainte pour une autre raison. Vérifiez la lisibilité du texte, l’accès aux commandes et l’absence de zones fixes couvrant l’essentiel de l’espace utilisable.

Dans OpenDesign, vous pouvez prévisualiser un tableau HTML à différents formats de fenêtre prédéfinis, rattacher des commentaires à une zone surchargée et affiner textes ou styles. Gardez les fiches d’exemple et la tâche choisie dans le contexte du design. Testez le balisage sémantique, le défilement au clavier, le tri et l’état enregistré dans le tableau implémenté.