Utilisateur:Kumkum/Brouillon4
Faudra-t-il déployer Graph sur Wikipédia ?
Petite histoire de l'intégration de données graphiques sur Wikipédia[modifier | modifier le code]
Intégrer des données graphiques (des cartes ou des diagrammes divers et variés), c'est comme raconter une histoire.
La préhistoire[modifier | modifier le code]
_Demo.jpg)
Avant, pour intégrer des données statistiques graphiques ou cartographiques dans un article, il n'y avait qu'une solution. Tout le monde la connaît, pour l'avoir pratiqué ou pour y avoir été confronté.
Il faut 1) trouver les données ; 2) les copier sur un tableur (Excel, ou Calc pour les plus progressistes) ; 3) en faire un graphique ; 4) l'enregistrer en format image (.jpg, .bmp, .png, etc.) ou (pire) faire un screenshot une impression d'écran enregistré en image raster (donc, 4b) aller sur Paint faire un crop recadrage) ; 5) téléverser sur Commons ; 6) l'insérer dans l'article.
Rires au fond de la salle.
Donc un nombre d'opérations assez important qui augmente considérablement la probabilité d'erreurs de saisie, pour un résultat de qualité contestable. A moins d'avoir affaire à un contributeur qui soit un professionnel de la sémiologie graphique et de la restitution statistique, on est sûr d'avoir devant nous de mauvais arbitrages pour ce qui est du choix des couleurs, des dimensions, des échelles et des opération de discrétisation pour les cas les plus complexes (comme les cartes). Pour avoir un accès simplifié à quelques octets de données, quand vous avez cliqué sur l'horreur rouge ci-contre vous avez téléchargé 122 kilos d'information.
Évidemment, la source des données n'est pas indiquée. Mais on sait que l'utilisateur qui a produit cette image s'est donné du mal (voir plus haut), donc on ne reverte pas... et ça reste.
Conclusion :
| Points positifs | Points négatifs |
|---|---|
 On a des graphiques dans l'article |
 Le fichier est lourd
|
| Manipulation syntaxique simple dans le code source de la page |
Les données ne peuvent pas être mises à jour
|
| L'image peut être enregistrée facilement et réexploitée ailleurs. |
Les conventions de sémiologie graphique ne sont pas respectées
|
| Trop d'opérations (fastidieux et augmente le risque d'erreur)
| |
| L'image n'est pas exploitable dans d'autre langues
| |
| On peut pas mettre de liens dedans
| |
| C'est ultra moche.
|
L'antiquité[modifier | modifier le code]
L'utilisation de modèles graphiques avec une restitution vectorielle n'est pas si récente. Ce machin-ci date de 2006 :
Et truc-là de 2012 :
L'utilisation de ces modèles est assez rare. D'abord parce que pour les trouver, faut se lever de bonne heure, et surtout, parce qu'ils sont moches.
Conclusion :
| Points positifs | Points négatifs |
|---|---|
| On a des graphiques dans l'article |
Pas de restitution image
|
| Manipulation syntaxique simple dans le code source de la page |
Les conventions de sémiologie graphique ne sont pas respectées
|
| Le fichier est léger (éléments vectoriels) |
Le modèle n'est pas exploitable dans d'autre langues
|
| Les données peuvent être mises à jour |
Existence persistante de bugs altérant l'affichage
|
| On peut mettre des liens dedans |
C'est méga moche.
|
| Peu d'interventions sont nécessaires |
Le début de la modernité[modifier | modifier le code]
Voici un modèle de restitution graphique qui a eu un succès certain par rapport à tous les autres. Du point de vue de la sémiologie graphique, il est correct (le choix des couleurs est possible et pertinent), efficace (l'information est lisible sans effort visuel) et robuste (un grand nombre de données peut apparaître). Par contre il est très difficile à concevoir. Et en plus il est moche.
Impossible de compiler l'entrée EasyTimeline :
Timeline generation failed: 1 error found
Line 42: from: 31/03/2014 till: 01/05/2024 color:rose text:"Manuel Valls" fontsize:10
- Plotdata attribute 'till' invalid.
Date '01/05/2024' not within range as specified by command Period.
En plus de ça, si vous faites clic droit vous pouvez afficher l'image même si c'est pas un format vectoriel, c'est dommage... Un grand pas en avant dans l'accessibilité.
| Points positifs | Points négatifs |
|---|---|
| On a des graphiques dans l'article |
C'est vraiment chiant à faire
|
| Les conventions de sémiologie graphique sont respectées |
C'est très moche.
|
| Le fichier est léger (éléments vectoriels) |
N'est pas restitué en format image
|
| Les données peuvent être mises à jour |
|
| On peut mettre des liens dedans |
|
| Peu d'opérations sont nécessaires |
La civilisation[modifier | modifier le code]
Les modules en Lua. Le Module:Diagramme (créé en 2013) est un progrès immense fait dans la restitution graphique de données.
(municipales)
(législatives)
(municipales)
(présidentielles)
Il est encore peu utilisé. Pour pouvoir créer un diagramme en moins d'une heure il faut avoir une bonne maîtrise du rechercher-remplacer ou du Regex... bref c'est chiant. Et encore plus pour les contributeurs aussi courageux que peu nombreux qui assurent le service après-vente.
Conclusion :
| Points positifs | Points négatifs |
|---|---|
| On a des graphiques dans l'article |
C'est compliqué à faire
|
| Les conventions de sémiologie graphique sont respectées |
Pas de restitution en format image
|
| Le fichier est léger (éléments vectoriels) |
|
| Les données peuvent être mises à jour |
|
| On peut mettre des liens dedans |
|
| Peu d'opérations sont nécessaires |
|
| Visuellement, c'est pas mal.
|
Le futur[modifier | modifier le code]
Le futur sera de se passer des assemblages vectoriels pour au moins une raison : la diversité croissante des supports et le risque croissant des erreurs d'affichage. Une image d'un seul tenant est à souhaiter.
En plus de gérer des diagrammes, gère des cartes en format vectoriel.
Conclusion :
| Points positifs | Points négatifs |
|---|---|
| On a des graphiques dans l'article |
Gros code compliqué
|
| Les conventions de sémiologie graphique sont respectées |
Faudra passer par de l'inclusion modèle
|
| Le fichier est léger |
|
| Les données peuvent être mises à jour |
|
| On peut mettre des liens dedans |
|
| Peu d'opérations sont nécessaires |
|
| Possibilité d'image vectorielle ou raster (selon navigateur)
| |
| Prévu pour marcher avec VisualEd
| |
| C'est beau.
|
La suite[modifier | modifier le code]
Il faudrait :
- Une intégration dans la source aussi simple que les vignettes thumb
- Aucune sous-page sur fr.wp : les modules et les sous-pages c'est chiant, c'est le bordel et personne n'y comprend rien
- Un rendu html sous la forme d'une entité unique qui serait une image vectorielle, ou png pour les navigateurs anciens
- Des données mutualisables, donc liées à Wikidata
- Des objets graphiques (diagrammes et cartes) standardisés
- Un langage de programmation qui ne soit pas sur la voie de l'obsolescence et qui satisfasse les standards de l'Internet du futur : Graphoid tourne sous JSON et Vega.