Liste par rapport à la conception de table
L'incapacité des tables à traiter des données qui s'étendent sur plusieurs lignes, en particulier dans les situations où l'espace d'écran est limité est une raison particulière pour laquelle les vues de liste ont été utilisées comme alternative pour afficher des informations. La popularité de la conception plate/métro qui utilise le style d'affichage des informations sur les cartes/tuiles a également entraîné l'utilisation de la vue liste pour afficher des données plus complexes.
Bien que l'utilisation des tableaux soit bien définie en termes de structure de données et de détails d'implémentation, les spécifications d'une vue de liste semblent être moins détaillées. Certaines vues de liste sont statiques comme un tableau tandis que d'autres peuvent déclencher l'affichage d'informations supplémentaires. De plus, les niveaux de hiérarchie des vues de liste peuvent varier considérablement tandis que les tables ont généralement la ligne d'en-tête et les lignes de données.
En dehors des problèmes d'implémentation qui ont été traités sur StackOverflow et des problèmes d'accessibilité spécifiques, y a-t-il d'autres considérations quand il s'agit de choisir entre la conception de liste ou de table?
Sont-ils considérés comme des équivalents logiques (il s'agit donc d'une préférence de traitement visuel ou cognitif) ou répondent-ils à des types spécifiques d'affichage d'informations (auquel cas nous devrions fournir de meilleures directives pour savoir quand utiliser quel type)?
Une question connexe sur la vue Tile versus List/Table fournit également quelques idées intéressantes.
1) Un aspect important est qu'une disposition en mosaïque facilite l'analyse des éléments un par un (a) tandis qu'un tableau facilite la comparaison des éléments (b):
a) Le pouvoir d'obtenir toutes les données autour d'un élément de contenu dans un élément de mise en page séparé ne doit pas être sous-estimé. L'analogie entre les deux entités facilite beaucoup la concentration et l'évaluation complète des données. Dans un tableau, la forme d'intrusion des lignes voisines distraira et le fait que vous devrez vous envoyer un regard sur l'en-tête chaque fois que vous n'êtes pas certain de la colonne que vous regardez fait du tableau un mauvais choix si cela est la tâche principale.
b)
Les tables, si elles sont implémentées ainsi (et elles devraient vraiment l'être), peuvent être classées selon les valeurs de n'importe quelle colonne (asc ou desc) sélectionnée par l'utilisateur. Cela permet de classer très facilement les éléments selon différents attributs, ce qui est très pratique dans les scénarios de comparaison. Cela peut également être réalisé avec une disposition en mosaïque ou en liste en ajoutant une fonction de tri "externe". Cependant, même si la fonction de tri peut mettre les éléments dans le bon ordre, il est beaucoup plus difficile d'analyser les valeurs particulières que vous avez triées, car cette valeur ne sera pas alignée verticalement les unes sur les autres; ils seront toujours dans leur tuile respective et les yeux devront sauter entre les tuiles plutôt que de simplement scanner une colonne.
2) Les tuiles sont de meilleurs conteneurs pour les médias. Un tableau avec des images plus grandes devient rapidement inutilisable, ou au moins perd ses avantages dans le classement/comparaison.
) Dans un tableau, les en-têtes sont affichés une seule fois (dans la barre d'en-tête). Dans une disposition de tuiles, le concepteur doit soit concevoir le contenu de sorte que les valeurs soient suffisamment claires par elles-mêmes, sans même avoir besoin des en-têtes pour expliquer les valeurs, soit les en-têtes doivent être inclus dans chaque tuile. Cette dernière étant très consommatrice de biens immobiliers, elle se prête à une conception désordonnée avec une mauvaise numérisation.
Je ne peux pas donner de réponse globale, mais il y a un cas très important où le tableau est supérieur.
Parfois, nous avons beaucoup d'éléments également structurés (c'est une condition préalable importante!) Et nous devons afficher beaucoup d'informations sur un élément dans une interface utilisateur qui prend en charge plusieurs tâches (ou plusieurs scénarios de la même tâche), mais une seule pièce est pertinente pour un tâche donnée. Là, un tableau fournit à l'utilisateur le moyen idéal pour suivre uniquement les informations dont il a besoin. La requête de recherche visuelle est très simplifiée par opposition à un affichage de liste.
Un exemple: un manager veut voir s'il y a des irrégularités dans la production. Il tire un tableau des numéros de KPI pour les 30 derniers jours. Il a 30 lignes et une colonne par KPI. Le gestionnaire se concentre désormais sur le pourcentage de produits ratés par jour (une requête de recherche visuelle). Si cela semble inhabituel, il fait deux comparaisons. Tout d'abord, il regarde d'autres numéros de la même ligne, pour voir s'ils expliquent le nombre élevé de ratés (une autre requête de recherche visuelle). Deuxièmement, s'il ne trouve aucune explication directe, il recherche d'autres lignes avec le même nombre de ratés (encore une autre requête de recherche visuelle) et compare les numéros des lignes avec un taux de raté similaire, pour voir si les autres numéros correspondent également, en recherchant un modèle commun (requête visuelle numéro quatre).
Si vous avez cela dans un tableau, la position des éléments nécessaires pour chacune de ces requêtes de recherche varie dans une seule coordonnée, x ou y, afin que notre responsable puisse suivre une ligne droite et faire quelques arrêts en cours de route. C'est beaucoup plus facile que lorsque vous faites cela dans une liste. Dans une liste, les coordonnées x et y d'un élément varient. Même s'ils varient selon un schéma cohérent (ce qui n'est pas toujours le cas), la coordination oculaire nécessaire pour passer à l'élément suivant est beaucoup plus complexe. Cela peut être encore plus compliqué que la charge cognitive de trouver un nombre est élevée et que la personne ne peut pas en traiter suffisamment à la fois avec l'œil. Il n'y a aucun moyen pour que seules les informations pertinentes "apparaissent" à la fois dans la mémoire de travail et pour la personne de voir les déviations du modèle en un coup d'œil.
Donc, si vous vous attendez à ce que votre table soit toujours lue ligne par ligne, cet argument n'est pas très pertinent. Une liste pourrait être encore meilleure, je n'en suis pas sûr. Mais si vous vous attendez à ce que votre table soit lue dans les colonnes ou que l'utilisateur fasse des comparaisons de lignes simples, les données tabulaires sont meilleures.
Notez que pour un sous-ensemble des tâches de recherche de modèle possibles (mais pas toutes), un graphique, ou en fait un certain nombre de graphiques (un par colonne de tableau) sera supérieur à la fois à un tableau et à une liste.