Meilleures pratiques pour les tables extra larges
J'ai une table avec une grande quantité (25+) de colonnes. À l'heure actuelle, il semble très complexe et possède un défilement horizontal. Je veux le rendre plus utile pour les utilisateurs .
Une solution consiste à regrouper les colonnes par zone (par exemple, Personnes, Heure, etc.). Cela rompt la capacité de numérisation de la table, qui est essentiellement l'objectif principal de la table:
La deuxième solution est d'avoir une fonctionnalité de basculement de colonne , car évidemment, personne ne travaille avec les 25 colonnes en même temps, donc laisser l'utilisateur décider des colonnes dont il a besoin quelque part près des colonnes elles-mêmes semble être un bon entraine toi. Dans ce cas, quel est le meilleur emplacement pour le bouton? Voici deux solutions que j'ai trouvées et je n'en aime pas particulièrement.
Au-dessus du tableau, en ligne avec la recherche:
Ou en ligne avec les en-têtes de colonne (semble bizarre, mais a plus de contexte):
Il peut également être amélioré avec quelque chose comme " index de priorité de colonne " afin de masquer ceux avec une faible priorité sur les écrans plus petits.
La troisième consiste à effectuer une recherche d'utilisateurs sur la façon dont les gens utilisent réellement la table, et peut-être à présenter son contenu d'une manière totalement différente.
J'apprécierais vraiment toutes les idées, suggestions ou autres commentaires à ce sujet.
Merci
[~ # ~] modifier [~ # ~]
Voici donc la solution dont je suis actuellement satisfait et que je vais tester:
J'ai décomposé toutes les colonnes en quatre groupes en utilisant un simple tri des cartes, plus une autre pour que l'utilisateur puisse créer la sienne.
La meilleure solution absolue que j'ai trouvée est un sélecteur de colonnes où chaque utilisateur peut choisir les colonnes qu'il souhaite voir.
De grandes grilles comme celle-ci ont tendance à se produire lorsque de nombreuses personnes différentes avec de nombreuses exigences de données différentes utilisent toutes la même grille de données à des fins différentes. D'après mon expérience, la mise en œuvre d'un sélecteur de colonnes m'a permis de masquer 75% des colonnes par défaut et a l'avantage supplémentaire de réduire considérablement le temps de chargement de la grille.
En parlant personnellement, je trouve que l'écran de gestion des messages de WordPress est assez bien organisé à cet égard, et compte tenu de sa part de marché, on pourrait affirmer qu'il est raisonnablement testé au combat:
Schématiquement au cas où ils le changeraient:
[Screen Options] [Help]
Screen title [Add New]
[Status Filters] [Search Field][Button]
[Bulk Actions] [Filtering Tools] [Short vs Detailed Switch]
List Header (with sort toggle where appropriate)
...
List items
...
List Header (with sort toggle where appropriate)
[Bulk Actions]
L'activation ou la désactivation des colonnes peut être effectuée dans les options de l'écran. Cela ouvre un panneau avec la liste des colonnes disponibles. Ou plus précisément, leurs ensembles: certains champs, par exemple créés/modifiés/statut, sont regroupés au lieu d'être affichés dans des colonnes distinctes.
Le seul problème que j'aurais à propos de leur écran est l'absence de la colonne ID. Dans la plupart des applications, l'ID est un encombrement indésirable, donc je pense que WordPress est correct de ne pas le répertorier du tout. Dans certaines applications (par exemple une application de comptabilité), cependant, montrant l'ID d'une ligne est hautement souhaitable.
25 colonnes, c'est trop oui. J'aime la deuxième solution où vous donnez à l'utilisateur le contrôle des colonnes.
J'avais une situation similaire où je pensais que certaines colonnes n'étaient pas pertinentes. Une enquête rapide m'a cependant indiqué que la plupart des utilisateurs ont examiné différentes colonnes, ce qui rend chaque colonne pertinente. Ma solution était un test rapide où je laissais les utilisateurs choisir le strict minimum de colonnes nécessaires pour donner un sens à la ligne, puis éliminer simplement le reste des colonnes. C'était une approche assez énergique, mais cela a nettoyé la conception et je n'ai pas encore reçu de plaintes concernant les utilisateurs manquant certaines colonnes (frapper sur le bois).
Mais j'avais affaire à 13 colonnes et à un nombre spécifique d'utilisateurs que je pouvais contacter facilement. Vous pourriez avoir affaire à un type de public différent, un public de tous les coins du monde/pays, un public auquel vous ne pouvez pas vous contenter de demander et de faire un test de tri des cartes avec vous. Donner le contrôle utilisateur des colonnes peut être la bonne solution dans votre situation.
Le problème est cependant comment savez-vous avec quelles colonnes et combien commencez-vous? Et comment expliquez-vous que l'utilisateur peut gérer les colonnes? Peut-être un petit test de tri des cartes? Il existe des outils qui vous permettent de trier les cartes à distance. Et peut-être changer la copie de simplement columns en manage columns?
J'aime l'idée du filtre/sélecteur de colonne, mais il pourrait y avoir encore plus de mécanismes impliqués par exemple. Mais surtout, l'utilisateur doit toujours avoir le contrôle des colonnes qui sont cachées/affichées
- prioriser (sur la base de recherches/analyses) et masquer les colonnes les moins utilisées
- révéler les colonnes en fonction de la personnalité/du rôle/du niveau d'accès
- révéler les colonnes pour qu'elles correspondent à des tâches spécifiques (la "tâche A" révèle les colonnes associées)
- laisser l'utilisateur créer ses propres préréglages personnalisés de colonnes révélées
- créer des regroupements réductibles de colonnes
Bien sûr, la mécanique exacte qui a du sens variera en fonction du contexte exact.
Et pourtant, il y a des moments où TOUTES les colonnes sont nécessaires - et il y en a trop pour s'adapter à l'espace disponible. J'ai fait face à ce problème. Masquer les colonnes ne fonctionne pas car les données sont nécessaires.
Dans un exemple, j'ai partiellement résolu le problème en réduisant le texte dans certaines colonnes. Par exemple, l'utilisateur scanne les colonnes pour savoir quel concurrent (8 concurrents == 8 colonnes) vend le produit à un prix supérieur ou inférieur à la période précédente. J'ai supprimé le prix et changé la couleur de fond de la cellule du tableau: rouge pour plus bas, vert pour plus.
Le résultat était qu'il était plus numérisable et moins d'espace était nécessaire avant (l'utilisateur pouvait obtenir plus de détails selon les besoins).
Cependant, dans ce cas, j'ai eu la chance de ne pas avoir, à première vue, besoin de connaître le prix exact du concurrent - seulement si le prix avait augmenté ou baissé.