La philosophie de design de Great Tables

 (posit-dev.github.io)
3 points par GN⁺ 2024-04-05 | 1 commentaires | Partager sur WhatsApp
  • Great Tables est un package de création de tableaux qui vise à retrouver la finesse expressive des tableaux imprimés du milieu du XXe siècle, tout en maintenant le flux d’analyse de données dans du code Python
  • Un tableau n’est pas une simple grille de lignes et de colonnes : c’est une forme de représentation de l’information qui, grâce à l’ordre des colonnes, aux libellés et aux séparateurs, facilite la recherche et la comparaison des valeurs
  • Des tablettes d’argile sumériennes au Manual of Tabular Presentation, les tableaux ont fait évoluer ensemble densité d’information et forme, mais les premiers tableurs manquaient d’expressivité par rapport à leur facilité de calcul
  • Great Tables décompose un tableau en 6 composants et sépare structure, formatage et styling via des API des familles tab_*, fmt_* et opt_*()
  • Le package se concentre moins sur l’exploration interactive de gros volumes que sur l’amélioration de la qualité de publication et de présentation des tableaux récapitulatifs statiques destinés aux articles, livres et rapports

Le dilemme de création de tableaux que Great Tables cherche à résoudre

  • Les tableaux sont importants à l’étape finale de présentation de l’information, comme les graphiques, et concevoir un tableau efficace exige plus de précision et de nuances qu’on ne l’imagine
  • Aujourd’hui, les personnes qui travaillent avec des données doivent généralement faire un compromis entre deux options
    • Copier les données dans un outil comme Excel et recréer le tableau
    • Afficher tel quel un tableau non peaufiné
  • Great Tables est un package qui cherche à résoudre ce dilemme avec une interface fondée sur du code Python
  • L’objectif est de tout traiter dans Python, de la collecte des données à l’analyse et à la génération de tableaux récapitulatifs, tout en produisant des tableaux expressifs

Définition de base d’un tableau et éléments de lisibilité

  • Un tableau peut se résumer à deux règles fondamentales
    • Les données sont représentées en colonnes et lignes
    • Les données sont principalement représentées sous forme de texte
  • L’exemple de tableau place les personnes en lignes, et des caractéristiques comme le nom, l’adresse, la ville, le code postal, la date de naissance, la taille et le poids en colonnes
  • Cette disposition facilite la recherche de valeurs individuelles et les comparaisons entre lignes et colonnes
  • Les lignes horizontales entre les lignes ne sont pas indispensables, mais elles renforcent la distinction visuelle entre les lignes individuelles
  • L’ordre des colonnes a lui aussi un effet direct sur la lisibilité
    • Si la colonne Name se trouve tout à droite, le sujet de chaque enregistrement n’apparaît pas immédiatement, ce qui peut rendre la lecture plus confuse
    • Les libellés de colonnes indiquent quelles données se trouvent dans chaque colonne et, dans la plupart des cas, réduisent les conjectures

Histoire ancienne des tableaux

  • Les tableaux partent d’une grille carrée, un conteneur capable de recevoir de l’information
  • Sur les parois des grottes de Lascaux et de Niaux, en France, on trouve des représentations en grille datant d’environ 25 000 ans
  • Au IIe siècle avant notre ère, Hipparque représentait les positions célestes et terrestres par latitude et longitude, et vers 150 de notre ère, la Geographia de Ptolémée incluait des méthodes de cartographie utilisant une grille
  • La centuriation romaine était un système d’arpentage formant une grille carrée à travers routes, canaux et terres agricoles
  • Après la diffusion de l’agriculture il y a environ 10 000 ans, le besoin d’enregistrer et de gérer les transactions économiques liées à l’agriculture, à l’élevage et à la division du travail s’est accru

Structure des tableaux en Sumer et en Mésopotamie

  • Au IVe millénaire avant notre ère, les villes mésopotamiennes commerçaient avec des royaumes lointains et devaient conserver des registres ; des tablettes d’argile trouvées à Uruk conservent des tableaux précoces mais sophistiqués
  • Une tablette d’Uruk datant d’environ 3200 à 3000 avant notre ère consigne les quantités d’orge et de malt livrées pour la production de bière
    • La structure se lit de droite à gauche
    • Chaque case contient des idéogrammes représentant des mots ou des concepts, ainsi que des nombres représentant les quantités
    • Environ deux lignes correspondent chacune à une personne
    • Les deux colonnes de droite contiennent les quantités de malt et d’orge
    • La troisième colonne indique le sous-total par personne, et la colonne tout à gauche affiche le total
    • La ligne du bas contient le nom du responsable chargé du dossier, fonctionnant comme un pied de tableau
  • Environ mille ans plus tard, une tablette du temple d’Enlil à Nippur contient les sources de revenus et les dépenses mensuelles de 50 membres du personnel du temple
    • On y voit une grille plus régulière
    • Elle comporte des en-têtes de colonnes sous forme de noms de mois et des en-têtes de lignes sous forme de noms de personnes et de métiers
    • Elle inclut des cellules vides sans information, des valeurs numériques, des sous-totaux semestriels, des totaux et des notes explicatives
  • Par la suite, le support des tableaux est passé de l’argile aux tablettes de cire, au papyrus puis au papier, tandis que les techniques d’écriture et le design des tableaux évoluaient également

L’apogée du design de tableaux au milieu du XXe siècle

  • Le milieu du XXe siècle est présenté comme une période particulièrement forte pour le design de tableaux
  • Les technologies de production documentaire comme l’impression offset, la machine à écrire et le varitype avaient suffisamment progressé pour composer avec précision les éléments d’un tableau
  • L’espace sur la page restait contraint, mais il existait diverses solutions pour faire tenir un tableau sur une page ou le répartir sur plusieurs pages
  • La combinaison de techniques d’impression avancées et de connaissances en design de tableaux permettait de créer de beaux tableaux
  • Le Manual of Tabular Presentation du Bureau du recensement des États-Unis est un travail qui traite en détail de la conception idéale des tableaux à forte densité d’information
    • Il nomme et décrit rigoureusement les différentes parties d’un tableau
    • Il formule des recommandations fermes sur ce qu’il faut faire ou éviter dans de nombreuses situations de création de tableaux
    • Il montre qu’un tableau peut être agréable à lire tout en contenant beaucoup d’informations
  • Great Tables reprend largement les principes de design de tableaux de ce document, en partant du principe qu’ils restent valables aujourd’hui

Recul et limites après les tableurs

  • Dans les années 1970 et 1980, avec l’accessibilité croissante de l’informatique, les gens ont pu créer des tableaux sous forme électronique et imprimée
  • On peut considérer que la popularisation des tableaux calculables a commencé en 1979 avec VisiCalc
  • VisiCalc permettait de calculer rapidement des valeurs, mais son expressivité était limitée pour créer des tableaux destinés à être présentés
    • Il n’était pas possible d’appliquer aux cellules de la grille des styles de bordures adaptés à une présentation
    • Il n’était pas possible de formater les valeurs
    • Il n’était pas non plus possible d’imprimer les tableaux
  • Au cours des 10 à 15 années suivantes, les tableaux de tableurs sont devenus plus agréables visuellement
    • Au début des années 1990, Excel permettait d’appliquer des bordures aux tableaux
    • La prise en charge de la typographie s’est améliorée
    • Les fonctions de formatage des valeurs sont également devenues plus complètes
  • Malgré cela, les tableaux Excel des 30 dernières années sont jugés difficiles à porter au niveau du Manual of Tabular Presentation
  • À mesure que l’analyse de données s’est aussi pratiquée en dehors d’Excel, trois scénarios inefficaces sont apparus
    • Réaliser à la fois l’analyse et la génération de tableaux dans Python, mais avec une faible qualité de tableau
    • Réaliser à la fois l’analyse et la création de tableaux dans Excel, mais avec une faible flexibilité d’analyse
    • Analyser dans Python puis copier dans Excel pour créer le tableau, mais sans reproductibilité

Le modèle de tableaux de Great Tables

  • Great Tables est un package Python qui cherche à combiner l’élégance des tableaux du milieu du XXe siècle avec la puissance d’une interface par code
  • Il représente un tableau comme la combinaison de 6 composants indépendants
    • Table Header : un espace pour placer un titre et un sous-titre qui décrivent brièvement le contenu du tableau
    • Column Labels : définissent le contenu de chaque colonne ; un spanner est un titre placé au-dessus de plusieurs groupes de colonnes
    • Stub Head : zone située en haut à gauche, où l’on peut placer différents types de libellés
    • Row Stub : zone destinée aux informations de ligne et aux libellés de groupes de lignes
    • Table Body : zone contenant les cellules, où se trouvent les données
    • Table Footer : espace contenant des informations supplémentaires liées au contenu du tableau
  • Great Tables s’utilise en créant le corps du tableau par code, puis en ajoutant itérativement le styling, le formatage et d’autres composants
  • L’exemple de code commence par GT(simple_table, rowname_col="Name"), puis ajoute un titre, un stub head, des column spanners, une note de source, des formats de date et d’entiers, ainsi que des options de style
  • Dans l’exemple de tableau, le row stub bleu sépare les libellés de lignes du corps du tableau
    • Comme chaque personne constitue une observation unique, le sujet de la ligne est mis en avant
    • Le titre décrit le contenu du tableau
    • Les spanners Location et Personal Characteristics regroupent les colonnes en ensembles significatifs
    • L’usage cohérent d’une ligne bleue et d’un arrière-plan de cellule donne un aspect professionnel
  • Les méthodes qui ajoutent des composants au tableau commencent par tab_

Formatage et nanoplots

  • La seule structuration du tableau ne suffit pas, car chaque domaine a ses propres exigences d’affichage des valeurs
  • Même un simple nombre peut s’afficher de différentes manières selon les normes et les attentes d’une communauté
  • Si l’on ajoute les dates, les heures et les devises, le champ du formatage s’élargit encore
  • La valeur brute 134,000 peut être représentée différemment selon les besoins
  • Lorsque les valeurs doivent être transmises sous forme d’image ou de graphique, la question du formatage devient encore plus importante
  • Si un analyste médical doit communiquer les tendances d’amélioration ou de détérioration des résultats d’examens d’un patient, lire une séquence de nombres sur toute une ligne peut ralentir l’interprétation
  • fmt_nanoplot() fournit de petites visualisations de tendance dans le tableau grâce aux nanoplots
    • En survolant les points de données, on peut voir la valeur de chaque date
    • Les nanoplots visent un équilibre entre l’interprétation visuelle rapide d’un graphique et la compacité d’un tableau
  • Les méthodes de formatage de Great Tables commencent par fmt_
  • Le package cherche à fournir de nombreuses méthodes de formatage et des options utiles pour répondre aux besoins d’utilisateurs variés

Priorité aux tableaux récapitulatifs statiques pour publication et présentation

  • Parmi les différentes façons d’interagir avec les tableaux, Great Tables se concentre sur l’affichage destiné à la publication et à la présentation
  • Dans l’analyse de bases de données, un affichage simple de tableaux permettant d’explorer et de filtrer des centaines, des milliers, voire davantage d’enregistrements peut être adapté
  • Publier des résultats est une autre tâche, où la structuration, le formatage et le styling sont centraux
  • Un bel affichage de tableau doit remplir les conditions suivantes
    • Rendre l’information plus facile à assimiler
    • Fournir du contexte supplémentaire là où c’est nécessaire
    • Respecter le style d’un document ou d’une organisation
  • Le cas d’usage visé est la présentation de données telle qu’on la voit dans les articles de revues, les livres et les rapports
  • Great Tables considère les tableaux récapitulatifs statiques comme un domaine méritant une attention dédiée, et cherche à faciliter la production de meilleurs tableaux pour les lecteurs via les méthodes opt_*()
  • Le critère de succès du package est la qualité des tableaux qu’il permet de produire, et le travail d’amélioration de l’API se poursuivra
  • Un serveur Discord est ouvert pour recueillir les retours de la communauté

À lire aussi

1 commentaires

 
GN⁺ 2024-04-05
Commentaires sur Hacker News
  • Great Tables a fait un travail vraiment remarquable du côté des tableaux Python/Jupyter, au point de sembler presque en train de créer une grammaire des tableaux, à l’image de la grammar of graphics
    J’aimerais que davantage de projets expliquent leur philosophie et leurs objectifs de cette façon
    J’ai créé une autre bibliothèque de tableaux pour Jupyter, Buckaroo, mais avec une approche différente
    Buckaroo vise à permettre un travail interactif, en essayant rapidement plusieurs formats et fonctions de post-traitement pour extraire les insights importants d’un tableau
    Lors d’une analyse exploratoire de données basique, on finit par retaper sans cesse les mêmes commandes, donc je pensais que ces commandes et ces insights devaient être intégrés dans le tableau lui-même
    Great Tables semble davantage conçu pour formater manuellement des tableaux destinés à la présentation
    https://github.com/paddymul/buckaroo
    https://youtu.be/GPl6_9n31NE
    • Merci pour votre travail sur Buckaroo. print() dans Jupyter et display() dans IPython ont la limite d’être des sorties statiques mortes, un peu comme l’ancien débogage au printf, et si je comprends bien Buckaroo a été créé pour résoudre ce problème
      Je serais curieux de savoir ce que vous pensez des raccourcis clavier et des interactions de Visidata
      J’ai utilisé Visidata autrefois, et je me suis toujours demandé pourquoi il ne pouvait pas finir par s’intégrer à Jupyter pour l’exploration de dataframes
      Je suis d’accord pour dire que Great Tables ressemble à une autre tentative de formaliser une grammaire des tableaux, et vu la puissance du format tabulaire et la diffusion du concept de dataframe via les écosystèmes R/pandas/Arrow/polars, ce type d’approche est bienvenu
      Cela dit, je crois que ce terme a été employé à l’origine dans le langage statistique S, dans les années 1990
      [1] https://towardsdatascience.com/preventing-the-death-of-the-d...
  • Les exemples de Great Tables sont trop complexes à mon goût. Les lignes horizontales au-dessus et en dessous du titre semblent inutiles, et l’alignement sur la première colonne, celle des étiquettes de ligne, ne me plaît pas non plus
    Un peu d’espace en dessous et une police en gras suffiraient sans doute à créer une hiérarchie visuelle sans bruit
    L’arrière-plan des étiquettes de ligne est trop sombre et, avec l’épaisseur de la police, rend la lecture difficile ; un bleu très clair serait préférable
    Je n’aime pas non plus le fait que l’étiquette de groupe de lignes, « Name », soit en italique
    Les étiquettes de colonnes supérieures flottant au milieu rendent le balayage du tableau plus difficile, et un alignement à gauche serait bien meilleur à mon avis
    Enfin, je n’aime vraiment pas la police, mais c’est peut-être la faute du navigateur
    J’ai fait une maquette avec quelques modifications, et je trouve que cette version est beaucoup plus lisible
    https://i.imgur.com/iMMf5vo.png
    • Vous devriez lire Beautiful Evidence d’Edward Tufte
      Le livre traite de tout ce que vous venez de mentionner, comme la lisibilité et les éléments qui parasitent le message ou l’idée principale des données
      Si vous avez déjà vu des sparklines, c’est aussi Tufte qui a inventé le terme
      À chaque revue d’interface, je me retrouve à feuilleter ce livre pour voir si quelque chose nous a échappé, et c’est un ouvrage intéressant même quand on l’ouvre au hasard
      Il contient aussi un long essai sur les raisons pour lesquelles PowerPoint est si mauvais
      [1] https://www.edwardtufte.com/tufte/books_be
      [2] https://en.wikipedia.org/wiki/Sparkline
    • Le titre d’un tableau devrait être centré en haut, ou placé en légende en bas
      Si on l’aligne à gauche au-dessus d’une colonne particulière, cela donne généralement l’impression — fausse ou non intentionnelle — que ce titre est au sommet de la hiérarchie informationnelle du tableau
      Dans la proposition moderniste ci-dessus, le titre annonce « names, addresses, characteristics », mais son alignement semble exclure les noms, ce qui m’a immédiatement dérangé
      À l’inverse, le manuel du recensement centre presque toutes les étiquettes à l’intérieur de leur boîte, et lorsqu’il ne le fait pas, c’est le plus souvent à cause d’un retrait
      Il dimensionne aussi la largeur des colonnes en fonction des données plutôt que des étiquettes, et n’hésite pas à harmoniser les retraits et la césure
      Le résultat est à la fois compact horizontalement et intuitif à comprendre
      En y repensant, le titre lui-même n’est pas bon non plus
      Le titre et la légende doivent transmettre le contexte, le périmètre et l’objectif ; sinon, on peut tout aussi bien les supprimer pour faute éditoriale de ne pas justifier leur existence
      Dans l’état actuel, ce titre pourrait être remplacé par « Table 1 » sans perte d’information ni de généralité
      Pour un article qui cherche à discuter et reconstruire la représentation tabulaire à partir des premiers principes, c’est assez décevant
      Les titres de tableaux constituent un niveau important du catalogue d’information, il n’est donc pas surprenant que le manuel du recensement consacre tout un chapitre à leur composition
      C’est assez spécifique au domaine et le style est un peu daté, mais cela vaut largement le détour
    • Je ne comprends pas pourquoi il n’y a pas d’éléments comme des lignes horizontales ou des zébrures pour renforcer l’idée que chaque ligne est son propre enregistrement
    • Votre maquette est une amélioration. L’exemple de l’article pose problème parce que le poids visuel de tous les caractères et chiffres du tableau est uniforme
    • Je pense qu’on peut pousser encore plus loin. Le titre peut être réduit à « remote correspondents », puisque le reste fait doublon avec les noms de colonnes
      L’accentuation en bleu est désormais elle aussi redondante avec le titre, donc on pourrait la supprimer entièrement, et il vaudrait mieux retirer aussi la distinction entre « personal characteristics » et « location », puisqu’elle n’aide pas réellement à l’organisation
  • C’est un bon article, intéressant pour son aspect historique
    Côté histoire plus récente, il y a aussi la création des tables CALS : https://en.wikipedia.org/wiki/CALS_Table_Model
    Datalogics https://en.wikipedia.org/wiki/Datalogics a été fortement impliqué dans la conception des tables CALS

Les employés de Datalogics participaient au comité ISO qui a créé SGML, et ont formé de nombreuses personnes à SGML, y compris des employés du département de la Défense américain et des sous-traitants impliqués dans la documentation
J’ai fait partie de l’équipe qui a créé un éditeur de documents basé sur SGML, dont l’une des fonctionnalités consistait à définir le style des éléments selon le contexte SGML de l’élément concerné
C’était avant l’arrivée de XSLT et de toute sa famille
Des anciens de Datalogics ont aidé Microsoft à comprendre XML. Dans le genre : « Non, vous ne pouvez pas changer librement la casse des balises d’éléments XML »
Les utilisateurs de TeX ont eux aussi une réflexion assez sophistiquée sur la mise en forme des tableaux
Détail annexe étonnant : à l’époque, on m’a appris que si l’on imprimait toute la documentation d’un certain avion de chasse, elle pèserait plus lourd que l’appareil lui-même et remplirait un ensemble d’armoires à dossiers de la taille d’un terrain de football
Et même si beaucoup de gens n’aiment pas XML aujourd’hui, vu depuis le monde SGML, XML est une immense bénédiction

  • À propos de Visicalc, il est écrit que « les cellules de la grille ne pouvaient pas recevoir de styles de bordure pour la présentation, les valeurs ne pouvaient pas être formatées et les tableaux ne pouvaient même pas être imprimés », mais cela ne me semble pas entièrement exact
    Il me semble que dès la première version il y avait une prise en charge limitée du formatage
    D’après http://www.bricklin.com/history/refcard3.htm, la commande /F permettait de définir l’alignement et le format numérique, par exemple en dollars et cents
    Ce document concerne la version 1.35, mais il me semble que la toute première version prenait déjà en charge au moins l’affichage en dollars et cents
  • Ce qui m’a toujours gêné dans les données numériques des tableaux, comme les montants en dollars, c’est que la comparaison des quantités paraît visuellement logarithmique plutôt que linéaire
    Par exemple, si les coûts sont de $1500, $130, $110 et $210, le texte des trois dernières lignes semble faire à peu près les 4/5 de la taille visuelle du texte de la première ligne
    Pourtant, leur somme atteint à peine un tiers du montant du haut
    Les gens perçoivent visuellement le nombre de chiffres, ce qui ressemble grosso modo à log10
    Ce problème revenait si souvent que j’ai fini par ajouter à chaque fois des graphiques en barres dans les cellules dans les feuilles de calcul financières
    Sinon, les réunions partaient inévitablement en débats sur des postes complètement insignifiants comparés au plus gros coût en valeur absolue
    J’ai réellement passé plusieurs réunions à discuter de $15 par mois pour la collecte des logs d’un serveur cloud, sur une VM qui faisait tourner un moteur de base de données dont la licence mensuelle coûtait à elle seule $15K
  • Je suis l’un des co-mainteneurs de Great Tables
    Je m’en occupe avec Rich Iannone
    Quand on demande à un développeur logiciel d’expliquer la philosophie du package, Rich est le seul que je connaisse capable de raconter 5 000 ans d’histoire de l’affichage des tableaux
  • Super. Merci du partage
    C’est étonnant qu’on ait laissé se dégrader aussi longtemps la représentation des tableaux de données
    Les tableaux modernistes du milieu du XXe siècle mentionnés dans l’article semblent vraiment être des exemples éclatants
    Ça me donne envie de refaire de l’analyse de données en Python, et j’ai aussi quelques idées d’améliorations et d’extensions de l’API que j’aimerais créer
  • J’adore ce package et je l’utilise depuis des années en R
    Il est excellent pour produire des tableaux HTML, mais la sortie PDF et DOCX est un peu moins aboutie
    Je m’inquiète un peu du fait que le développement côté R semble avoir ralenti depuis que l’accent a été mis sur la mise à niveau de la version Python au niveau de la version R
    Cela dit, ça vaut le coup d’y jeter un œil, quel que soit le langage que vous utilisez
  • Excellent. Dans les années 90, j’ai coécrit avec un collègue EBRI Datebook on Employee Benefits, un livre composé en grande partie de tableaux
    En dehors de SAS, notre principal outil était un ancien langage appelé Table Producing Language, ou TPL
    Il remonte aux années 1970, mais une fois la syntaxe assimilée, TPL était incroyablement flexible, expressif et efficace
    Les concepteurs de Great Tables feraient bien d’y jeter un œil
    Il couvre tout ce que Great Tables cherche à faire, et a peut-être même quelques tours supplémentaires
    https://www.ojp.gov/pdffiles1/Digitization/68013NCJRS.pdf
    En tout cas, merci d’avoir créé Great Tables
    Cela contribue grandement à améliorer la qualité de génération de tableaux en Python
  • Cette personne mérite une récompense. 1) excellent travail, 2) attention aux détails, 3) recherche approfondie, et 4) excellente manière de présenter qui évite les questions habituelles du genre « Donc, c’est quoi exactement ? », « Comment on commence ? », « Tu peux donner un exemple ? »
    Les personnes qui postent sur Show HN devraient en prendre de la graine
  • Il existe aussi un livre sur ce sujet : https://en.wikipedia.org/wiki/The_History_of_Mathematical_Ta...
    Détail annexe intéressant : les modèles d’IA entraînés sur des feuilles de calcul ont besoin de « bons tableaux » avec des noms de colonnes, des en-têtes, etc., pour comprendre le contexte
    Fortap en est un exemple : https://arxiv.org/abs/2109.07323