Close Menu Navigation
Open Categories Menu Supprimons les Datagrid de 90% de nos écrans ça fera du bien… aux utilisateurs
- 7 August, 2012 -
- Ergonomie RIA, Idées -
- Tags : Datagrid, ergonomie, Expérience utilisateur, NUI, UX
- 8 Comments
L'objectif de cet article est de montrer en quoi l'utilisation intensive de Datagrid démontre une mauvaise pratique dans une majorité de cas. Nous allons démontrer ce propos à travers différents aspects de la conception logicielle.
Datagrid versus NUI
Vous ne trouverez jamais de Datagrid dans une application NUI. En effet, dans une interface naturelle tactile, on privilégie les listes personnalisées. A l'opposé d'un Datagrid, ces dernières permettent d'agencer l'information en mettant le contenu important au premier plan.
La table Surface, Windows Phone ainsi que les différentes tablettes tactiles n'ont pas de Datagrid dans leur librairie car cela serait une hérésie. Rien n'est moins naturelle que l'utilisation d'un Datagrid. Si l'utilisation d'un Datagrid est naturelle pour vous, c'est que vous avez beaucoup d'expérience en utilisation de logiciels informatiques. Attention "habitude" n'est pas la même chose que "naturelle", ce qui est naturel s'acquière durant l'expérience avec notre environnement physique dès la naissance. Ainsi, toucher, effleurer, appuyer, bouger un objet, sentir, goûter, sont des actions totalement maîtrisées par un enfant de trois ans.
Dans la vie réelle on manipule des objets concrets ayant une fonctionnalité. En environnement tactile, c'est exactement la même philosophie. Un Datagrid n'expose pas d'objets identifiables et personnifiés mais plutôt une série de lignes. Bien sur, techniquement parlant, chaque ligne est un objet. Toutefois, d'un point de vue graphique et ergonomique, cette réalité est très mal traduite par un Datagrid.
Dans l'environnement NUI, on dispose souvent de peu d'espace ou d'un espace à 360° comme c'est le cas sur la table. Le Datagrid, avec ses colonnes dont la taille est dictée par l'entête ou par le contenu est très contraignant d'un point de vue affichage. Concrètement une liste personnalisée d'éléments est plus simple à comprendre, à lire et à manipuler. Pour deux raisons, d'une part l'affichage du contenu peut facilement être mise en page et adapté au type d'objet, d'autre part on essaiera pas forcément de tout afficher tout le temps ce qui contextualisera les actions et l'usage.
En gros utiliser une liste personnalisée force une réflexion sur ce que l'on souhaite réellement afficher et faire dans la page. Cela amène plus de travail de mise en page. Un Datagrid ne fait que consommer de la donnée et l'affiche avec plus ou moins bien de succès.
Les modèles de conception ergonomiques contenus par une vue CRUD.
Bien qu'il puisse en exister d'autres, nous allons différencier 7 usages communs aux applications métiers :
- Rechercher un ou des objets
- Trouver un objet
- Filtrer une liste d'objets
- Acceder aux objets liés / relatifs
- Afficher une vue détail
- Opération unitaire comme ajouter, supprimer, imprimer, etc...
- Opération en masse comme supprimer, imprimer, modifier, etc...
Ce qui frappe au premier abord, c'est qu'un Datagrid résout une grande partie de ces usages a lui seul. C'est un premier indice inquiétant car plus un objet résout d'usages différents plus il est compliqué à interpréter et donc à utiliser. De plus on obtient une page avec un nombre d'actions et de flux d'utilisation bien trop important, concrètement une page très très technique et peu abordable par le grand public.
Le Datagrid évite de se poser tout un tas de questions concernant l'ergonomie logicielle. En termes de développement pur, c'est un peu la grosse artillerie. Quand on ne sait pas trop comment structurer le lien et la navigation entre vue de détail et vue liste, c'est une énorme facilité évitant de se poser pas mal de questions pourtant essentielles en termes d'expérience utilisateur. C'est notamment le cas pour les fonctionnalités "trouver" et "chercher".
Sans rentrer dans le détail, trouver n'est pas la même chose que chercher. Généralement on essaie de trouver un objet dont sait qu'il existe. Au contraire, lorsque l'on cherche quelque chose on est pas forcément sur de ce que l'on va découvrir. Par exemple, lorsque vous entrez dans un magasin, soit vous allez droit au but car vous savez exactement ce que vous souhaitez acheter; soit vous furetez a droite a gauche pour savoir si quelque chose correspond a votre envie. Les moteurs de recherche tels qu'ils sont conçus aujourd'hui résolvent ces deux besoins...
L'une des grandes erreurs consiste à utiliser des options de tri ou de filtre de colonnes pour trouver, car pour trouver rien de plus efficace qu'un simple champ de saisie, autocomplete ou non. Cela est largement démontré par les moteurs de recherche sur internet. On a d'ailleurs jamais vu de Datagrid comme élément de résultat dans le navigateur mais plutôt des listes personnalisées.
Lorsque l'on recherche, on ne sait pas vraiment ce que l'on va trouver. Chercher permet de se faire une idée globale de la structure d'un environnement déterminé. Cela correspond un peu à de l'exploration pure. Dans ce cas, le tri et le filtre sont vraiment intéressant et permettent de détacher des sous-ensembles que l'on va pouvoir réellement utiliser...
Quelques bonnes pratiques en matière d'ergonomie
Lorsque l'on conçoit une application, plusieurs bonnes pratiques sont à mettre en œuvre afin de simplifier au maximum les interfaces visuelles.
- Regrouper les fonctionnalités dans des zones identifiables
- Mettre l'accent sur les actions à mener dans une page
- Limiter le nombre d'actions possibles dans une page afin de simplifier ses objectifs et sa lecture
- Personnifier les objets afin de rendre leur utilisation intuitive
- Contextualiser au maximum les actions au sein d'étapes ordonnées
- Optimiser les dimensions des surfaces / zones associées à chaque usage
- créer des transitions animées logiques entre chaque étape
- fournir des invitations visuelles statiques ou dynamiques
Dans de nombreux cas, poser une simple barre d'actions et surtout un Datagrid, efface tous ces beaux principes. N'oublions pas que les Datagrid existent depuis des technologies comme Winforms et qu'ils représentent un passé révolu ne prenant pas en compte la nouvelle manière de penser une application. L'expérience utilisateur n'avait pas vraiment pignon sur rue en 2001 que ce soit dans le monde Java ou .Net 1.
Dans quels cas utiliser un Datagrid
De mon point de vue, l'utilisation d'un Datagrid dans une page n'a de légitimité que dans de rares cas :
- Il faut être dans une application métier technique dédiée à une population d'utilisateurs ciblée.
- Vous avez la nécessité de faire de l'édition en masse comme dans Excel.
- Il n'y a aucun intégrateur graphique et/ou designer dans votre équipe ce qui vous empêche de personnaliser une liste adaptée et mise en page.
- Vous devez travailler / visualiser sur des sous-ensembles d'objets à travers des options de tri et de filtre exhaustives comme dans Excel. Attention chercher n'est pas trouver, ce besoin n'est pas si fréquent.
Dans tous les autres cas, une liste personnalisée fera beaucoup mieux l'affaire qu'un Datagrid.
Mais alors pourquoi existe-t-il tant de Datagrid dans nos applications desktop ? La réponse qui me vient en premier est toute bête : il n'y a pas encore assez de designers, d'intégrateurs et d'ergonomes dans nos équipes de conception logicielle pour éradiquer ce genre de pratiques et les mauvaises habitudes ont la vie dures...
As tu des bonnes pratiques à nous conseiller ou des exemples à nous montrer pour la présentation de liste paginée ?
Merci pour cet excellent article
Lorsque l’on travaille sur des ensembles ou qu’une liste contient mille éléments, une liste sans pagination est une bonne solution car la zone de filtre/recherche suffit à obtenir un résultat pertinent sur une telle quantité. Au contraire, dès que l’on cherche un objet précis connu ou attendu sur plus de 1000 éléments, une liste paginée est une bonne pratique car on est plus intéressé par la pertinence des résultats. Du coup, la zone regroupant les mécanismes de pagination est en générale placée en bas. Dans l’ordre de lecture, du haut vers le bas, on obtient :
-zone d’option d’affichage de la liste en haut à droite ou à gauche selon les cas
-zone de recherche avec options avancées dépliables en haut à droite ou à gauche selon les cas
-zone de liste personnalisée paginée affichant n premiers résultats permettant au moins de distinguer l’aspect unique de chaque item(quelques fois plusieurs propriétés d’un type sont nécessaires à différencier les objets)
-pour finir zone de navigation en bas centrée, après lecture des résultats on décide de passer à une autre page si résultat attendu non trouvé.
J’espère que ça répond à ta question
Les 4 cas finaux correspondent à environ… 90% des applications de gestion, ce n’est donc pas si rare, mais tout dépend du métier qu’on fait. Corollaire: on va avoir du mal à faire coïncider “Windows 8 Metro” avec les applications de gestion
Hello,
J’ai pris plaisir à lire cet article, et je suis tout à fait d’accord avec toi.
J’ajouterais que même lorsque l’on croit avoir besoin d’un DataGrid, une simple ListView (avec un GridView en guise de vue par exemple) est souvent suffisant en terme de fonctionalités et bien plus performant!
Salut Simon,
le cas que j’ai peu rencontré reste la modification en masse, mais il est vrai que cela dépend beaucoup de l’environnement métier. De mon point de vue tout le reste est faisable sans Datagrid de manière simple et séquentielle ou “all in page” (selon les contraintes).
Si tu veux on en discutera autour d’un verre aux techdays à l’occaz…