From fc53dcdcda4d5ee299fb5fcdc4f1bdb03fada7e7 Mon Sep 17 00:00:00 2001 From: Sébastien Dailly Date: Thu, 19 Mar 2015 17:21:00 +0100 Subject: New article on the creation --- content/Perso/2013-05-18-traitment.rst | 119 ++++++++++++++++++++++++ content/Perso/2015-03-19-dynamisme.rst | 114 +++++++++++++++++++++++ content/Perso/traitement.rst | 119 ------------------------ content/images/desire.jpg | Bin 0 -> 7447 bytes content/images/time/1135634742_0b4735dab5_m.jpg | Bin 0 -> 20507 bytes 5 files changed, 233 insertions(+), 119 deletions(-) create mode 100644 content/Perso/2013-05-18-traitment.rst create mode 100755 content/Perso/2015-03-19-dynamisme.rst delete mode 100644 content/Perso/traitement.rst create mode 100644 content/images/desire.jpg create mode 100755 content/images/time/1135634742_0b4735dab5_m.jpg (limited to 'content') diff --git a/content/Perso/2013-05-18-traitment.rst b/content/Perso/2013-05-18-traitment.rst new file mode 100644 index 0000000..8830404 --- /dev/null +++ b/content/Perso/2013-05-18-traitment.rst @@ -0,0 +1,119 @@ +.. -*- mode: rst -*- +.. -*- coding: utf-8 -*- + +========================================= +Cachez-moi ce menu que je ne saurais voir +========================================= + +:date: 18/05/2013 +:tags: Humeur +:summary: |summary| +:logo: /images/traitement/logo.jpg + + +.. figure:: http://farm1.staticflickr.com/214/4555895229_880a76beb7_q.jpg + :figclass: floatright + :alt: Machine ancienne + + Photo : `Arielle Fragassi`_ + +Dans la programmation, la maintenance du code, c'est-à-dire la réutilisabilité +d'une partie de l'application par un tiers ou l'utilisation de ce code dans un +autre contexte que celui pour lequel il a été écrit est tout aussi important +que le bon fonctionnement de l'application. + + +Comment des développeurs peuvent-ils concevoir des applications qui incitent les +utilisateurs à produire des documents qui ne soient pas maintenables ? + +Ma question s'adresse aux logiciels de traitement de texte, et cible cette +ignominie héritée des suites bureautiques d'un ancien temps : je ne comprends +pas pourquoi libreOffice continue de présenter une barre de formatage de texte +incluant les boutons pour choisir la police sa taille et appliquer des effets +de style sur le texte. + +|summary| + +.. |summary| replace:: + Si je devais écrire un logiciel de traitement de texte, j'irais cacher ces + boutons dans un obscur menu, et enverrai des décharges électriques à + l'utilisateur à chaque fois qu'il prend le risque de les utiliser malgré + tout ! Pourquoi ? Parce que ces boutons sont utilisés la plupart à tort et + à travers, et compliquent la tâche des usagers plus qu'ils la facilitent. + +.. image:: {filename}../images/traitement/fautif.png + :alt: Le menu coupable + +Le nombre de fois où il est légitime d'utiliser ces boutons ne justifient au +aucun cas leur présence en pleine page, juste au-dessus du document sur lequel +on est en train de travailler ! + +Maikeskidi ? +============ + +Trop souvent je vois des documents dont le formatage repose seulement sur des +styles appliqués via ce menu : les titres, les paragraphes, les effets de mise +en page étant uniquement géré via des mises en gras, des changements de police, +et, comble de l'horreur, des espaces pour gérer les retraits ! + +Comme je plains l'auteur d'un document, qui, trois mois après avoir écrit son +CV, essaie de rajouter une ligne dans ses expériences ; lorsque son beau +formatage se retrouve cassé parce que sa nouvelle ligne est plus longue que les +précédentes ! Comme je plains l'utilisateur qui est obligé de re-numéroter tous +ses titres parce qu'une nouvelle section a été insérée sur la 4e page de son +rapport ! + +Et pourtant, je comprends pourquoi les documents sont ainsi rédigés : c'est +tellement intuitif, tellement facile de mettre en forme son document +directement, en appliquant le formatage sur le texte sélectionné. Après tout, +on utilise un traitement de texte avoir un rendu visuel immédiat du document, +pas pour passer son temps dans les styles, à mettre en place une mise en forme +abstraite, nommée « Titre2 » juste pour configurer un sous-titre que l'on +utilise une seule fois dans son texte ! Mais lorsque le rapport se met à +grossir, une fois ces sous-titres plus nombreux, quand on souhaitera mettre les +sous-titre en italique plutôt que les souligner, le temps passé à mettre en +forme le document causera énervement, erreurs, et frustration. + +Pourtant, le retirer signifie couper les utilisateurs de leurs habitudes et les +placer face à une application qu'ils maîtriserons encore moins. Entre ces deux +solutions extremes (encourager l'utilisateur utiliser incorrectement le +produit, ou le contraindre à l'utiliser tel qu'il a été pensé par les +développeurs), il y a une marge : accompagner l'utilisateur dans son usage de +l'application. + +On fait quoi alors ? +==================== + +Pour l'utilisateur qui ne sait pas : `utiliser les styles`_ ! Je ne vais pas +faire un tutoriel sur leur usage, mais il s'agit de la solution la plus simple +pour mettre en forme un document. + +Ensuite, pour la communauté, alerter : c'est en remontant l'information +et en échangeant que les logiciels évoluent ; pas en pestant tout seul dans son +coin. Si l'on ne prend pas le temps de remonter un problème (comme ici à +travers cet article) rien n'évoluera, et la situation persistera. Cette alerte +peut se faire directement via des remontées de bugs, des réunions +d'information, ou des commentaires dans forums. Le but est de parler, et +échanger sur ce que l'on perçoit. + +Comment contribuer ? +==================== + +Enfin pour le développeur, être à l'écoute. C'est une faute grave de ne pas +suivre les remontées de ces utilisateurs, surtout quand un problème est connu +(les articles qui présentent l'utilisation des styles sont connus et existent +depuis longtemps, preuve que le besoin de documentation n'est pas nouveau). +Mettre en place une pop-up affichant « Êtes vous sûr de vouloir appliquer un +effet de texte local ? » peut aussi être une solution. + +Malheureusement, plus le projet devient imposant, plus contribuer devient +difficile. Tout d'abord parce qu'avant de proposer un patch, il est nécessaire +de prendre le temps et se plonger dans le code existant (ce qui casse le patch +spontané corrigeant un problème local), mais aussi parce que plus un projet +devient imposant, plus il acquiert une inertie qui l'empêche d'évoluer +facilement. + +.. _Utiliser les styles: https://help.libreoffice.org/Writer/Styles_in_Writer/fr + + +.. _Arielle Fragassi: http://www.flickr.com/photos/toastytreat/4555895229/ diff --git a/content/Perso/2015-03-19-dynamisme.rst b/content/Perso/2015-03-19-dynamisme.rst new file mode 100755 index 0000000..d157d3d --- /dev/null +++ b/content/Perso/2015-03-19-dynamisme.rst @@ -0,0 +1,114 @@ +.. -*- rst -*- +.. -*- coding: utf-8 -*- + +=========================== +De la dynamique des projets +=========================== + +:date: 2015-03-21 +:tags: Jeux, DIY +:summary: |summary| +:logo: /images/desire.jpg + +.. figure:: {filename}/images/desire.jpg + :figwidth: 150 + :figclass: floatright + :alt: Goban + + Image : `Wendy`_ (creativecommons_) + +.. _Wendy: https://www.flickr.com/photos/smkybear/2395845001 +.. _creativecommons: http://creativecommons.org/licenses/by-sa/2.0/ + +|summary| + +.. |summary| replace:: + Il suffit parfois de pas grand-chose, par exemple changer de téléphone, + pour avoir envie de créer. C'est parti d'un manque — une application qui me + manquait sur mon nouveau téléphone, et aussi l'envie de faire quelque chose + par soi-même, plutôt que simplement télécharger un outil tout prêt qu'il + suffit d'installer. + +Toujours est-il que je me suis mis à coder pour mon téléphone. Pour m'amuser, +pour apprendre, pour m'occuper dans le train une fois que j'aurai terminé mon +jeu… + +S'amuser +-------- + +Le moteur le plus important, sûrement. Prendre du plaisir dans ce que l'on +fait. Déjà le jeu. Réfléchir, se prendre la tête sur un problème, chercher la +solution, tâtonner, revenir en arrière et recommencer. J'ai toujours aimé +trouver des réponses à des problèmes. Ou du moins la chercher. Une fois que +l'on a compris comment trouver la réponse, l'enjeu disparaît, même si la +solution n'a pas été exprimée jusqu'au bout… + +Ici le sujet est bien choisi : des problèmes de go. Il faut trouver la +solution, comprendre le problème et ce que l'on attend de nous. Survivre — +trouver une défense au prix de la perte de quelques pierres ? Attaquer — +trouver la faille dans le jeu de l'adversaire ? + +Identifier un motif pour comprendre comment répondre a un besoin en s'insérant +dans une configuration existante, c'est un jeu de puzzle du quotidien. La même +problématique se pose dans le cadre de la programmation ; surtout quand il +s'agit de mener un projet seul, dans lequel il est nécessaire de construire +l'ensemble des fonctions d'une application en gardant à l'esprit comment +l'application va évoluer à l'avenir. + +Apprendre +--------- + +Vient ensuite un autre plaisir, celui d'apprendre. Être confronté à une +nouvelle situation devant laquelle on commence sans savoir quoi faire. Le +téléphone nécessite son propre environnement de travail (même si des +simulateurs existent). Les concepteurs ont choisi des technologies existantes, +mais encore faut-il les connaître, ce qui n'était pas mon cas quand j'ai +commencé à développer mon jeu. + +Il y a donc un besoin d'apprendre de nouvelles connaissances, mais surtout, une +dynamique de l'apprentissage. Cette dynamique qui me pousse sans cesse à aller +`au fond de l'Inconnu pour trouver du nouveau !` + +Persévérer +---------- + +.. figure:: {filename}/images/time/1135634742_0b4735dab5_m.jpg + :figwidth: 182 + :figclass: floatleft + :alt: Perséphone + + Image : `Olga Diez`_ (creativecommons__) + +.. _by-nc-sa: http://creativecommons.org/licenses/by-nc-sa/2.0/ + +__ by-nc-sa_ + +.. _Olga Diez: https://www.flickr.com/photos/caliope-olga/1135634742/ + +Ensuite viennent les obstacles : Ne pas savoir faire, être bloqué sur un +problème que l'on ne comprend pas, perdre du temps à chercher. `Bien qu'on ait +du cœur à l'ouvrage, l'art est long, et le temps est court` dit le poète. +Pendant six mois, le projet est resté endormi sans que je ne cherche à m'y +remettre. Souvent, cela commence par un problème que je n'avais pas imaginé. +Un obstacle un peu plus difficile que les autres, qui oblige à prendre une +heure de réflexion avant de le résoudre. Sauf que c'est long une heure (moins +long que six mois d'attente certes)… + +Quand la seule récompense à cette motivation est une satisfaction personnelle, +il est facile de laisser tomber. Passer à une autre activité dont le plaisir et +la récompense est immédiate. Combien de projets ai-je déjà laissé sombrer, +avant qu'une nouvelle idée arrive, et qu'un nouveau projet vienne chasser le +précédent. + +Ici la dynamique est repartie, venant cette fois d'un autre jeu ; une +découverte, m'a redonné l'envie. L'envie de jouer, de créer, d'expérimenter. +C'est le balancier de Perséphone qui oscille, entre la phase de création et +celle de son repos. + +Diffusion +--------- + +Le projet a été diffusé cette semaine. C'est une première version, mais c'est +une première tout court. La naissance d'un nouveau projet qui va venir +compléter tous ceux pour lesquels des créateurs ont donné de leur temps. +Maintenant il reste à continuer à le faire vivre, et ne pas le laisser mourir ! diff --git a/content/Perso/traitement.rst b/content/Perso/traitement.rst deleted file mode 100644 index 8830404..0000000 --- a/content/Perso/traitement.rst +++ /dev/null @@ -1,119 +0,0 @@ -.. -*- mode: rst -*- -.. -*- coding: utf-8 -*- - -========================================= -Cachez-moi ce menu que je ne saurais voir -========================================= - -:date: 18/05/2013 -:tags: Humeur -:summary: |summary| -:logo: /images/traitement/logo.jpg - - -.. figure:: http://farm1.staticflickr.com/214/4555895229_880a76beb7_q.jpg - :figclass: floatright - :alt: Machine ancienne - - Photo : `Arielle Fragassi`_ - -Dans la programmation, la maintenance du code, c'est-à-dire la réutilisabilité -d'une partie de l'application par un tiers ou l'utilisation de ce code dans un -autre contexte que celui pour lequel il a été écrit est tout aussi important -que le bon fonctionnement de l'application. - - -Comment des développeurs peuvent-ils concevoir des applications qui incitent les -utilisateurs à produire des documents qui ne soient pas maintenables ? - -Ma question s'adresse aux logiciels de traitement de texte, et cible cette -ignominie héritée des suites bureautiques d'un ancien temps : je ne comprends -pas pourquoi libreOffice continue de présenter une barre de formatage de texte -incluant les boutons pour choisir la police sa taille et appliquer des effets -de style sur le texte. - -|summary| - -.. |summary| replace:: - Si je devais écrire un logiciel de traitement de texte, j'irais cacher ces - boutons dans un obscur menu, et enverrai des décharges électriques à - l'utilisateur à chaque fois qu'il prend le risque de les utiliser malgré - tout ! Pourquoi ? Parce que ces boutons sont utilisés la plupart à tort et - à travers, et compliquent la tâche des usagers plus qu'ils la facilitent. - -.. image:: {filename}../images/traitement/fautif.png - :alt: Le menu coupable - -Le nombre de fois où il est légitime d'utiliser ces boutons ne justifient au -aucun cas leur présence en pleine page, juste au-dessus du document sur lequel -on est en train de travailler ! - -Maikeskidi ? -============ - -Trop souvent je vois des documents dont le formatage repose seulement sur des -styles appliqués via ce menu : les titres, les paragraphes, les effets de mise -en page étant uniquement géré via des mises en gras, des changements de police, -et, comble de l'horreur, des espaces pour gérer les retraits ! - -Comme je plains l'auteur d'un document, qui, trois mois après avoir écrit son -CV, essaie de rajouter une ligne dans ses expériences ; lorsque son beau -formatage se retrouve cassé parce que sa nouvelle ligne est plus longue que les -précédentes ! Comme je plains l'utilisateur qui est obligé de re-numéroter tous -ses titres parce qu'une nouvelle section a été insérée sur la 4e page de son -rapport ! - -Et pourtant, je comprends pourquoi les documents sont ainsi rédigés : c'est -tellement intuitif, tellement facile de mettre en forme son document -directement, en appliquant le formatage sur le texte sélectionné. Après tout, -on utilise un traitement de texte avoir un rendu visuel immédiat du document, -pas pour passer son temps dans les styles, à mettre en place une mise en forme -abstraite, nommée « Titre2 » juste pour configurer un sous-titre que l'on -utilise une seule fois dans son texte ! Mais lorsque le rapport se met à -grossir, une fois ces sous-titres plus nombreux, quand on souhaitera mettre les -sous-titre en italique plutôt que les souligner, le temps passé à mettre en -forme le document causera énervement, erreurs, et frustration. - -Pourtant, le retirer signifie couper les utilisateurs de leurs habitudes et les -placer face à une application qu'ils maîtriserons encore moins. Entre ces deux -solutions extremes (encourager l'utilisateur utiliser incorrectement le -produit, ou le contraindre à l'utiliser tel qu'il a été pensé par les -développeurs), il y a une marge : accompagner l'utilisateur dans son usage de -l'application. - -On fait quoi alors ? -==================== - -Pour l'utilisateur qui ne sait pas : `utiliser les styles`_ ! Je ne vais pas -faire un tutoriel sur leur usage, mais il s'agit de la solution la plus simple -pour mettre en forme un document. - -Ensuite, pour la communauté, alerter : c'est en remontant l'information -et en échangeant que les logiciels évoluent ; pas en pestant tout seul dans son -coin. Si l'on ne prend pas le temps de remonter un problème (comme ici à -travers cet article) rien n'évoluera, et la situation persistera. Cette alerte -peut se faire directement via des remontées de bugs, des réunions -d'information, ou des commentaires dans forums. Le but est de parler, et -échanger sur ce que l'on perçoit. - -Comment contribuer ? -==================== - -Enfin pour le développeur, être à l'écoute. C'est une faute grave de ne pas -suivre les remontées de ces utilisateurs, surtout quand un problème est connu -(les articles qui présentent l'utilisation des styles sont connus et existent -depuis longtemps, preuve que le besoin de documentation n'est pas nouveau). -Mettre en place une pop-up affichant « Êtes vous sûr de vouloir appliquer un -effet de texte local ? » peut aussi être une solution. - -Malheureusement, plus le projet devient imposant, plus contribuer devient -difficile. Tout d'abord parce qu'avant de proposer un patch, il est nécessaire -de prendre le temps et se plonger dans le code existant (ce qui casse le patch -spontané corrigeant un problème local), mais aussi parce que plus un projet -devient imposant, plus il acquiert une inertie qui l'empêche d'évoluer -facilement. - -.. _Utiliser les styles: https://help.libreoffice.org/Writer/Styles_in_Writer/fr - - -.. _Arielle Fragassi: http://www.flickr.com/photos/toastytreat/4555895229/ diff --git a/content/images/desire.jpg b/content/images/desire.jpg new file mode 100644 index 0000000..684ef63 Binary files /dev/null and b/content/images/desire.jpg differ diff --git a/content/images/time/1135634742_0b4735dab5_m.jpg b/content/images/time/1135634742_0b4735dab5_m.jpg new file mode 100755 index 0000000..04c12f8 Binary files /dev/null and b/content/images/time/1135634742_0b4735dab5_m.jpg differ -- cgit v1.2.3