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.