Jugez un ebook sur son rendu,

Jugez un ebook sur son rendu,

Fran­che­ment, je me moque du code source. Faites des livres numé­riques avec du code horrible, ce qui m’im­porte c’est qu’il soit utili­sable partout, au mieux.


Je prends donc le contre-pied total de Jiminy :

Jugez un ebook sur son rendu,
c’est unique­ment pour cela qu’il existe.

Le rendu c’est l’as­pect graphique, la typo­gra­phie, l’adap­ta­tion à diffé­rents écrans, l’ac­ces­si­bi­lité, les extrac­tions textes, la compa­ti­bi­lité avec les outils divers et variés…

L’exemple parfait nous vient du PDF. Il y a des PDF très bien faits, acces­sibles, utili­sables, compa­tibles. Personne n’ira regar­der à l’in­té­rieur, et cet inté­rieur est très fréquem­ment effec­ti­ve­ment une soupe infâme géné­rée par un logi­ciel d’édi­tion. Je n’ai aucun problème à ce que l’EPUB prenne le même chemin.

* * *

L’ar­ti­san expert a un atta­che­ment émotion­nel fort avec ses outils, et peut conti­nuer à les chérir et les utili­ser quand bien même ils ne seraient pas indis­pen­sable. Il reste que ces outils ne sont qu’un moyen de parve­nir à une fina­lité, pas la fina­lité elle-même. Le code interne n’est qu’un outil, rien de plus.

Faut-il promou­voir un code simple et « propre » dans les EPUB ? La ques­tion est pure­ment tech­nique et ne devrait inté­res­ser que les concep­teurs. Hors atta­che­ment émotion­nel, la ques­tion est simple­ment de savoir ci ce code simple et propre est néces­saire.

*

Nous avons eu le débat il y a envi­ron 10 ans dans le milieu du déve­lop­pe­ment web, pour les mêmes tech­no­lo­gies. Aujourd’­hui faire du code simple et propre est devenu une bonne pratique incon­tour­nable. Les Dream­wea­ver et autres GO Live ont disparu. Si l’es­sen­tiel du code reste du code généré par des outils, il sera jugé en fonc­tion de sa ressem­blance avec du code déve­loppé main par un arti­san. À l’époque la compa­ti­bi­lité, l’évo­lu­ti­vité, la perfor­mance et le coût de main­te­nance nous ont entrai­nés dans cette direc­tion.

Doit-il en être de même pour l’EPUB ? Je n’en sais rien, ce d’au­tant plus que la concep­tion d’EPUB n’est pas direc­te­ment mon métier.

Je ne suis par contre pas convaincu que les argu­ments qu’on avait pour les pages web il y a 10 ans valent pour les EPUB aujourd’­hui : Les livres sont peu modi­fiés une fois publiés. On s’ap­proche plus d’un format final d’ex­port comme le PDF qu’un docu­ment en évolu­tion perma­nente comme le gaba­rit d’un site web.

Le débat s’ouvre d’ailleurs de nouveau aujourd’­hui pour les sites web. Avec certains frame­works Javas­cript, le format de travail tend à s’éloi­gner gran­de­ment du code tech­nique rendu par les navi­ga­teurs. Pourquoi faudrait-il appliquer les mêmes bonnes pratiques à ce dernier alors que les contraintes et avan­tages y sont diffé­rents ?

*

J’ai un passé d’ar­ti­san du web. J’étais moi-même mili­tant de cette vision à l’époque. J’ai donc forcé­ment tendance à encou­ra­ger les arti­sans du livre numé­rique, ceux qui aiment le code bien fait, qui en prennent soin, qui font atten­tion aux détails.

En prenant du recul, toute­fois, main­te­nant que je ne suis plus partie prenante, je me moque du code tech­nique interne. C’est un débat de tech­ni­ciens. Si un jour on me montre des EPUB avec un code infâme mais dont le rendu – au sens large – est bon, je n’au­rai aucun mal à le prendre en exemple.

Nous sommes malheu­reu­se­ment en réalité encore loin de ce débat. Ceux qui génèrent du code mal fait sont aujourd’­hui très loin de géné­rer un bon rendu. Typo­gra­phie, compa­ti­bi­lité et acces­si­bi­lité sont rare­ment au rendez-vous.

Photo d’en­tête sous licence CC BY par Vicky Hughes­ton


5 réponses à “Jugez un ebook sur son rendu,”

  1. Tl;dr: je ne suis pas forcément en désaccord avec ton billet, à considérer qu’on passe d’ailleurs une grosse partie du processus de fabrication à vérifier les fichiers sur des solutions de lecture, on peut même dire que le rendu est une autre chose sur laquelle on juge — et tiens, on a même ce discours là en formation.

    Pour développer :

    1. Oui c’est une discussion technique dont les lecteurs n’ont pas à se soucier — et jamais il n’a été dit le contraire d’ailleurs, le contexte du blog ne laisse à mon avis aucun doute là-dessus.

    Je sais que certains en viennent à imaginer que c’est un débat global que j’essaye de pousser, donc que les lecteurs s’approprient ce débat, ce serait quand même je pense me considérer comme un extrémiste totalement idiot en ne faisant pas la part du contexte dans lequel les billets sont publiés. Je ne vise personne mais ça arrive à d’autres aussi apparemment…

    2. Ce qui a fait naître ce billet, c’est la réaction d’un lecteur qui modifie ses fichiers — ce qui est de plus en plus courant, justement parce que le rendu n’est pas bon. Et je considère que ce genre de témoignage devrait être un message d’avertissement pour la communauté des gens qui fabriquent ces fichiers.

    3. Le PDF, avec tout ce qu’il cache derrière son rendu, peut également servir d’exemple lors de la tenue d’un discours du type « attention les mecs, si vous ne faites pas attention, y’a un risque qu’on n’avance plus à un moment ».

    Il y a une idée qui veut que pour le PDF reflow, tout bon logiciel supporte la fonctionnalité. Oui mais non. Pour m’être intéressé à ceci en particulier et avoir fait des recherches conséquentes, il se trouve que c’était tellement devenu le bordel d’un point de vue technique que les développeurs des logiciels préféraient passer leur tour sur la fonctionnalité ou n’arrivaient pas à l’implémenter convenablement. Et beaucoup ont essayé.

    Ce n’est pas une question de bon ou mauvais logiciel au final (et les gens qui font du PDF reflow vont systématiquement tenir ce discours) mais une problématique de pan technique qui est devenu ingérable au point où on ne se donnait plus la peine de supporter des fonctionnalités à valeur ajoutée.

    C’est un événement de l’Histoire que nous avons oublié et que nous résumons aujourd’hui à bon ou mauvais logiciel alors que c’est bien plus complexe que ça.

    4. Comme tu le soulignes bien, on est encore loin de ce débat. Le rendu, il faut aussi le vérifier quand l’utilisateur désactive la feuille de styles. Là, il n’y aura plus que la structure qui sera rendue à l’écran et ça pourra par extension donner une idée de comment le tout sera géré par les outils d’accessibilité.

    Vérifier le rendu est épuisant, frustrant et on peut très rapidement en venir à se taper la tête contre les murs, d’où l’approche que j’essaye d’encourager et qui consiste à structurer le mieux possible pour éviter de perdre du temps. C’est même pas pour moi au final, parce que je le fais et que ça fait gagner en sérénité, c’est juste une façon de faire que je partage parce que Dieu sait qu’une bouillie de paragraphes et de span finit toujours par poser des problèmes ; on le voit et on l’entend chez les lecteurs qui ne devraient pas avoir à s’en préoccuper (oups, il change de typo, tous les italiques sautent par exemple).

    5. J’aimerais sincèrement ne pas avoir à me soucier de ce qui sort pour me concentrer sur tout le reste (typo, design, etc.) mais il n’y a qu’avec iBooks Author que je peux me le permettre aujourd’hui, environnement clos aidant (j’en ai même parlé il y a deux jours sur Twitter, en disant que ça pouvait être un support d’enseignement de design éditorial (numérique).

    Là, pour rappel, nous avons un fournisseur d’outils à la pdm majoritaire qui ne prend même pas en compte son propre moteur de rendu pour traiter l’export EPUB. Du coup, les utilisateurs des outils créent des scripts (passer le formatage local en style de caractères, toutes caps, overrides locaux, enlever les accents des styles, etc. ) parce qu’ils perdent justement un temps incommensurable à juger sur le rendu.

    Toutes ces choses auraient pu être faites automatiquement lors de l’export. C’est d’ailleurs ce que certains plugins font pour LibreOffice par exemple : ce qui peut poser problème est corrigé à l’export, parce que les développeurs veulent pouvoir atteindre cet objectif de non-préoccupation par rapport au code côté utilisateur.

    Malheureusement, quand tu remontes des infos à certaines boîtes, infos qui pourrait simplifier la vie des utilisateurs, elles s’en foutent, la course aux fonctionnalités passent avant tout, quitte à oublier tout ce qui concerne l’expérience du lecteur (on a quand même du js exporté pour le fixed-layout qui ne « preventDefault » pas et qui fait donc apparaître/disparaître les menus des apps à chaque fois que le lecteur lance une interaction.

    6. On juge sur le rendu, parce que c’est nécessaire, parce que c’est ce que le lecteur va voir. Ça me paraît naturel au point où effectivement je suis amené à ne pas en parler dans des articles déjà fort longs par ailleurs et me concentrer sur d’autres choses. S’il faut vraiment que je clarifie, je le ferai volontiers avec un article dédié.

    Mais j’avoue cependant avoir du mal avec les gens qui, en lisant le titre de ton article, se sont réjouis que tu ne penses pas la même chose que moi et se sont empressés de me le faire remarquer même indirectement. Ce n’est pas comme si tout le monde pouvait donner son opinion là-dessus et participer à une conversation, d’autant que nous sommes les premiers à accueillir les retours et expliquer pourquoi nous en sommes venus à adopter cette approche là. Mais non, personne ne veut discuter, personne ne veut écouter les autres et tout le monde en pâtit.

    • Argh, toutes mes confuses pour ton dernier paragraphe. Il va falloir que j’arrête avec les titres tranchés. Ce d’autant plus que je suis – tu le sais – un artisan par nature, historiquement sur les mêmes technos que toi, donc j’ai effectivement l’amour de ce code bien fait. Je suis non seulement heureux de voir comment tu travailles mais en plus je trouve ça indispensable.

      Accessoirement, l’avis de gens qui ne lisent que les titres et se forgent une opinion sans aller plus loin dans le fond, au moins tu sais que tu peux les ignorer voire te moquer d’eux.

      Maintenant côté vêtement j’achète de l’industriel. Côté meubles j’achète de l’industriel. Je ne sais pas, aujourd’hui si l’ebook artisanal est amené à être une niche émotionnelle ou un pré-requis de qualité. Il est clair que l’essentiel de la grosse édition tend à vouloir passer en industriel, quitte à avoir une qualité plus faible. Pour l’instant la plupart des acteurs manque même la base donc ils ne sont de toutes façons pas à mettre en exemple.

      Merci pour ton retour sur le reste

  2. Note que qu’une partie des efforts artisanaux, si je puis me permettre l’expression, pourraient très bien être intégrés à de l’industriel. C’est ce que j’avais essayé d’expliquer avec l’article sur la conversion.

    Dans l’idéal, donc, on connaît les problématiques et les moyens pour obtenir la base sur de l’industriel mais, ô surprise, ça n’intéresse aucune boîte qui fait de l’outil ou de l’automatisation.

    De toute façon, en général, ils sont même à te dire qu’on s’en fout et que les solutions qui ont été choisies l’ont été parce que ça « passait partout en visuel » — sauf que… comprendre par là « quand le lecteur change un truc, ça ne change pas et ça reste comme on veut que ce soit ; l’accessibilité, c’est pas la priorité pour le moment » puisque j’ai eu plusieurs échanges à ce sujet.

    Après, s’il nous prenait l’envie demain, on pourrait très bien commercialiser des outils qui automatisent certains processus de fabrication mais, puisque ça n’intéresse de toute manière personne, autant dire qu’on perdrait beaucoup de temps pour rien. On avait d’ailleurs parlé d’un soft ajoutant les insécables si mes souvenirs sont bons. ;-)

    • Ajout :

      Après, le débat est de toute manière complexe puisqu’il faut également prendre en compte le fait que très souvent, on se trouve dans l’industrialisation humaine : certains font sous-traiter ailleurs et payent très très peu les « usines à EPUB » qui réalisent le boulot manuellement.

      Ça, c’est quelque chose dont le boss d’inkling avait plutôt violemment parlé dans une présentation il y a quelques années, souhaitant justement révéler le sale petit secret de l’industrie de la presta numérique sans que ça ne trouve de réel écho en France, bizarrement.

      Et on peut aussi le voir avec des responsables numériques chez les éditeurs US, les directives techniques qu’ils donnent à ces sous-traitants ne sont jamais respectées et ils passent un temps fou à repasser derrière pour que ça devienne au moins potable. Si bien que certains ont justement décidé de développer un CMS pour gérer le numérique en interne.

      Ça se fait aussi en France, je peux le confirmer personnellement. Et quand tu fais de l’audit, en tout cas pour moi, tout part du rendu et tu remontes ensuite dans le « code » pour voir où ça pose souci. Donc ouais, on juge au rendu et on creuse, je devrais peut-être le clarifier dans un article, d’autant que ces problèmes de rendu illustrent chaque point technique abordé dans le compte rendu ensuite.

      J’ai une belle collection de captures d’écran, des images d’un chapitre entier qui ne s’affichent pas sur l’app d’un gros revendeur à cause d’un accent dans le nom de la première image utilisée à la police qui bug complètement sur l’app d’un autre gros, en passant par le text-to-speech qui t’annonce un truc incompréhensible pour des images décoratives.

      J’ai longtemps cherché à faire toujours plus — et je continue encore — mais je pense qu’il ne faut pas oublier les vertus de la simplicité au final : si la structure est à l’épreuve de toutes les modifications, autant se simplifier la vie et faire l’effort là-dessus.

  3. À propos de :

    « […] Malheureusement, quand tu remontes des infos à certaines boîtes, infos qui pourrait simplifier la vie des utilisateurs, elles s’en foutent, la course aux fonctionnalités passent avant tout, quitte à oublier tout ce qui concerne l’expérience du lecteur (on a quand même du js exporté pour le fixed-layout qui ne « preventDefault » pas et qui fait donc apparaître/disparaître les menus des apps à chaque fois que le lecteur lance une interaction. »

    … N’est-ce pas simplement un non-pensé à l’époque de la part d’Adobe ? Et je ne suis pas sûr qu’Adobe (et accessoirement Apple) puissent ne pas se préoccuper d’une telle question !

    À propos de :

    « […] certains font sous-traiter ailleurs et payent très très peu les « usines à EPUB » qui réalisent le boulot manuellement. »

    La tendance, de la part d’éditeurs majeurs, semble prendre depuis peu la direction inverse ! … En tout cas, jusqu’à que « ces » usines soit capables d’intégrer l’approche numérique en amont dans la conception des fichiers print (qui leur sont sous-traités ou non dans l’immédiat).

    ;-)

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.