Utilisateur:Sub/Conseils

Comment je travaille

Pour créer un livre à partir de « rien »

• Je commence systématiquement dans mon espace personnel. Ceci afin que personne ne puisse faire diverger mon travail alors que je ne lui ai pas encore donné de sens. Cela permet de faire de nombreux remaniements (notamment de plan) facilement.
• Commencer par rédiger l'intégralité de l'essentiel. Faire les chapitres superflus dans un second temps.

Pour être productif

• Ne vous lancer pas dans trop de travaux à la fois sinon vous ne ferez rien. Limitez-vous à un, deux voire trois livres à écrire en même temps. Cela ne vous empêche pas d'intervenir ponctuellement sur d'autres livres.
• Si vous butez sur l'écriture d'un passage, imaginez que vous l'expliquez à un ami à l'oral (ton simple).

Ma vision de la pédagogie

La meilleure façon pour moi d'écrire un bon document est de toujours revenir à cette question : « quel livre aurais-je voulu avoir quand j'ai souhaité apprendre ça ? ». Il faut essayer de toujours se mettre à la place de la personne qui veut apprendre sur tel sujet (personne qu'on a été).

Il faut absolument impliquer le lecteur. Pour ça, il faut parler de lui. Exemple : « Ce livre décrit comment faire ceci et comment faire cela » retient moins l'attention du lecteur ; par contre, « Après avoir lu ce livre, vous serez capable de faire ceci et cela ». Il faut que le lecteur sache ce que sa lecture va changer pour lui.

pour les informaticiens...

Il y un problème récurrent dans les documents créés par les développeur d'un logiciel à l'intention des utilisateurs du dit logiciel. Les développeurs ont tendance à voir leur application de leur point de vue, c'est-à-dire selon un découpage technique de l'application et non pas selon un découpage fonctionnel, ce dont l'utilisateur a besoin.

Un exemple pour être plus clair : supposons que le développeur de l'interface graphique d'un logiciel de dessin documente ses travaux. Il va découper le plan comme ceci :

• Le premier menu
• Le second menu
• La première barre de raccourci
• La barre latérale

Il découpe la documentation comme il a découpé le code source. Or, l'utilisateur ne fonctionne pas comme ça, il n'a pas besoin de savoir comment l'application a été découpée, cela doit être transparent à ses yeux. Le plan doit parler des fonctionnalités pour l'utilisateur. Un plan beaucoup mieux :

• Tracer des traits
• Dessiner des formes
• Colorer des éléments

Ce sont les fonctionnalités qui intéressent l'utilisateur d'un logiciel. C'est selon cet aspect que l'utilisation d'un logiciel doit lui être transmise. Ce que veut savoir l'utilisateur pour utiliser le logiciel, ce n'est pas « À quoi servent les boutons du premier menu » mais « Comment tracer un trait ». Il y a une différence de niveau d'abstraction.

Voilà ce qui, à mon humble avis, fait la plupart du temps la différence entre les documentations lues et les autres.

Pour la qualité

N'écrivez que ce que vous savez et pas ce que vous croyez savoir. Notamment, dans l'informatique, il ne faut pas se fier au liste de features des logiciels. Installez vraiment le logiciel et voyez, par vous même, ce qu'il est possible de faire : si ça marche pour de vrai et si c'est si facile que ça.

L'esthétique d'un livre est importante. Personne n'a envie de lire un livre moche. Aussi, n'hésitez pas à passer du temps à faire de jolis encadrés, de beaux schémas et à bien illustrer le tout.

Opinions issues de mon expérience

• La gestion des nouveaux livres telle qu'elle est pratiquée actuellement est un système mis au point à partir de mes constats. Ce système rend Wikilivres mieux pour tout le monde et devrait être préservé.
• Wikilivres n'est pas la poubelle de Wikipédia. Les imports ne devraient pas être décidés unilatéralement là-bas.
• Devenir administrateur ne devrait être qu'une formalité dès qu'on a prouvé sa bonne volonté. Plus il y a d'administrateurs dignes de ce rôle, mieux c'est.
• Ne pas copier de livres extérieurs au projet, sauf s'ils sont abandonnés définitivement ou risquent d'être perdus.
• Pas de documentation sur les logiciels propriétaires. Tout simplement par respect pour leurs auteurs. De toute façon, il faudrait qu'elle intègre des captures d'écran d'un logiciel propriétaire, or, ce seraient des images propriétaires et elles n'auraient pas leur place sur notre projet qui se veut Libre. Cela peut paraître être une opportunité manquée pour notre projet de ne pas proposer de contenus sur ces logiciels, mais les éditeurs ont délibérément choisis de se passer de nos services et sont même prêt à nous poursuivre judiciairement... De toute façon ce n'est pas une grosse perte pour les utilisateurs qui se tourneront peut-être vers des solutions pour lesquelles il est légal d'aider les gens...
• Pas de documentation sur les logiciels libres, les gens du projet en question sont les mieux placés pour le faire (ils le font sûrement déjà) et il ne faut pas diviser les ressources. Exception pour les logiciels dont la documentation n'est pas en français et qu'aucun projet de traduction n'est envisagé quoique qu'un projet de traduction devrait en premier lieu être proposé aux gens du projet. En revanche, on peut tout à fait prendre des logiciels libres comme outils/support pédagogique (L'infographie avec Inkscape, La retouche photo avec GIMP). Les LL doivent êtres des supports d'apprentissage, pas des sujets d'apprentissage.
• Wikilivres n'est pas le centre du monde Libre. Si d'autres livres sont créés par d'autres projets, c'est tant mieux. Il ne faudrait pas être contre-productif en forkant (c.-à-d. en copiant bêtement le livre ici, cela va diviser les contributeurs qui ne sauront plus quelle version mettre à jour).

En somme :

• Il faut éviter les forks à tout prix, aussi bien internes qu'entre Wikilivres et le reste du monde.
• D'autres endroits sont mieux que Wikilivres pour créer des contenus, c'est tant mieux, la diversité est une force.