Prenez le temps de documenter.

C’est un conseil simple, rapide et efficace que vous devez absolument envisager de transformer en habitude pour améliorer votre workflow eBook.

Nous ne pouvons pas nous permettre de buter sur les mêmes problèmes constamment. Il nous faut partir du principe qu’un problème que nous rencontrons une fois est susceptible de se reposer dans quelques semaines ou quelques mois.

Alors quel est selon vous le moyen le plus efficace d’en retrouver la solution ? Repartir d’un très vague souvenir et chercher dans des dizaines de fichiers ? ou consulter une documentation personnelle dans laquelle il suffira de rechercher un mot-clé ?

Si vous ne tenez pas de documentation, peut-être même que vous ne trouverez rien dans votre mémoire et que vous essayerez de refaire le cheminement qui vous a mené à la solution… depuis le champ de recherche de votre moteur préféré. Et vous y perdrez des heures, ce qui risquerait bien de vous faire enrager.

Ou alors vous irez consulter les documentations mises à disposition par les trop rares revendeurs puis chercherez à vous remémorer comment vous avez fait en sorte que le tout fonctionne chez les revendeurs concurrents ?

Se souvenir

Un souvenir, c’est une vague idée que l’on cherche à creuser. Nous essayons de re-contextualiser, nous n’y arrivons pas, cela reste dans un coin de notre tête, nous pensons que toutes les informations nécessaires y sont également restées mais il nous est de plus en plus impossible de tout ré-imbriquer à mesure que les semaines passent.

Nous nous souvenons parce que l’événement nous a plus ou moins marqué. C’est typiquement un hack CSS que nous ne sommes pas amenés à utiliser au quotidien, une petite victoire que nous avons pris bien volontiers le temps de savourer mais pas de documenter.

À l’inverse, l’habitude c’est l’astuce CSS que nous utilisons systématiquement dans notre workflow eBook car nous la concevons comme une « bonne pratique ». C’est quelque chose qui ne procure pas la même joie, que nous ne remarquons pas vraiment mais qui va nous simplifier la vie à partir du moment où nous nous disons « Ah oui, c’est mieux comme ça. »

Certes, le hack n’est pas voué à devenir une habitude mais nous pouvons faire en sorte que nous n’ayons pas à nous en souvenir.

Cinq minutes pour ouvrir un éditeur de texte, décrire le problème et copier/coller la solution. Cinq petites minutes pour documenter là où le hack en lui-même a certainement demandé des heures, ne serait-ce que pour vérifier qu’il ne posait aucun souci dans toutes les solutions de lecture que nous devons prendre en considération.

Ne pas oublier

L’idée, c’est de ne pas oublier le moindre détail, ce petit grain de sable tellement important qui peut bloquer la machine de production dans le pire des cas.

Et puis, il y a aussi tous ces problèmes et bugs que nous découvrons par hasard, qui ne se posent pas forcément avec les fichiers que nous avons fabriqué jusqu’ici mais qui sont en attente d’une solution.

Un jour, qui sait, nous devrons peut-être faire avec. Alors quelqu’un a-t-il trouvé une solution ? Et pourquoi pas la résoudre nous-même si ce n’est pas le cas et que nous avons un peu de temps ?

Ces problèmes, nous pouvons faire en sorte de ne pas les oublier, de ne pas les reprendre en pleine figure le jour où… Et si ça se trouve, une solution à un autre problème pourrait être une base sur laquelle amener quelques légères modifications.

Au pire, nous reverrons ces problèmes assez régulièrement, lorsque nous consultons notre documentation. Et nous pourrions très bien en venir à les contourner inconsciemment grâce à ça, donc ne pas dédier des heures à chercher une solution efficace et pérenne.

Au mieux, toutes nos recherches pourront être utilises aux développeurs de la solution pour laquelle nous reportons un bug — testé et approuvé chez Apple.

Notre code est une base de données

Nous ne nous en rendons pas forcément compte mais tous les petits bouts de code que nous utilisons constituent une base de données. Seulement, ces petits bouts sont suffisamment insignifiants pour que nous ne nous en encombrions pas.

Ce sont des détails de notre quotidien.

Mais si nous travaillons en équipe et qu’un autre membre a besoin de ces détails ?

Et si un remplaçant arrive et qu’il ne connaît pas la méthodologie, parfois très précise, pour exporter un fichier InDesign, QuarkXpress ou Word ? Un document de référence pourrait lui être utile…

Et si nous utilisons des maquettes (ID, CSS, etc.) ? Un guide des styles pourrait également se révéler très pratique : la combinaison « style/classe – résultat » apparaîtra à l’écran et ne laissera aucun doute à celui qui ne sait pas (ou plus) trop bien quoi utiliser dans un cas bien précis.

Au final, ce n’est pas juste du code que nous devons documenter mais aussi des étapes du processus de fabrication. Heureusement, il n’est jamais trop tard pour commencer.

Ça ne prendra pas forcément 21 jours comme le veut ce bon vieux mythe répété à l’envi alors rendez-vous service et commencez dès aujourd’hui.