Soubresauts.net

Je place ici le journal écris sur linuxfr et qui m'a conduit à ajouter le petit bouton « liseuse » qui se trouve dans la colonne de gauche et continuera a évoluer. Je continuerais d'ajouter à cette page les différents développement que je pourrais trouver.

Une petite introduction pour dire que je suit d’assez prêt le développement de la littérature contemporaine, en particulier sur internet et que mes réflexions m’amène à discuter assez souvent avec les responsables de la coopérative d’édition publie.net¹ fondée par François Bon. À lire de nombreux textes sur le net (sur des sites et blogs, ou sur la liseuse de l’immateriel.net⁸), je reste souvent frustré lors de lecture « dense » de la qualité de lecture qu’on peut obtenir sur les différentes plateformes et j’ai fini par concevoir une idée de ce que pourrait être la liseuse idéal (à défaut d’être parfaite…).

Cette interface à deux objectifs :

Interface très propre et simple
Je pense ici aux logiciels d’écriture comme pyroom⁹ et autres darkroom ou Q10¹⁰. Rien d’autre que le texte et un repère de l’avancé dans celui-ci. Pour autant ça ne veut pas dire aucuns réglages, au contraire.
Compte tenu de la diversité des écrans à l’heure actuelle (téléphones, tablette, écrans larges, écran pivotants), on ne peut pas imaginer une seule mise en page pour un texte. Il me semble donc important qu’une interface de lecture permette des réglages fin de choses comme police, taille de police, interligne, retrait première ligne, couleur du fond, de la page, largeur et hauteur de la page, marges haute. Mais, aussi, comme c’est le cas dans pyroom (pas testé les autres), propose des réglages par défaut fondés sur une détection automatique de l’appareil, ainsi que la possibilité d’enregistrer ses propres réglages.

Ergonomie du défilement
L’autre question qui m’intéresse est la façon dont on affiche un texte sur un écran et celle dont on navigue en son sein. Je ne vais pas faire trop long mais à l’heure actuelle c’est assez triste. Le pire étant les plugins flash, avec vrai-fausse page qui tourne et bruit de la page. On attend l’odeur d’incunable diffusé par l’ordi. Notons que c’est ce qui a été repris (avec étagère virtuelle en bois, excusez du peu) dans l’ipad™ de M. Pomme, roi de l’ergonomie, c’est bien connu. Il y a mieux, comme la liseuse de l’immatériel.net², le plugin epub³ pour firefox, ou fbreader⁴.
Or je crois qu’il faut qu’on se sépare de l’idée de « page » en tant qu’entité unique contenant un nombre fini de caractères. Puisque je veux pouvoir changer la taille de mes caractères et la largeur de mon texte, que par ailleurs chaque écran est de taille fixe, la quantité affichée à l’écran est variable, il faut donc que me déplace dans cette page. Différentes solutions :

* une page d’une taille choisie par le lecteur mais qui entre forcément totalement dans l’écran (je ne fais _rien_ défiler), et il faut que je passe d’une page à l’autre : on passe d’une page à l’autre en appuyant sur une touche, ou cliquant, un geste… La page suivante vient remplacer la précédente, avec la possibilité de reprendre en haut de cette nouvelle page n lignes du bas de la précédente (proposé par fbreader). Si il doit y avoir animation, plutôt qu’une page qui tourne, je verrais plutôt un carrousel horizontal, comme le passage d’une page d’appli à l’autre dans l’iphone (et pas un « cover flow »). Mais surtout pas de défilement vertical d’une page à l’autre (cf. lecteurs de pdf) ; ça n’a aucun intérêt puisqu’on a déjà lu la page, aucun intérêt de la voir défiler. Il faut minimiser au maximum le temps que prend le passage d’une page à l’autre.

* une très grande page (sans rupture), de la taille du texte entier, ou du chapitre, selon, il faut que je la fasse défiler verticalement. Plusieurs solutions :
— défilement « web » classique, à la molette ou au doigt pour les écran tactiles, valable que pour de courts textes, c’est fatiguant pour le doigt et on s’y perd vite ;
— défilement automatique à la firefox : on clique n’importe où dans la page et en restant cliqué, plus on s’éloigne du point de départ, plus on défile vite. Fatiguant pour les doigts et pour les yeux ;
— un défilement automatique « vrai » (essayer dans empathy⁵) ; comme ci dessus, mais on ne touche à rien, c’est un mode « prompteur » plutôt très confort, mais la vitesse linéaire est un peu fatiguant à la longue.

* une solution intermédiaire assez séduisante, le mode « never ending page », développé pour un lecteur⁶ sur pda. Allez voir les animations, c’est en gros un mode page par page mais avec un défilement automatique qui remplace la page au fur et à mesure qu’on la lit, une fois en bas de la page, on remonte dans la même page… c’est la suite du texte !

Là encore, je ne crois pas que le choix doive être imposé, tout dépend du type de texte (je voudrais lire « la nuit juste avant les forêts » B-M. Koltès comme une seule longue page), de l’appareil sur lequel il est lu, par qui (facultés visuelles) et dans quelles circonstances (métro, maison, sur scène…)

Reste la question de comment se repérer dans le texte s’il n’y a plus de page. La solution que je voie est assez simple : c’est le mot qui devient la référence, et plus la page. On place donc un signet sur un mot ou un groupe de mots et on dit à quelqu’un « va lire à 2 kilo-mots ». On peut aussi imaginer utiliser les %, mais c’est moins précis.

Ce journal est déjà trop long, mais il faudrait bien entendu parler des fonctions de signets, notes recherche et historique.

le tout, dans le navigateur !
Pour remplir les objectifs d’une telle interface, me semble que le navigateur est un très bon candidat :
— il est présent sur de nombreuses plateformes (toutes sauf le livre numérique, en fait) ;
— il est en évolution et amélioration permanente et de plus en plus capable d’un point de vue de la typo (ligatures, polices otf, utf8, etc.) ;
— il intègre un moteur de css qui sait déjà lire le html + css et donc le xml + css (epub) ;
— les textes numériques que nous lisons proviennent du net, il me semble logique que le navigateur soit celui qui les ouvres. Imaginez par exemple un simple bouton en bas d’un billet de blog(ue) qui serait disponible dans les CMS et qui m’ouvrirait le billet courant dans ma liseuse, dans un nouvel onglet. Je, lecteur, suis débarrassé de toutes ces applettes qui encombrent les colonnes et, corolaire, cela permet aussi à l’auteur du blog de ne pas cantonner son site à un blanc ou un noir uni, justement pour permettre la lecture : le texte dense est lu dans une interface qui lui est dédiée, la navigation se fait dans le site, mais on reste dans le navigateur ;
— les navigateurs savent maintenant stocker du contenu pour utilisation hors-ligne ;
— les navigateurs savent synchroniser ce qu’ils contiennent ;
— d’éventuels liens sont ouvert dans ce même navigateur ;
— les navigateurs gèrent déjà les images, le son et la vidéo ;
— ouvrir un dictionnaire devient très facile ;
— technologies libre ;
— tout ceci n’est pas très « DRM-compliant », mais je m’en moque. Je crois que les DRM du livre sauterons comme ceux de la musique et espère bien pour finir une sortes de licence globale et des appareils tout le temps connectés.

Voici donc l’état de mes réflexions, et en quelques sortes le « cahier des charges ». En fait, mes compétences ne me permettent pas de savoir si c’est réalisable ou pas (enfin un partie, si c’est certain, ce sont les histoires de défilement qui sont sans doute plus compliqués), mais quand je vois ce que Paul Rouger⁷ qui officie chez mozilla arrive à faire en html5, je me dis qu’il y a de l’espoir. D’ailleurs s’il me lit, ou si vous pouviez lui transmettre ce message… Si nous arrivons à faire quelque chose, j’ai bon espoir qu’il y ai rapidement quelques textes sur publie.net qui soient utilisés comme test sur toile réelle.

Voici pour finir trois « mockup » de ce à quoi pourrait ressembler cette interface :
— en mode « lecture » ;
— en mode « réglage » ;
— détails de la navigation ;

Grâce aux commentaires j’ai découvert deux extensions firefox qui peuvent aussi s’utiliser comme un bouton situé dans la barre des signets :
— Redability
— Tidyread
Un lecteur de fichier epub uniquement avec un javascript et des css : epub zen garden

Ce qui me paraît dommage avec ces boutons c’est que c’est le lecteur qui utilise ces outils pour compenser un défaut d’ergonomie du site. Je trouve bien plus intéressant que ce soit le propriétaire du site qui le propose à son lecteur. De plus il serait intéressant d’offrir d’autres réglages. Voir des systèmes automatiques qui, détectant la résolution de l’écran en déduirait des réglages à proposer.

[1] http://publie.net
[2] http://publie.net/tnc/spip.php?rubrique124 fonction des textes un mode « livre virtuel » ou défilement vertical de pages
[3] http://www.epubread.com/en/
[4] http://www.fbreader.org/
[5] http://live.gnome.org/Evince/
[6] http://maksee.narod.ru/palm/rta/
[7] Si vous ne l’avez pas encore fait, allez tester sa démo d’un éditeur d’images en ligne et en html5 : http://hacks.mozilla.org/2010/02/an-html5-offline-image-editor-and-uploader-application/
[8] http://www.immateriel.fr
[9] http://pyroom.org
[10] http://www.baara.com/q10