En quête de versatilité

Salut les zestiens,

Dans ma façon de gérer mes apprenants, je ne sais jamais sur quel pied danser. J’ai essayé diverses solutions : papier, bdd, trello, et excel bien sûr. Comme je suis pragmatique, j’utilise plusieurs solutions en même temps.

Au-delà de mon cas personnel, enfin professionnel, je me demande : quel type de logiciel permet de manipuler au mieux des informations qui sont, par nature, très hétérogènes. Sans tomber dans le logiciel spécialisé j’entends.

J’aurais tendance à penser que les tableurs sont ce qui répond le mieux à ce besoin… mais n’y a-t-il vraiment rien à inventer après les tableurs ?

Bonjour,

Je ne comprends pas bien la question, c’est quoi, un apprenant, dans ton cas ?

Personnellement, j’ai vu tellement de mauvais usage du tableur¹ que c’est un outil que j’évite par défaut, mais peut-être que, dans ce cas que je n’ai pas bien compris, c’est une solution à envisager.

Peu importe mon cas particulier en fait, la question porte plutôt sur : comment présenter de la meilleure manière des informations hétérogènes à l’utilisateur, pour lui permettre de les manipuler facilement. Je me demande quelle forme un logiciel devrait avoir. Tu vois ce que je veux dire ?

J’ai déjà eu à gérer plus d’une centaine d’entreprises clientes via Excel pour des déclarations, ou leurs salariés ~3000. Je sais ce que c’est donc.

Les logiciels ont souvent des limites : impossible de créer des champs, impossible de travailler/exporter les données facilement, de les traiter, etc…

La gestion brut de données en entreprise pour des travaux administratifs ou sociales se fait souvent par Excel. Il est souvent la solution permettant de répondre aux mieux à la liberté de saisie, de duplication et de traitements de données. Faute d’avoir d’autres logiciels accessibles de saisie et traitement de données hétérogènes.

Pour palier aux tableurs, il y a Microsoft Access et les bases de données. Ça requiert de le mettre sur un serveur pour qu’il soit accessible simultanément, et un petit niveau pour l’utiliser.

L’utilisation des tableurs oblige souvent à créer un fichier est à devoir dupliquer les données fichiers par fichiers. Alors que les vues d’Access évitent de dupliquer les données, et sont facilement/rapidement mise en place.

J’avais justement fait ce sujet plus ou moins dans la même optique. Je n’ai pas trouvé de logiciel miracle. Je pensais m’orienter vers un système de base de données avec une interface utilisateur accessible. Je vais peut-être m’orienter vers Access et une vrai base de données plutôt qu’un fichier Access (pour un accès à plusieurs).

Pour des données quantitatives hétérogènes, le classeur peut être une solution.

De manière générale, j’utilise pour ça du papier ou un bête fichier texte. Ce qui me gêne avec le classeur sur des données hétérogènes, c’est que ça peut donner envie d’additionner des choux et des carottes divisées par des navets. Ça encourage les mauvaises pratiques.

Si le but est de les présenter à un utilisateur finale, qui n’a pas vocation à utiliser les données, il n’y a pas 36 solutions : il faut réduire (un tableau est l’une des pires présentations de données si le but est de dégager une vision d’ensemble). Faire des statistiques, trouver un indicateur pertinent, faire de graphes… Donc, traiter les données.

Si le but est de les donner à un collègue qui va les utiliser, je partirai soit sur les données brutes (fichier texte) à traiter lui-même, soit un classeur s’il n’est pas spécialiste (et c’est souvent ça qui se fait, à mon grand désarroi). Après, je suis biaisé, car je fais des simulations, donc je travaille sur de gros (mais pas immense) volume de données, qu’il n’est pas imaginable de traiter correctement avec un classeur. Ensuite, par habitude, je fais plus vite un script python pour traiter des trucs bêtes que d’utiliser un classeur. Donc il y a une grosse contrainte : ça dépend des gens en plus de dépendre des données.

A-312, oui "apprenant" voulait dire "personne actuellement en formation".

Ok Gabbro je vois ce que tu veux dire. Mais je me demande quel genre d’interface permet de manipuler des données hétérogènes, et d’ailleurs pas nécessairement quantitatives. Ça peut être du quantitatif, des périodes de temps, des associations entre les choses. Je cherche ce qui pourrait être vraiment modelable à souhait.

Tu vois, le classeur c’est hyper-malléable, mais c’est mal adapté à des données hautement structurées, et je crois que c’est surtout ça qui me manque. Ce n’est pas tellement une histoire de volume, puisque je ne suis pas, comme tu peux l’être, confronté à des données volumineuses. En revanche, les données que je dois traiter ont une structuration importante, bien que changeante.

Il me faudrait presque un mélange entre entités-relations et tableur. ER pour le côté structure, mais tableur pour le côté stat / suivi de progression péda. Un genre de mélange Visio/Excel. Dans le browser bien sûr (et avec une paille si possible)

J’ai mal posé ma question, c’est vraiment l’interface qui me turlupine je crois

J’avais bien compris finalement. Pourquoi ne pas accentuer l’utilisation d’ACCESS et des vues ?

Au final j’ai réédité.

Access, ça a été mon premier réflexe quand je suis arrivé au poste que j’occupe. Je me suis fait ma petite base, tranquille, et tout allait bien. Puis assez vite, je me suis rendu compte que… le monde est fait d’exceptions ! Non c’est vrai, dans mon boulot tout évolue sans arrêt, chaque apprenant fait un parcours qui lui est propre, j’ai sans cesse de nouveaux contenus, de nouvelles demandes, …etc. Donc dans mes premières bases Access, les informations de base (non changeantes) avaient leurs champs, et pour le reste, j’avais un bon vieux champ "Commentaire". Mais franchement c’est la mochitude. Et puis ça me pose la question, plus générale, de ce qu’est l’information.

Je pense que le modèle Objet qu’on utilise en programmation fonctionne bien ici, et plus particulièrement l’idée de prototype avec héritage par délégation. Mais comment on traduit ça par une UI aussi fluide qu’un tableur (ou qu’un formulaire Access) ?

Je connais des profs qui se sont fait leurs propres scripts Python pour gérer les données des étudiants. Ça me semble assez adapté. Ils généraient des stars, graphiques, classements, grilles d’évaluation…

Pour une base de données orientée le document plutôt que colonne c’est le NoSQL avec mangoDB, je sais qu’il y a plein de GUI qui existe mais je ne suis pas sûr qu’il y en a une qui réponde à tes attentes.

J’ai testé CouchDB, j’en garde un assez bon souvenir, je trouvais que c’était bien cet outil. Mais je n’avais pas creusé la question de l’UI par contre.

Je me suis même fait une REPL sur node pour gérer mes apprenants, une fois. Bon la command-line c’est bien pour certaines choses, mais ça a ses limites aussi !

J’ai aussi envisagé d’utiliser un Smalltalk, genre Squeak ou Pharo. C’est bien Smalltalk, mais j’ai du mal à rentrer dedans, je l’avoue. C’est particulier quand même.

Je vais paraître vieille école, mais il n’y a rien de mieux qu’un bon vieux papier et un crayon. Ça s’adapte à toutes les situations.

C’est pas faux (à chaque fois que je dis ça, j’ai une petite pensée pour Perceval)

Je réfléchis à voix haute.

En fait quand on y pense, la solution serait aux tableaux associatifs (voire aux objets) ce que le tableur est aux matrices 2D.

Mais dans le tableur on a tout en un : on peut modifier la présentation de certaines plages, on peut entrer des valeurs constantes, et fournir des formules de calcul des valeurs, avec mise à jour immédiate.

Transposé à notre solution envisagée, cela donne quoi ?

Imaginons un modèle simple : des objets encapsulant des données, dont certaines sont potentiellement des méthodes, en mode prototype avec héritage multiple par délégation. On peut modifier l’apparence des clefs, des valeurs, et des objets eux-même. On peut entrer des données constantes en clefs ou en valeurs, et fournir des formules de calcul des clefs / valeurs. La présentation, les constantes et les formules seraient transmises par héritage, et overridables.

Mais dans le tableur on a tout en un : on peut modifier la présentation de certaines plages, on peut entrer des valeurs constantes, et fournir des formules de calcul des valeurs, avec mise à jour immédiate.

Je ne suis pas convaincu, je pense qu’il faut qu’on garde une séparation modèle (base de données/stockage) et controlleur (action/traitement des données) un peu comme le modèle MVC de programmation. Ou Microsoft Access qui fait une séparation entre les tables, les vues, les requêtes et les formulaires.

Pour les activer à sa guise après rien empêche de mettre un systeme d’événements. Du type : "Réaliser l’action lorsque le formulaire est envoyé", "Champs modifiés" etc…

La présentation, les constantes et les formules seraient transmises par héritage, et overridables.

Je suis persuadé qu’il faut donner une ossature/structure principale. Puis à cette ossature greffer des propriétés.

Par contre ces propriétés annexes devrait suivre une norme, une structure, un typage précis, ou un système de suggestions de nouvelles propriétés :

• Pour être certain qu’on va affecter un nom identique à un même champs 2 semaines après ou s’il y a plusieurs utilisateurs.
• Pour qu’on puisse s’y retrouver en cas d’action/traitement automatique pour travailler sur les données.

Quand je parle de typage précis c’est d’overRide le format VarChar pour ajouter un type : Téléphone, Adresse, CP, etc…

Je ne suis pas convaincu, je pense qu’il faut qu’on garde une séparation modèle (base de données/stockage) et controlleur (action/traitement des données) un peu comme le modèle MVC de programmation. Ou Microsoft Access qui fait une séparation entre les tables, les vues, les requêtes et les formulaires.

Ok on peut en parler… Pourquoi considères-tu qu’il faille garder cette séparation ?

Je suis persuadé qu’il faut donner une ossature/structure principale. Puis à cette ossature greffer des propriétés.

Par contre ces propriétés annexes devrait suivre une norme, une structure, un typage précis, ou un système de suggestions de nouvelles propriétés : Pour être certain qu’on va affecter un nom identique à un même champs 2 semaines après ou s’il y a plusieurs utilisateurs. Pour qu’on puisse s’y retrouver en cas d’action/traitement automatique pour travailler sur les données. Quand je parle de typage précis c’est d’overRide le format VarChar pour ajouter un type : Téléphone, Adresse, CP, etc…

Que penses-tu de ceci :

Quand on travaille sur un objet (appelons ça comme ça pour le moment), on a deux situations possibles :

• Soit on hérite des propriétés des prototypes de cet objet,

• Soit on ajoute de nouvelles propriétés.

Il y a deux problèmes à traiter, comme tu le mentionnes.

• Il pourrait y avoir une typo : simplement parce qu’on a mal orthographié une clef, on se retrouve avec une nouvelle propriété alors qu’on voulait modifier la valeur d’une propriété héritée.

• Il pourrait y avoir un problème de type : on override une valeur, mais en donnant un type qui provoquera, ailleurs dans le système, des erreurs parce que ce type ne convient pas à cet endroit.

Donc je propose deux solutions.

Si on souhaite créer une nouvelle propriété, non héritée donc, on doit le faire explicitement. Si c’était du code, on aurait une instruction "new" par exemple, mais là on envisage plutôt un logiciel intégré, donc cela se traduirait par

1) une action explicite de l’utilisateur pour exprimer sa volonté de créer une propriété non héritée, et

2) une représentation visuelle du statut "non hérité" de la propriété.

Si au contraire on souhaite overrider une valeur, on ne peut le faire qu’un choisissant un type qui soit

• soit égal au type de la valeur d’origine,

• soit un sous-ensemble du type de la valeur d’origine.

Puisque les valeurs sont des objets, leurs types sont définis par les prototypes qu’elles ont. Donc par exemple, si j’ai une propriété prévue pour recevoir des valeurs ayant "quadrilatère" en proto, je peux aussi y mettre des valeurs ayant "quadrilatère" et "parallélogramme" en proto. Du moment que le proto "quadrilatère" est présent, on en bon. Ensuite, plus tu vas vers les objets héritiers, plus tu obtiens des propriétés spécifiques.

Salut,

Je ne suis pas sûr d’avoir tout à fait bien cerné ton problème mais je voudrais juste apporter mon grain de sel. Lorsque tu parles de manipuler des données très hétérogènes et de les insérer dans un "système" cela me fait penser à Org-mode pour Emacs. Il est difficile de dresser une liste de toutes les features d’org mais je peux essayer de te donner quelques unes qui pourraient t’être utiles:

• Une hiérarchisation / classement solide de ton contenu. Tu peux bien sûr créer plusieurs répertoires et fichiers, mais surtout à l’intérieur des fichiers tu peux hiérarchiser avec des headlines de différents niveaux et un système de tag.
• Bien que ton fichier soit du texte pur, tu peux inclure des tableurs, des images, des graphes, des schémas, du code (que tu peux exécuter "à l’intérieur" de ton fichier pour en capturer la sortie), des liens vers d’autres documents, etc.
• Tu peux assigner des propriétés à chaque headline de manière à faire de l’héritage sur les noeuds enfants. Tu peux ensuite propager ces propriétés, les filtrer, etc.
• Il est possible d’exporter les documents .org vers un grand nombre de formats (pdf, markdown, html, …) avec un excellent support pour des outils comme LaTeX et Pandoc.
• Org-mode offre un agenda qui te permet d’avoir une vue d’ensemble de tes fichiers ainsi qu’un outil de capture pour prendre des notes et les ajouter dans tel ou tel fichier sans avoir à s’interrompre. Avec le refiling et l’archivage il est aisé de déplacer des éléments d’un fichier à un autre.
• Avec Emacs tout est entièrement scriptable et extensible en elisp et l’éco-système Emacs + Org-mode fournit des packages pour absolument tout. Enfin avec Emacs tu utilises un éditeur de texte puissant qui, une fois bien configuré, peut te faire gagner énormément de temps au quotidien (raccourcis claviers, templates / snippets, etc).

Le principal inconvénient que je vois est que cela va te demander beaucoup de temps d’arriver à un setup qui correspond à tes besoins et si tu l’utilises dans le cadre de ton travail, il va être difficile de former tes collègues à utiliser Emacs + Org-mode. Par contre tu peux toujours exporter tes documents pour les partager.

J’ai peut-être tout compris de travers et cela ne te conviendrait pas du tout. Mais si jamais tu décides de creuser, tu peux commencer par le site communautaire worg et cet exemple de configuration pour voir ce qu’il est possible de faire

Je pense que ça permet d’éviter de tout mélanger et de faire une séparation permettant de réutiliser des données tout en les traitants différemment. L’une des première chose que j’ai appris en SQL c’est qu’il fallait stocker seulement les variables bruts et non ce qui est calculé.

Pour moi ce qui est calculé :

• Peut-être facilement retrouvé ;
• Peut changer d’un usage à l’autre.

Donc faire une séparation permet aussi d’effectuer des modifications rapidement sans que ca soit trop imbriqué de l’un à l’autre.

Après le reste me semble très bien. Tu m’as juste perdu dans ton exemple avec les formes géométriques. Je ne sais faire que des ronds avec mon avions mais j’ai compris le principe.

Salut skywhi,

Du coup j’ai commencé à rédiger ma réponse sur emacs (tout en buvant un café préparé par emacs), et… ça m’a gonflé au bout de 5 lignes, désolé. D’accord c’est versatile, j’en conviens, mais alors en termes d’ergonomie, non ça ne va pas être possible. Je pense qu’à son époque, au temps des croisades "emacs/vim", c’était un super outil. Je pense aussi que les personnes qui sont fluentes sur emacs y trouvent leur compte encore aujourd’hui. Mais pour un newcomer, il faudrait que j’avale 650 pages de "C-x pour faire ci" et "M-y pour faire ça" + 300 pages pour l’org-mode, ça va pas le faire : j’aime les romans-fleuves, mais je ne peux pas intégrer autant de réflexes pour un simple outil. Je trouve que c’est à l’outil de s’adapter à moi. J’ai toujours eu envie d’emacs, mais j’ai jamais pu malheureusement. Merci pour la suggestion en tout cas ça alimente la réflexion !

A-312, je crois que tu fais référence à l’idée qu’il vaut mieux mémoriser la date de naissance que l’âge d’une personne par exemple, et l’âge peut toujours être retrouvé par le calcul. Je suis d’accord. Simplement il faut bien mémoriser la formule de calcul de l’âge quelque part… Comment tu vois les choses concrètement ?

@skywhi Dans ma tête, je voyais plutôt un outil simple et qui peut-être pris en main par n’importe qui via une interface visuelle. La programmation n’est pas une compétence attendue dans mon domaine d’activité, donc mes collègues ne savent pas faire ça.

Concrètement :

Je vais citer SQL comme exemple alors qu’on parle de NoSQL. C’est peut-être ça mon problème, je pense trop façon SQL.

En SQL, on peut inclure/joindre lors d’une requête une sous-requêtes comme si c’était une table. Et on peut faire des calculs directement dans une requête.

Vu qu’ici nos requêtes sont des objets/class, je pense :

• Une class qui hérite de la class model qui va récupérer les données/l’objet dans notre base NoSQL.
• Une class qui hérite controller qui va être conçu afin de récupérer les formules de calcul de cette class¹ et recipérer/traiter l’objet que retourne la class model ou d’une autre class controller (on autorise l’imbrication de class controller).

Pour la structure/ossature de notre objet model, je pensais créer un objet ossature avec comme propriétés les champs et en valeur le type des champs.

Par contre je ne sais pas comment séparer les champs principaux et secondaires. Par une clé à la racine des objets ? Faut-il prévoir des sous groupes ? Par exemple, si on souhaite faire un objet véhicule, doit-on anticiper les différents sous groupe de propriété ? Si c’est une voiture, un camion, un bus… Un véhicule de luxe ou normal, etc…

1
2
3
4
5
6
7

//principaux :
ossature.main.propriete1

//secondaire
ossature.minor.propriete56
//ou :
ossature.minor.groupA.propriete56

SQL, sors de ce corps ! C’est vrai que je sens bien le SQL en toi, mais c’est plutôt bien, c’est synonyme de rigueur. Si ça ne se transforme pas en rigidité, c’est une bonne chose.

Pour la structure/ossature de notre objet model, je pensais créer un objet ossature avec comme propriétés les champs et en valeur le type des champs.

Oui, comme le « Mode création » d’Access si je comprends bien.

Quel(s) langage(s) de programmation parles-tu ? On pourrait peut-être mieux communiquer via des snippets… Personnellement, je comprends principalement le Javascript, mais je peux sans doute m’adapter à d’autres choses (pas trop exotique hein).

Aussi, une autre façon de « concevoir » notre outil pourrait être de prendre la discussion dans l’autre sens : on commence par discuter de l’apparence qu’on voudrait obtenir, pour venir petit à petit vers les mécanismes sous-jacents.

Edit : tu veux vraiment faire des classes, ou il y a moyen de bosser avec des protos ?