Outils conviviaux

Nous avons récemment déjeuné avec les personnes s’occupant d’Outils-Réseaux dans les locaux de scopyleft (d’ailleurs, si vous passez dans le coin de Montpellier/Clapiers n’hésitez pas à venir nous voir) qui nous ont parlé des outils conviviaux introduits par Ivan Illich :

Illich définit alors trois critères indispensables pour qu’une instrumentation ou une institution soit considérée comme juste ou conviviale :

Critères de convivialité, sur Wikipédia.

Lorsque l’on applique ces critères à l’informatique, on se rend compte du chemin qu’il reste à faire pour obtenir des outils numériques conviviaux. Cela m’a amené à penser à l’utilisation des frameworks comme outils d’industrialisation à l’origine d’une hiérarchisation entre ceux qui connaissent le langage et ceux qui connaissent les méta-outils associés au langage. On en arrive à une hiérarchie entre développeurs avant même de pouvoir rendre ces outils accessibles au grand public.

Permettre à nos outils de communiquer localement sans passer par un réseau distant à des propriétés sociales intéressantes :

L’édition en intimité sur un réseau local, Karl Dubost

Pour un projet que l’on a en interne, j’ai pas mal réfléchi à la simplicité extrême que pouvait prendre une application et j’en suis arrivé à la solution conviviale suivante :

Est-ce que vous avez des exemples d’applications web conviviales ?

Discussion suite à l’article :

Tu définis quatre critères pour pouvoir qualifier un outil de convivial. Le premier est qu’il soit disponible sous la forme d’un unique fichier non minifié. Cette dernière contrainte me fait un peu tiquer. Pour de basses questions de performances, l’outil pourrait gagner à avoir son source minifié. Est-ce que, comme pour un logiciel dont on distribue le code source et la version compilée, un outil pourrait être convivial s’il est disponible sous la forme d’un fichier unique minifié et sous la forme de plusieurs fichiers sources, lisibles et commentés ?

Le troisième critère est la centralisation des données. Ce critère ne pourrait-il pas être alternatif avec la possibilité d’exporter les données ? En effet, offrir une possibilité de synchroniser plusieurs instances de l’outil via un serveur impose de se lier à une solution serveur. Le partage de données via import / export, certes moins pratique, offre à mon humble avis, plus de liberté aux utilisateurs.

Dernier point, le plus important, proposes-tu une certification « outil certifié convivial par davidbgk` », à apposer sur mon application si j’arrive à remplir tes critères ? Comme les regrettés badges « Valid XHTML 1.0 »

Clochix, le 2013-12-20 à 11:07

Tu définis quatre critères pour pouvoir qualifier un outil de convivial. Le premier est qu’il soit disponible sous la forme d’un unique fichier non minifié. Cette dernière contrainte me fait un peu tiquer. Pour de basses questions de performances, l’outil pourrait gagner à avoir son source minifié.

Je ne vois pas très bien la contrainte des performances sur un environnement local, en quoi la taille du code risque d’influer sur le chargement de la page ? Ou alors tu parles d’autres performances ? Dommage de perdre la possibilité de voir la source instantanément depuis son navigateur lors d’une inspection du code par exemple.

Est-ce que, comme pour un logiciel dont on distribue le code source et la version compilée, un outil pourrait être convivial s’il est disponible sous la forme d’un fichier unique minifié et sous la forme de plusieurs fichiers sources, lisibles et commentés ?

Ce que je pourrais comprendre par contre c’est la flexibilité lors du développement d’avoir le fichier éclaté afin de pouvoir bénéficier de la coloration syntaxique ou d’outils externes. J’ai peur que cela introduise de la complexité par contre, le fait de tout avoir dans le même fichier peut être un indicateur de la taille à ne pas dépasser avant de devenir incompréhensible pour autrui.

Le troisième critère est la centralisation des données. Ce critère ne pourrait-il pas être alternatif avec la possibilité d’exporter les données ? En effet, offrir une possibilité de synchroniser plusieurs instances de l’outil via un serveur impose de se lier à une solution serveur. Le partage de données via import / export, certes moins pratique, offre à mon humble avis, plus de liberté aux utilisateurs.

En effet cela pourrait être une alternative tout à fait valable en attendant du pair à pair, j’ai l’impression que l’on n’est plus très loin d’une solution envisageable à base de WebRTC.

Dernier point, le plus important, proposes-tu une certification « outil certifié convivial par davidbgk` », à apposer sur mon application si j’arrive à remplir tes critères ? Comme les regrettés badges « Valid XHTML 1.0 »

Haha, bien sûr avec un lien vers mon validateur et/ou mieux une formation obligatoire qui permet à des tiers d’être certifiés/certifiants moyennant finances. Le tout sous licence ABRMS bien évidemment.

Blague à part, cette définition est vivante, n’hésite pas à l’enrichir de tes propres critères. Pour moi MDNHub se rapproche beaucoup de ce que j’avais en tête pour définir une application conviviale et sa taille me semble suffisamment raisonnable pour ne pas avoir à la minifier.

David Larlet, le 2013-12-20 à 17:10