Penser son livre numérique pour Mobi 7.

L’idée peut paraître atrocement folle, c’est pourtant le meilleur exercice qui soit.

Pensez donc, le support CSS de l’ancien format Kindle est tellement mauvais :

• pas de polices intégrées au fichier ou de police système monospace ;
• pas de marge à droite ;
• pas de prise en compte des tailles en em avec virgule ;
• pas de bordures ou de couleurs de fond ;
• des caractères spéciaux (unicode) quasiment boutés hors du format ;
• un très médiocre support des listes et des tableaux ;
• l’impossibilité de faire flotter (float) des éléments, d’en indiquer les dimensions width et height ou même d’en transformer le texte (text-transform font-variant letter-spacing word-spacing text-shadow etc.) ;
• la conversion qui impose des images à 100 % de la largeur de l’écran ;
• l’impossibilité d’attribuer 2 classes à un même élément.¹

Toutes les conditions requises pour frustrer le designer de livres numériques ; toutes les contraintes nécessaires à la maîtrise de l’espace et du rythme, aussi.

Et c’est sans compter sur les petites astuces à connaître pour obtenir ce que l’on veut, ces astuces découvertes par des designers ou développeurs qui refusaient le statu quo — des hackers en somme — et qui peuvent grandement améliorer la qualité des fichiers produits.

• l’indentation négative devant s’accompagner d’une marge à gauche de 0 pour les vers de poésie ;
• les dimensions de l’image à indiquer en pixels dans le tag <img/> lui-même ;
• des images verticales ne devant pas dépasser un certain nombre de pixels pour éviter de se retrouver avec une page blanche sur l’écran qui suit ;
• les tailles de caractères que l’on peut gérer plus finement avec les valeurs xx-small, x-small, small, medium, large, x-large et xx-large ;
• les marges supérieures et inférieures en pour cent pour mieux gérer l’espacement des titres ;
• l’utilisation de la ligne horizontale hr pour réaliser des bordures — attention, elle a désormais du sens en HTML5.

Si nous ne listons pas toutes les astuces, il nous faut tout de même souligner que les choses ont très souvent été poussées trop loin…

• l’usage d’espaces insécables pour créer des marges et aligner horizontalement certains éléments ;
• des tableaux et morceaux de code en images ;
• des titres aux polices spéciales intégrées en images ;
• des fausses listes réalisées à l’aide de paragraphes débutant par une puce ou un numéro.

Pour le coup, nous pourrions dire que pas mal en sont venus à privilégier la forme (mise en pages) sur le fond (structure sémantique), approche que nous devrions nous interdire à tout prix et que je souhaite décourager en vous proposant cet exercice puisque nous passerions à côté de son objectif premier.

Designer pour Mobi 7 est un excellent moyen d’appliquer la règle 80–20 : puisque nous sommes limités sur la partie CSS, il est absolument nécessaire que les contenus soient correctement structurés.

Mais nous pouvons aller encore un peu plus loin et essayer d’atteindre la feuille de styles la plus simple possible voire même la feuille la plus pure qui soit, celle qui ne contient que le strict nécessaire pour les éléments de base (h[n], p, ul, blockquote, etc.).

Designer pour Mobi 7 est un excellent moyen d’épouser le minimalisme : les contraintes esthétiques et limitations techniques du format nous encouragent à retirer pour atteindre l’essentiel.

Il faut trouver le point d’équilibre sur lequel la mise en pages pourra reposer, c’est-à-dire conserver du sens et faciliter la consultation de l’ouvrage en permettant le scan et la compréhension des différents contenus lors de la lecture.

Je conçois que cela peut paraître difficile, simplifier étant l’un des processus les plus complexes qui soient en matière de design. Mais je vous invite aussi à sérieusement considérer cette approche, elle permettra de produire des fichiers à l’épreuve des pires solutions de lecture² et de systématiser la réflexion de design autour du concept d’amélioration progressive.

Less but better, less is more.³