Je sais que l’idée est audacieuse mais j’aurais bien envie d’appliquer la règle « 80–20 » à la fabrication de livres numériques.

Cette règle, Apple en a fait un cheval de bataille par exemple, conseillant aux développeurs d’apps de la suivre autant que faire se peut. Aussi, l’entreprise la présente comme un principe fondamental pour établir une stratégie de design : 80 % des utilisateurs se contentent de quelques fonctionnalités et les 20 % restants utiliseront les autres, classez les fonctionnalités de votre app dans ces deux catégories et tout se passera pour le mieux.

Dire que tout a commencé avec Pareto, qui fut repris par l’administration états-unienne dans les années 60 et qui est aujourd’hui relayé par des géants de la Silicon Valley. Donc, si le principe sert le commerce et le design, pourquoi ne pourrait-il pas servir la fabrication de livres numériques ?

Adaptons la règle à nos besoins :

• 80 % du temps pour structurer (HTML) ;
• 20 % du temps pour styler (CSS).

Aujourd’hui, les pourcentages sont inversés. La situation doit changer.

Si l’on y regardait bien, ne nous rendrions pas compte que la majorité du déboguage des fichiers se fait sur la partie CSS, parce que ça ne passe pas comme nous le voudrions et que nous sommes incapables de l’accepter ? Que se passerait-il si nous appliquions cette règle ?

Naturellement, ces pourcentages ne sont pas absolus. Ils définissent simplement un idéal que nous souhaiterions viser.

Et, bien sûr, pour certains livres, nous serions plus proches du « 50–50 ». Mais ce sont là des exceptions, ces livres ne constituent pas notre pain quotidien.

Je ne m’en suis pas rendu compte mais je respecte cette règle inconsciemment. Elle est juste l’expression d’une prise de conscience : je passe déjà (à peu près) 80 % du temps de fabrication sur les fichiers XHTML.

Vous pensez que je suis un peu barré ? Alors prenez en compte ces 3 points (parmi d’autres) :

• les réglages utilisateurs, qui incluent la désactivation de l’intégralité de la feuille de styles éditeur ;
• les apps de lecture qui ne supportent même pas CSS ;
• l’accessibilité.

Alors, vous voyez pourquoi j’en viens à privilégier à ce point la structure sur les styles ?

Allez-y, faites vous-même le test : structurez votre fichier EPUB, regardez combien de temps cela vous a demandé, divisez par 4 et ne consacrez pas une seule seconde de plus à styler. Je suis sûr que vous arriverez à faire quelque chose de bien dans le temps imparti.

Au mieux, cela vous invitera même à regarder du côté des pré-processeurs CSS. Plus besoin de calculer les em, les marges et interlignes ; plus besoin de partir d’une feuille blanche ou de reprendre une CSS abominable exportée par un logiciel ; une feuille de styles générée en quelques secondes, en fonction des besoins. Mais pour ça, il faudra une structure et pas un amoncellement de classes.

J’insiste sur ce point : CSS peut nous demander énormément de temps, beaucoup trop de temps si nous commençons à nous entêter pour obtenir, au pixel près, ce que nous visualisons dans notre esprit.

Chaque ligne de CSS que vous écrivez est une suggestion. Vous ne dictez pas comment le contenu HTML doit être rendu, vous ne faites que le suggérer au navigateur. — Jeremy Keith

Et si (nous) nous simplifions (la vie) plutôt que de vouloir à tout prix ? Et si nous nous montrions créatifs plutôt que de vouloir reproduire bêtement ? Et si nous développions des méthodes de design réellement adaptées au numérique ?

J’en viens à penser qu’il en est de même avec les styles de paragraphe et de caractère des traitements de texte et solutions PAO. Nous passons énormément de temps à styler. Trop, très souvent. Beaucoup en viennent à oublier l’existence-même des styles tellement ils sont obnubilés par ce qu’ils voient à l’écran.

Appliquons cette même règle, utilisons « titre de section », « titre de sous-section », « citation », etc. pour ce qu’ils signifient, pas pour ce à quoi ils ressemblent. Modifions leur esthétique ensuite, dans un second temps.

Un peu comme un one-two punch.

Ce que nous voyons peut être trompeur donc nous induire en erreur. Si nous faisons l’effort de nous concentrer sur l’essence d’un style, nous pourrons l’utiliser à bon escient et prendre de meilleures décisions.

Tout est question d’architecture : nous construisons les fondations quand nous structurons, nous les rendons plus solides en respectant les règles et en utilisant les bons matériaux. Seulement ensuite devons-nous entreprendre les autres travaux, une fois que la structure est posée.

Une structure mal pensée est tout peut avoir des conséquences désastreuses en numérique.

D’abord les titres qui s’écroulent au milieu des paragraphes, ensuite les italiques qui s’envolent au premier coup de vent.

Ce qui reste dans tous les cas, la base qui subsiste malgré tout, c’est la structure sémantique que l’on trouvera dans les fichiers XHTML. Et il faut concevoir et accepter qu’une mauvaise structure prête à conséquence. Il y a même une chance que vous vous rendiez compte que quand tout est bien structuré, la mise en pages — et non plus seulement les styles — découle d’elle-même…