Avec le texte au format numérique, à la mise en page liquide, chacun peut changer les paramètres élémentaires. Il faudrait être typographe soi-même pour lire son livre savamment et ne pas jeter plus de mille ans de connaissance de mise en forme du texte. Pour un professeur, la perspective d’un retour à l’école de tous ces lecteurs en quête de connaissances typographiques est assez joyeuse !

Philippe Millot - qui est dessinateur de livres - abordait il y a quelques semaines une excellente question. Les applications qui lisent les livres numériques sont nombreuses (intégrées dans les liseuses, proposées sur les tablettes ou les ordinateurs, disponibles en ligne via un navigateur), et proposent un nombre plus ou moins important de choix de réglages (de la police aux marges, en passant par les couleurs). Potentiellement n’importe qui peut modifier les paramètres originaux d’un livre numérique, la mise en page n’est plus forcement celle qui a été pensée pour le livre, mais un choix - potentiel - du lecteur. Choix qui peut faciliter la lecture (police plus lisible), ou qui peut être désastreux à la fois pour le lecteur et le livre. Choix qui peut remettre en cause le rôle du graphiste - ou graphic designer.
Il y a même des cas où le “style de l’éditeur” est remplacé - par défaut - par le style proposé par l’application (c’est la mauvaise surprise que j’avais eu avec la Bookeen).

Il y a quelque chose de beau dans cette possibilité de choix typographique des lecteurs. Mais c’est aussi particulièrement effrayant. N’y a-t-il pas un risque à ce que nous nous perdions dans ces possibilités ? Peut-être aussi que cette “ouverture” n’est que temporaire…

La découverte de todo.txt me fait rendre compte d’une chose : il faut abandonner les applications pour des systèmes simples qui reposent sur des syntaxes. En cherchant des outils numériques, j’ai trop souvent fait l’erreur de partir de l’interface - du point de vue de l’ergonomie - plutôt que des réponses précises à des besoins.
De la même façon que Markdown simplifie l’écriture et la gestion de celle-ci - parce que le texte et les métadonnées sont dans un simple fichier lisible partout - todo.txt simplifie la gestion d’une liste de tâches grâce à un seul fichier texte. L’interface n’est plus au centre de l’utilisation.
Il est toujours possible d’imaginer des accès et des interactions - simples mais reposant sur des systèmes complexes - qui interviennent sur ces fichiers. Jekyll, le générateur de site statique, part des fichiers écrits en Makdown pour la partie contenus. Todo.txt peut être synchronisé avec des services tels que Ubuntu One, et une application permet une gestion sur des supports mobiles.

Abandonner les applications pour des systèmes simples qui reposent sur des syntaxes, cela permet :

• une simplicité d’usage après un - court - temps d’apprentissage ;
• une interopérabilité : lisibilité de l’information dans la majorité des contextes (par exemple dans les cas de Todo.txt et Jekyll on peut revenir aux fichiers lisibles par n’importe quel éditeur de texte) ;
• la pérennité (valeur qui varie selon l’utilisation, pour une todo liste c’est tout de même très relatif sur la durée) ;
• de ne pas alourdir les serveurs : limiter les requêtes ;
• de favoriser les usages hors ligne, plutôt que la connexion permanente pour accéder à des interfaces web par exemple.

Le cas d’une liste de tâches

La todo liste peut être considérée comme un gadget, ou comme un outil de gestion des tâches, et donc d’organisation du travail, tout dépend du point de vue.
J’ai utilisé myTinyTodo pendant presqu’un an, mais cette application est trop lourde : nécessité d’une base de données et accès via une interface web.
Je lorgne sur Nitro : fonctionnement similaire avec un système plus simple mais qui nécessite l’utilisation d’un client ou d’une interface web pour interpréter et modifier le fichier .json ; possibilités d’utilisation hors connexion.
Trello est attrayant, mais cet outil n’est utilisable qu’avec une connexion, et on a pu constater la fragilité de son infrastructure lors de la tempête Sandy.
Todo.txt est intéressant parce que c’est l’occasion d’apprendre une nouvelle syntaxe - certes simple - et de modifier ma façon de travailler avec les outils numériques.

La diversité des sites web dans leur forme et leur rendu est nécessaire, parce qu’il n’y a pas un Web.

Quelques notes

Une liste rapide des éléments qui font la diversité des sites web, et qui concernent plutôt les carnets, les blogs ou les petits sites :

• l’architecture des sites ;
• la construction des URL : par exemple des URL compréhensibles (mentions du titre, de la catégorie, de la date de publication…) ;
• la structuration de l’information : la hiérarchisation de l’information, les niveaux de titres, les métadonnées visibles…
• l’ergonomie : comment naviguer de billets en pages, entre les rubriques et les catégories, comment rechercher dans le site, comment savoir où l’on est ;
• le graphisme : les choix typographiques, la “charte graphique”, la lisibilité du texte et du rapport texte/image ;
• l’adaptabilité : comment le site va s’adapter aux différentes tailles d’écran, de la non-adaptation au responsive design en passant par la version mobile ;
• comment est pensée l’entrée dans le site ;
• …

J’ai toujours été admiratif des sites faits à la main, ou des personnalisations très poussées de CMS connus, ce sont de telles initiatives qui permettent d’avoir une diversité de formes sur le Web.

Wordpress : des dégâts collatéraux ?

On ne peut pas dire que Wordpress contribue à la diversité du Web, tant dans sa structure que dans sa forme - mais plutôt dans sa forme. Peut-être que Wordpress permet une facilité de publication sur le Web au détriment d’une certaine diversité. Combien de fois je reconnais un carnet, blog ou site réalisé avec ce CMS ?
C’est un peu le même constat avec Octopress lorsqu’on visite la liste des sites réalisés avec ce générateur. L’ergonomie et les choix typographiques de ce carnet devraient bientôt évoluer.

J’observais l’espace entre deux hirondelles, cherchant à comprendre comment la durée se transforme en distance.

Ces derniers jours/semaines, plusieurs articles sur le constat - discutable - de la perte d’un Web idéal idéalisé. Loin de moi l’envie de revenir sur le fameux billet déclencheur (traduit sur Framablog). En revanche les réactions sont passionnantes.

Clochix parle de génération : c’est réaliste, les usages évoluent et sont surement assez éloignés de ceux des pionniers du Web. Si on ne le constate pas forcement dans nos propres pratiques de geeks ou d’intéressés, c’est souvent le cas autour de nous.
Et pourtant, j’ai moi-même moins de trente ans et je ne veux pas de ce Web que les gros nous vendent, ce carnet le prouve d’une certaine manière - tout en restant conscient que c’est très différent pour mon entourage.

Karl Dubost évoque l’idée de David d’offrir des noms de domaine, qui ne semble pas si surréaliste. Donner les moyens d’entrevoir un Web réellement décentralisé : cela ne se joue pas uniquement sur le terrain du Web, cela va bien au-delà, autant en principe qu’en pratique.

Olivier Meunier relativise lui aussi : “Il y a toujours une alternative et si elle n’existe pas, elle ne demande qu’à être créée.” Après tout les questions d’usage nous appartiennent.

Nicolas Hoffmann pose les termes du débat sur la notion de choix, il a cette formule dure et juste : “La seule chose qui soit un frein à votre détermination à faire des choses, disons-le franchement, est dans votre miroir. Vous avez le choix, vous avez toujours le choix.”

Ces billets contrebalancent le constat d’Anil Dash, ou plutôt démontrent l’existence de la diversité d’un Web qui se pense, et donc la réalité - et non la promesse - d’un Web qui est autre chose que ce que les apparences et la majorité des usages peuvent laisser croire. Tout dépend de nos choix et de nos pratiques. J’ai d’ailleurs découvert ces billets de carnets en carnets, hors des réseaux fermés.

Je ne mets plus les noms des alphabets à la fin des livres, car je me suis rendu compte que certains d’entre nous [designers graphiques] prennent des raccourcis avec l’expérience, et c’est jamais bon. […] Qu’ils fassent pareil ne me dérange pas dans le fond, quoique, mais il faut qu’ils le trouvent. Il faut travailler un peu quand même. Parce que ce qui est là ce n’est pas parce qu’on en a l’idée cinq minutes avant ou dix minutes avant, mais parce que ça fait vingt ans qu’on travaille. Et ça ça n’est comme ça que parce que ça fait vingt ans que je travaille. Le livre je ne le faisais pas comme ça il y a quinze ans. […] Je ne mets pas le nom, mais il y est l’alphabet. Tous le monde peut le regarder et se dire “ah c’est cet alphabet là, d’accord…”.

Cette citation pose la question de la réutilisation et de la copie du travail des graphistes ou “designers graphiques” : mises en page, associations typographiques, choix de papiers…
Philippe Millot est “dessinateur de livres”, il a dessiné (entre autres) des livres aux éditions Cent Pages, ces objets sont des merveilles de création typographique. Difficile de lire d’autres livres après avoir découvert ceux de Cent Pages ; même chose pour les livres des éditions B42 par exemple.

Le livre numérique, au format ePub et sans DRM, est ouvert. On peut très facilement voir comment le livre est conçu en décompressant le fichier (après l’avoir renommé en .zip) et en observant les différents fichiers : XML, feuilles de style CSS, métadonnées, fontes. On découvre alors les choix typographiques : polices utilisées, marges, espacements, structuration du contenu (chapitres, pages, niveaux de titres…), couleurs des textes et des fonds… Ce qui pouvait être caché dans un livre papier se dévoile en quelques clics.

Le travail des graphistes est-il désacralisé, parce que visible ? D’un côté il semble que ceux qui viennent du Web n’y voient aucun problème, habitués par cette ouverture. Les faiseurs de livres papier acceptent-ils ce postulat inscrit - pour le moment - dans les livres numériques ?
Est-ce que cela changera quelque chose dans le processus de création et de mise en page ?
Quand bien même cela est potentiellement visible, combien de lecteurs iront voir le “code source” d’un livre numérique ?

Wordpress n’est pas un outil d’écriture naturel

En tout cas pas pour moi. Pour écrire un article il faut :

• disposer d’une connexion Internet ;
• ouvrir un navigateur web ;
• se connecter à l’interface de Wordpress ;
• créer un article ou afficher celui sur lequel on souhaite intervenir ;
• être contraint d’écrire dans le wysiwyg de Wordpress.

On peut trouver plusieurs moyens de contourner la contrainte du wysiwyg de Wordpress :

• utiliser un client pour Wordpress, mais aucun n’est satisfaisant : Blogilo bugg, l’application pour Android ou iOS est une application avec tout ce qu’elle comporte comme limites (mise en forme, gestion des versions hasardeuse, pas d’équivalent pour Linux…) ;
• pendant un temps j’ai écris mes articles en HTML, en effectuant un copier-coller dans le wysiwyg ;
• pour le moment j’écris mes billets en Markdown, avec également un copier-coller dans le wysiwyg, en utilisant le plugin Markdown on Save Improved pour Wordpress.

Ces deux dernières solutions ne sont pas satisfaisantes : les articles écrits en HTML ou en Markdown sont bons à jeter puisque les ultimes modifications sont faites dans le wysiwyg.
Cette façon d’écrire les billets n’est pas vraiment tenable sur la durée - plus pour des raisons de principe que techniques, car ce n’est pas pour le nombre de billets que j’écris…
Wordpress correspond à une utilisation d’Internet qui n’est plus la mienne : être connecté pour écrire.

“Obsolescence injectée dans l’écrit”

Pour un carnet de ce type, l’utilisation d’un CMS de la puissance et de l’envergure de Wordpress semble disproportionnée. Et Wordpress est un système qui nécessite d’être mis à jour et maintenu régulièrement.

Nicolas Taffin le dit diablement bien :

@antoinentl oui, je ne crois pas aux CMS. Obsolescence injectée dans l’écrit. Retour au Gopher ? J’adorais #1990’s

Dissocier l’écriture du moteur du carnet

C’est le point qui me semble le plus important. L’écriture se fait ailleurs que dans le moteur du carnet. Je peux décider d’utiliser un autre générateur ou un CMS, puisque les articles existent en dur, avec leurs métadonnées propres.

Migration

Tout ça pour dire que je vais (enfin) migrer sans tarder vers un générateur de sites statiques (j’en parlais déjà là). Après quelques tests Octopress (framework basé sur Jekyll) est le plus simple à prendre en main. Sans rentrer dans les détails cela me permettra :

• de me passer de wysiwyg : on peut écrire en Markdown dans n’importe quel éditeur de texte, l’écriture est dissociée du moteur du carnet ;
• de conserver tout ce que j’écris sans me soucier de la façon dont est généré ce carnet ;
• de gérer le site en local et d’y effectuer les relectures nécessaire avant la mise en ligne (séparation de l’écriture et de la publication) ;
• de disposer d’un site portable en HTML ;
• …

J’avoue qu’au début je comptais faire un billet sur les bienfaits d’écrire en HTML, et puis la lecture d’un énième article sur les qualités de Markdown (celui de David Bosman) a fini de me convaincre que c’était une erreur, je dois bien l’avouer. Et pourtant ce n’était pas faute d’avoir lu de nombreux billets de Karl Dubost à ce sujet.

Pourquoi Markdown ?

Je n’ai jamais pu supporter les “wysiwyg”, certains sont meilleurs que d’autres mais aucun n’est parfait ou même satisfaisant. Écrire sur le Web implique forcement de prendre un minimum en compte le HTML, au moins ses balises les plus simples, au moins pour comprendre comment un document HTML est structuré - je ne dis pas non plus qu’il faut forcement écrire directement en HTML. Même le wysiwyg de Wordpress fait parfois mal les choses :

• insertion de codes supplémentaires et inutiles ;
• utilisation de balises invisibles même dans la version “code” ;
• génération ou interprétation de balises au moment de l’affichage.

Depuis plusieurs mois je rédige mes billets dans Sublime Text 2 en HTML, et je fais un copier-coller dans l’onglet de code de Wordpress, je n’ai pas encore trouvé d’outil pour exporter les contenus des billets autrement, et c’est pourquoi j’avais envisagé de passer à PluXml. De cette façon je sais exactement ce que j’écris, à la fois sur le fond (le contenu) et sur la forme (le code HTML).
Markdown permet d’écrire dans n’importe quel éditeur de texte, par exemple avec une extension .txt ou .md.

Quelques outils à utiliser avec Markdown

Avant tout il faut jeter un oeil à la syntaxe Markdown, Michel Fortin explique tout cela très bien, et en français.
Pour écrire les billets j’utilise donc Sublime Text 2.
Un plugin permet d’interpréter le Markdown directement depuis l’éditeur de l’interface web : Markdown on Save Improved.

Quelques questions en suspens

Concernant Markdown :

• comment faire pour indiquer l’ouverture de liens dans une nouvelle fenêtre ?
• quel outil de “rendu” utiliser en parallèle de Sublime Text 2 pour voir sur deux écrans le Markdown et le résultat, et le tout sous Ubuntu ?
• quel outil utiliser sous Android pour écrire ?

Plusieurs choses me tracassent sur l’écriture numérique, Markdown vient renforcer ces interrogations (tout en y répondant un peu) :

• comment “envoyer” des fichiers Markdown directement vers Wordpress sans passer par l’interface web et faire du copier/coller ?
• comment récupérer tous les billets en Markdown qui seront désormais créés sous cette forme ?

Donc

Avec Markdown c’est tout comme écrire en HTML, sans la contrainte d’un langage certes simple mais lourd. Markdown me permet de maîtriser l’écriture web. Une demie-heure de rédaction de ce billet m’aura suffit à m’adapter à cette syntaxe.