Le public ciblé et les prérequis des livres techniques

Quand nous achetons un livre technique, nous aimerions ne pas nous tromper sur le public visé et sur les prérequis nécessaires à la bonne compréhension du livre.

Il me paraît indispensable que les éditeurs de livres techniques, à travers leurs très nombreuses collections, indiquent systématiquement quel est le public visé. En fonction du niveau de compétence de chacun, nous voulons que le livre soit bien ciblé à nos besoins. Une personne très qualifiée ne sera pas intéressée par un livre expliquant les bases d'un logiciel et un débutant sera perdu par des précisions techniques très pointues pour des personnes ayant dix ans d'expertise. Si dès la quatrième de couverture, l'éditeur précise le public visé, c'est un plus indéniable et appréciable. Bien sûr vous allez me répondre que le libellé peut parfois prêter à confusion : qu'est-ce qu'un expert ? Qu'est-ce qu'une personne confirmée ? Qu'est-ce précisément une personne maîtrisant telle ou telle technologie ? Certes, mais en ayant l'indication du public visé et en parcourant rapidement les pages du livre, nous pouvons nous faire très rapidement une opinion : ce livre est-il fait ou non pour moi, selon mes compétences.

De la même manière, connaître les prérequis est aussi une information indispensable à connaître avant d'acheter un livre technique. Supposons que j'achète un livre sur Photoshop pour faire de la retouche de photos. Dois-je avant cela être capable de maîtriser la prise de vue ? Va-t-on aborder dans ce livre la notion de balance des blancs ? La notion de sensibilité ISO des vues ? Dois-je déjà connaître les bases de Photoshop et de son interface ? Supposons que je veuille acheter un livre sur le design web avec les CSS (Cascading Style Sheets), dois-je connaître le HTML ? Dois-je avoir déjà créé un site web ? Là encore, avoir ces informations en quatrième de couverture est indispensable pour le choix d'un livre technique.

A tous les éditeurs de livres techniques : s'il vous plait, indiquez ces informations pour guider au mieux vos lecteurs, vos acheteurs.

Livre Bien rédiger pour le web - Points d'amélioration

Tout d'abord merci à Isabelle de son commentaire constructif. Je ne réponds que maintenant, avec du retard (je suis en phase finale de rédaction d'un livre...). Voilà quelques remarques concernant le code HTML/CSS :

Les noms des éléments HTML :

L'auteur parle systématiquement de balises au lieu d'éléments HTML. Rappelons qu'un élément HTML est composé d'une balise d'ouverture, d'un contenu et d'une balise de fermeture.
Le libellé des éléments HTML et des attributs est écrit avec des majuscules. C'est une syntaxe obsolète : privilégions uniquement des minuscules.

Confusion sur l'attribut alt, page 99.

Le texte qui apparaît au survol d'une image (ou d'un autre élément HTML) est l'attribut title et non l'attribut alt. L'attribut alt est une alternative textuelle à l'image. La valeur de l'attribut alt apparaît quand l'image n'est pas encore chargée, ou bien quand l'image n'est pas chargée. Ce texte peut aussi apparaître si l'internaute a demandé à ne pas afficher les images (pour gagner du temps au chargement). C'est bien la valeur de l'attribut title qui est affiché au survol de la souris. Cette confusion provient souvent d'une mauvaise interprétation de Microsoft Internet Explorer.

Accessibilité et typographie, page 111

La police de caractère Arial, comme le Tahoma ne sont pas des polices faites pour la lecture à l'écran. Ce sont des polices qui ont été créées pour l'impression. Il est préférable de recommander la police Verdaana qui a été créée par le typographe américain Matthew Carter, pour une bonne lisibilité à l'écran.
Pour mettre en gras,simple mise en forme visuelle, nous pouvons utiliser l'élément HTML ‹b›. Mais pour une synthèse vocale, il n'y a pas de différence. C'est pour cela qu'il faut utiliser l'emphase forte : ‹strong› qui permet une différence vocale du synthétiseur. Il en est de même avec l'italique ‹i› et l'emphase ‹em›.
Plus gênant, le paragraphe sur la taille des caractères. Si le concepteur utilise une taille de caractère fixe : en point (comme c'est indiqué dans le livre, page 112) ou en mm, cm... la personne handicapée ne pourra pas agrandir le texte proportionnellement. Il faut impérativement utiliser des unités relatives : le pourcentage (%) ou le cadratin (em). Sachez que par défaut les navigateurs utilisent valeur relative 1 em (ou 100%) = 16 points.
L'auteur revient sur ce sujet page 174 en indiquant bien l'utilisation préférable de la police Verdana. Page 175, l'auteur indique bien d'utiliser des tailles relatives.

Abréviations et Acronymes, page 139

Précisons que deux éléments HTML sont prévus pour gérer les abréviations et les acronymes : ‹abbr› et ‹acronym›.

Les ancres - Page 151

Attention, la valeur de l'attribut name de l'élément a, doit respecter des règles d'écriture. Il doit contenir des lettres, des chiffres, des tirets et des tirets bas (underscore). Mais pas d'espace, ni de caractères accentués, ni l'apostrophe, comme le montre l'exemple. Il eut été plus judicieux de mettre un exemple de type : ‹a name="titre"›‹/a›.

Mise en forme du texte, page 180, 181 et 184

L'élément HTML pour mettre en exposant est effectivement ‹sup›. J'ajoute que l'élément HTML pour mettre en indice est ‹sub›. Pour les chimistes cela est indispensable.
Pour les abréviations et les acronymes, je réitère mas remarques précédentes (pour la page 139).
Pour les petites capitales, l'auteur montre un exemple avec une syntaxe totalement obsolète aujourd'hui : l'utilisation de l'élément ‹span›. Utilisez les feuilles de styles.
Enfin, pour écrire en petites capitales, l'auteur indique une syntaxe CSS de type "en ligne". C’est-à-dire que le code CSS est inséré directement dans l'élément HTML. Pas pratique du tout car l'auteur ne peut pas réutiliser cette mise en forme. Il faut créer un sélecteur de classe pour créer la règle et l'appliquer rapidement autant de fois qu'il est nécessaire.

Voilà, rapidement, quelques remarques constructives. Si je vois d'autres éléments importants, je vous en ferai part.

Livre Bien rédiger pour le web

Synthèse de lecture sur Bien rédiger pour le web... et améliorer son référencement naturel
Je suis en train de terminer la lecture de l'ouvrage d'Isabelle Canivet. Mon avis reste sur une impression mitigée.
L'ouvrage se lit très bien, le style est clair et les exemples très parlants. Pas de problème.
Là où je suis un peu déçu, c'est sur l'épaisseur du livre : il y a parfois (souvent ?) des redites, même à quelques pages d'intervalles. L'ouvrage aura largement gagné à être plus synthétique, plus court. Nous aurions eu alors une lecture plus dynamique en allant directement à l'essentiel (conseil pourtant répété 45 fois dans le livre).
Deuxième petit souci, des approximations dès lors que l'auteur parle technique et code HTML / CSS. Clairement ce n'est pas son domaine de prédilection.
Mais cela reste un livre largement recommandable. A lire donc.
PS : me reste la partie référencement à lire, pour un autre billet.

Une lecture et des vacances...

Voici une de mes lectures pour cet été : Bien rédiger pour le web ...et améliorer son référencement naturel d'Isabelle Canivet, paru aux Editions Eyrolles. Le site web étant déjà très bien fait (www.action-redaction.com), je pense que nous avons là une lecture prometteuse.



Et ce blog va prendre aussi des vacances, je vous retrouve à la rentrée.

Interview de Corinne Hervo, responsable de collection aux Editions ENI - 2e partie

Avez-vous un travail de relecture aussi important pour le rédactionnel que pour l'aspect technique des livres ?
La relecture technique est fondamentale : tous les relecteurs sont des professionnels de l’informatique (en majorité formateurs ou auteurs) et sont en mesure d’effectuer une relecture critique tant d’un point de vue compréhension technique que pédagogique (savoir analyser la structure du livre pour en comprendre le fondement pédagogique, par ex).

Est-ce la même personne qui s'occupe de la relecture technique et de la relecture rédactionnelle ?
En règle générale, oui, sauf pour certains livres très techniques pour lesquels la double compétence est plus difficile à trouver.

Donnez-vous des conseils rédactionnels aux auteurs ?
Oui, notre rôle est de suivre et de soutenir l’auteur (surtout s’il est novice) : nous recherchons avant tout la compétence professionnelle et nous mettons notre expérience d’éditeur à la disposition de l’auteur pour l’aider dans cette merveilleuse aventure que peut être l’écriture d’un livre ; c’est un travail d’équipe et cela rassure beaucoup certains de nos nouveaux auteurs.

Les auteurs acceptent-ils facilement les corrections proposées ?
Oui, en règle générale, ils apprécient beaucoup ce regard critique sur leur livre qui leur permet encore de l’améliorer ; c’est aussi le rôle du Responsable de collection de régler les (légères) dissensions qui peuvent survenir parfois entre auteur et relecteur.


Merci d'avoir répondu à mes questions.

Interview de Corinne Hervo, responsable de collection aux Editions ENI

Voici la première partie d'une interview de Corinne Hervo, responsable de collection aux Editions ENI.



Comment s'organise la notion de collection aux Editions ENI ?
Plusieurs critères entrent en ligne de compte mais globalement, on peut simplifier en disant que chaque collection correspond à un public visé ; ce public peut être défini par son niveau en informatique (débutant, utilisateur, informaticien, expert…), par un centre d’intérêt (graphisme, bureautique, certifications…) ou par la méthode d’apprentissage recherchée (aide-mémoire, autoformation pas à pas, TP…). Ces 3 orientations se cumulent les unes aux autres et expliquent que nous proposons aujourd’hui plus de 20 collections, un même sujet étant décliné dans plusieurs collections : par ex, la sortie de Windows Seven peut générer jusqu’à une dizaine de livres : pour le débutant, pour l’utilisateur bureautique qui veut découvrir les fonctionnalités de façon détaillée ou au contraire condensée, pour celui qui veut apprendre par la pratique, pour l’informaticien qui devra installer les postes Seven, pour l’expert et pour celui qui est intéressé par la Certification Microsoft.

Quel est votre rôle en tant que responsable de collection ?
Le Responsable de collection définit la ligne éditoriale de la collection (comment la connaissance est-elle diffusée, à quel niveau) ce qui se traduit par des règles précises au niveau de la rédaction (choix des termes) et de la mise en page (utilisation de titre et sous-titres à l’infinitif, par ex, découpage de chaque manipulation par étape…) ; son rôle consiste à expliquer cette ligne éditoriale aux auteurs et à s’assurer qu’elle est respectée.

Est-ce que chaque collection possède son propre type d'écriture ?
Oui, c’est ce qu’on appelle « le moule », le style d’écriture est lié aussi aux principaux formats de paragraphes et donc à la mise en page. De nombreuses similitudes existent cependant entre les livres de même type (livre de référence, par ex) appartenant à des collections différentes.

Les différents types d'ouvrages : les références

Dans les divers ouvrages techniques, informatiques qui nous sont proposés, nous avons à notre disposition plusieurs types de livres.

Les livres de références sont les plus classiques.

Ces ouvrages proposent une alternative au manuel "officiel" du logiciel, quand il existe. Ces manuels "officiels" ont parfois deux défauts. Une traduction de l'anglais (ou de l'américain) vers le français qui laisse à désirer : nous avons des phrases mal construites, des mots mal utilisés, des néologismes, des anglicismes...

Dans ce cas un livre de référence écrit par un professionnel apporte énormément au lecteur, à l'utilisateur du logiciel : l'écrit est clair, précis et bien rédigé (c'est du moins ce que nous devons pouvoir espérer !).

Deuxième défaut, c'est tout simplement l'absence de version papier du manuel d'utilisation. Actuellement la plupart des éditeurs informatiques privilégient les versions électroniques en ligne des manuels d'utilisation des logiciels. L'argument premier est la réactivité de mise à jour du manuel. Ce qui est vrai. Mais avoir un manuel "papier" donne un certain confort à l'utilisateur. Enfin, la traduction peu là aussi laisser à désirer.

Enfin, l'auteur peut (doit ?) aussi apporter en plus du manuel "officiel", son expérience d'utilisateur : qu'est-ce qui d'usage courant, quelles sont les fonctionnalités secondaires, voire obsolètes que l'utilisateur peut ne pas utiliser sans conséquence, comment il a résolu tel ou tel problème avec telle ou telle fonctionnalité du logiciel étudié. L'auteur peut aussi apporter des précisions techniques sur des concepts plus généraux qui ne sont pas directement liés au logiciel. Par exemple des précisions techniques sur les formats de fichiers utiles dans les médias web ou print, dans l'utilisation de logiciels graphiques de création de sites web ou de mise en page. L'auteur peut aussi apporter des précisions concernant l'utilisation du logiciel étudié avec d'autres produits, d'autres logiciels de même catégorie. Pourquoi se contenter d'évoquer l'utilisation unique d'un Adobe InDesign, alors que ce logiciel est fait pour travailler avec Adobe Illustrator et Adobe Photoshop.

L'auteur ne doit pas se contenter d'un simple "listing" des fonctionnalités du logiciel : il doit apporter un plus, son expérience de praticien.

Écrire l'introduction en dernier

Voilà un fait qui peut vous paraître étonnant ! Mais oui, personnellement j'écris l'introduction toujours à la fin de la rédaction.

L'introduction dans un livre joue le même rôle que le chapô en presse : c'est lui qui va donner l'envie de lire le livre, de lire l'article en presse
C'est donc quand j'ai terminé de rédiger le livre que j'ai enfin une bonne vision globale de ce qu'il va apporter au lecteur. Je peux comprendre dans son ensemble ce que va acquérir le lecteur. À la fin de la rédaction, je sais ce que j'ai écrit, comment je l'ai écrit, ce que va gagner le lecteur en lisant l'ouvrage. À ce moment-là je peux écrire une introduction qui va inciter le lecteur à acheter le livre.
Si vous écrivez l'introduction dès le début de la rédaction, vous n'avez pas encore l'orientation rédactionnelle précise du livre, vous n'avez pas encore le "fil rouge". Vous ne savez pas encore comment vous allez amener le lecteur là où vous souhaitez aller.

Donc comme en presse pour le chapô, essayez de rédiger vos introductions en dernier.

Un verbe d'action dans les titres

Un chapitre d'un livre est structuré en paragraphes. Chaque paragraphe est annoncé par un titre. Nous allons maintenant évoquer contenu des titres. Nous avons déjà évoqué l'importance des titres et leurs différents types dans un article précédent.

Il me semble très intéressant de placer un verbe d'action dans les titres. Cela va permettre de donner du dynamisme au titre. L'objectif étant de donner au lecteur l'envie de lire le paragraphe. Il faut donc éviter une forme passive, voire ennuyeuse. Nous devons indiquer ce qui va se passer dans le texte qui va suivre en plaçant un verbe d'action.

Par exemple évitons d'écrire : "Le paramétrage du nouveau document", mais plutôt "Paramétrer le nouveau document".
Utiliser un verbe d'action à l'infinitif implique beaucoup plus le lecteur, il se sent forcément concerné, il va devoir agir, réaliser une action. Personne d'autre que lui va devoir passer à l'action.
De plus, commencer tout de suite par le verbe, permet d'entrer immédiatement dans le vif du sujet, au cœur de l'action, vous interpellez sur-le-champ le lecteur.

Faire des phrases simples et courtes

L'écriture dans un livre informatique pédagogique doit être réalisée avec des phrases courtes et simples. Cela rejoint l'écriture pour le web. Plus les phrases sont longues alambiquées, plus l'utilisateur sera gêné et il devra alors relire une fois, deux fois la phrase avant de la comprendre. Tout cela nuit à la compréhension rapide d'un texte.

Voilà un exemple d'une phrase un peu trop complexe à mon goût, extraite d'un livre sur l'utilisation du logiciel Adobe Dreamweaver. C'est une explication sur la façon d'annuler l'application d'un style CSS :
"Pour annuler l'application d'un style, sélectionnez l'élément qui utilise ce style puis choisissez Format - Styles CSS - Aucun ou dans le menu déroulant Règle cible (ou Classe) du panneau Propriétés, cliquez sur Supprimer la classe ou dans le menu déroulant Classe cliquez sur Aucune".
Ouf ! Maintenant vous pouvez respirer !

Alors analysons cette phrase.

- Cette phrase comporte 46 mots ! C'est beaucoup trop. Pour moi, il faut compter 20-25 mots par phrase.

- La phrase contient trois fois le mot ou. C'est un indicateur très précis d'une phrase trop longue. A partir du moment où vous utilisez plusieurs fois le mot "ou", cela doit être un indicateur pour vous dire "Ma phrase est trop longue. Est-ce que je peux en faire plusieurs à chaque utilisation du mot ou". J'ajoute que l'utilisation du mot "puis", dans ce contexte, donne le même effet que le mot "ou".

- Le rédacteur écrit : "Règle cible (ou Classe)". Là c'est une erreur pédagogique. De quoi parle-t-on ? D'une Règle cible ou d'une Classe ? Cela ne peut pas être les deux en même temps. Si c'est l'un ou l'autre, il faut alors en expliquer le contexte d'utilisation : quand devons-nous utiliser une Règle cible ou une Classe ? A la lecture de cette phrase l'utilisateur est incapable de savoir quand il doit passer par Règle cible ou Classe.

- Puis nous lisons ensuite que cela ce passe dans le panneau Propriétés. Il eut fallut le dire avant ! Il faut toujours situer l'environnement d'utilisation avant de parler d'un élément d'interface de cet environnement (voir l'article Le chemin d'accès aux éléments d'interface).

Voilà ce que je propose comme correction :
"Pour annuler l'application d'un style, sélectionnez l'élément qui utilise ce style. Dans le panneau Propriétés, avec le bouton CSS actif, dans la liste déroulante Règle cible, choisissez Supprimer la classe. Toujours dans le panneau Propriétés, avec le bouton HTML actif, dans la liste déroulante Classe, choisissez Aucune."
J'ai ainsi trois phrases de 14, 19 et 17 mots.
Je n'ai pas utilisé les mots "ou" et "puis".
J'ai bien indiqué d'abord l'environnement dans le quel le lecteur va trouver les éléments décrits : le panneau Propriétés et après les éléments d'interface de ce panneau.
J'ai bien indiqué le contexte d'utilisation des deux possibilités pour annuler le style : avec le bouton CSS ou avec le bouton HTML actif.

Rappel à une fonction, une option

Dans une page constituée de plusieurs paragraphes, le rédacteur peut évoquer plusieurs fois une fonction, une commande, une option donnée.

A la première évocation de cette fonction, il faut clairement la décrire et correctement la nommer, avec le même nom que dans l'application, le logiciel étudié.

Quand nous devons de nouveau évoquer cette fonction, il faut impérativement la nommer de la même façon que la première fois. Il ne faut surtout pas mettre en difficulté le lecteur en changeant son nom.

De plus, nous ne devons pas l'évoquer en utilisant un mot "passe-partout" dénué de sens, type : "cette option", "cette fonction" ou "cette commande". Le lecteur ne pourra pas facilement faire le lien entre ces mots "passe-partout" et le nom de la fonction que nous souhaitons évoquer de nouveau.

Il faut toujours faire appel à une fonction en l'évoquant par son nom utilisé dans l'application.

Même mot pour la même action

A la rédaction d'un livre, il faut bien faire attention à toujours utiliser le même mot pour la même action.

Je vais prendre un exemple bien concret que j'ai déjà vu dans un (des) livre(s) : le mot choisi pour désigner l'action d'utilisation d'un item d'un menu. Dans le même ouvrage, j'ai noté tous ces mots :

• choisir,
• cliquer,
• sélectionner,
• pointer,
• activer.

Soit cinq mots différents pour la même action ! Cela nuit à compréhension de ce qu'il y a à faire. Pourquoi utiliser cinq mots différents pour la même action ? Quelle est la justification de ce manque flagrant d'homogénéité ? Le lecteur débutant peut facilement se perdre.

Donc soyons clairs : utilisez le même mot pour la même action. Vous gagnerez en simplicité et en compréhension pour vos lecteurs.

Le manque de cohérence de l'interface des logiciels (3)

Un dernier billet (?) sur Adobe Dreamweaver et son manque de cohérence dans son interface

Ces billets ne sont pas une attaque en règle contre ce logiciel (que j'utilise professionnellement et sur lequel j'ai écrit plusieurs ouvrages), mais ils sont faits pour mettre en exergue la problématique du rédacteur face à des situations pas toujours simples à résoudre : comment faire passer simplement le message aux lecteurs-utilisateurs que pour une même fonction plusieurs libellés peuvent être utilisés ?

Prenons pour nouvel exemple les formulaires qui permettent de saisir des informations et de faire divers choix. Pour insérer un élément de choix (champ de texte, bouton radio, liste...) Dreamweaver utilise des identifiants (attribut id en code HTML). Dans la boîte de dialogue qui apparaît quand nous insérons un élément de formulaire, le champ de saisie ID a deux usages !
Quand il s'agit d'un Champ de texte, d'une Liste, d'un Menu... la saisie indiquée dans le champ ID sert bien à identifier de manière unique l'élément inséré. Par contre quand il s'agit d'un bouton radio la saisie du champ ID sert aussi à indiquer la valeur à envoyer au script serveur qui gère les données du formulaire.
Le problème est bien là : un champ de saisie pour deux usages différents que rien ne différencie dans la boîte de dialogue. Ce n'est pas si simple à expliquer et à utiliser pour le débutant.

Deuxième exemple : une des techniques de mise en page des pages web utilise des "boîtes en position absolue" (boîte

en HTML). Avec Dreamweaver, cette technique s'appelle "les éléments en position absolue", les éléments PA. C'est par ce libellé, Elément PA, dans le menu et dans le panneau Insertion que nous pouvons y accéder. Mais, pour paramétrer cet élément PA, dans le panneau Propriétés, cela s'apelle Elément CSS-P.

Toujours le même problème...

Toujours faire appel à des fonctionnalités connues

Dans un livre, nous devons toujours faire appel à des fonctionnalités déjà étudiées, déjà connues.

Nous ne devons pas faire appel, ou parler d'une fonction que le lecteur verra plus tard : dans un paragraphe ou un chapitre suivant par exemple. Il n'est pas rare de lire une phrase contenant une fonctionnalité, un menu, une fenêtre, une technique que le lecteur connaîtra plus tard en lisant la suite de l'ouvrage.

Par exemple, j'ai déjà lu ce genre de phrase : "Dans cette fenêtre, vous pouvez aussi ouvrir un modèle : cliquez sur l'option Modèle". Et de me dire : "Qu'est ce qu'un modèle ?". Pas un mot, pas une référence à la notion de modèle avant d'avoir lu cette phrase ! Et même immédiatement après, pas d'explication. Comment le lecteur peut savoir à l'avance ce qu'est un modèle ? S'il faut qu'il lise dix paragraphes ou qu'il atteigne le chapitre suivant avant de d'aborder cette notion, c'est perdu. Il faudra alors qu'il revienne x pages en arrière pour retrouver la première référence à cette notion de modèle. Ce n'est pas pédagogique.

Le minimum que l'auteur puisse faire, c'est écrire explicitement que cette notion sera vue à telle page dans tel chapitre. Mais personnellement je pense que cela n'est jamais judicieux d'imposer des allers et des retours dans un livre.

C'est bien à l'auteur d'écrire sur des fonctionnalités vues et connues du lecteur. A l'auteur de structurer son ouvrage pour éviter ce type de maladresse rédactionnelle.

L'ordre dans le couple fonctionnalité vs accès

Une petite réflexion me vient : dans quel ordre est-il plus judicieux d'indiquer l'objectif et l'accès d'une fonctionnalité ?

Un exemple simple : dans le logiciel de mise en page Adobe InDesign, nous pouvons réaliser des tables des matières. Cette fonction est accessible dans le menu Texte.
Que devons-nous dire :
- C'est dans le menu Texte que vous pouvez créer une table des matières,
- Pour créer une table des matières, allez dans le menu Texte.

Dans la première solution, je donne l'importance à l'accès, puisque je l'indique en premier. Inversement dans la deuxième solution, je donne l'importance à la fonctionnalité.

Qu'en pensez-vous ? Que devons nous privilégier ? La fonctionnalité ou l'accès ? Pouvons nous même s'imposer une règle à respecter dans tout l'ouvrage ? Est-ce que cela peut largement varier tout au long du livre, pour éviter d'avoir un rédactionnel trop rigide ?

Le manque de cohérence de l'interface des logiciels (2)

Toujours sur le même sujet et toujours avec le logiciel Adobe Dreamweaver, une autre incohérence sur les libellés des fonctionnalités.

Cette fois, il s'agit des feuilles de style en cascade (CSS). Pour lier une feuille de style CSS à une page (X)HTML, nous pouvons le faire par quatre accès différents :
- par le menu : Attacher feuille de style,
- par un bouton : Attacher une feuille de style,
- par une barre de propriétés : Joindre la feuille de style,
- et en créant un nouveau document : Lier le fichier CSS.

Quatre façons de procéder, quatre libellés différents, pour la même fonctionnalité !

Et quand la fenêtre de dialogue apparaît, son titre est : Ajouter une feuille de style externe. Encore un libellé différent.

Comment voulez-vous que le débutant s'y retrouve si pour la même fonctionnalité, l'interface lui indique des libellés à chaque fois différents ?

Le chemin d'accès aux éléments d'interface

Dans un livre ou un tutoriel, il est très important de donner le chemin d'accès aux éléments d'interface dans l'ordre chronologique d'utilisation.

Si je dois indiquer l'utilisation de telle ou telle commande d'un menu, je commence par indiquer le nom du menu et pas l'inverse. Exemple : "Allez dans le menu Fichier et choisissez Enregistrer". Simple et logique dans l'ordre d'exécution.
Pas contre, si je dis "Utiliser la commande Enregistrer que vous trouverez dans le menu Fichier", l'utilisateur est obliger de lire complètement la phrase avant de pouvoir réaliser la consigne. L'utilisateur devra prendre la consigne à l'envers, il sera obligé de revenir au début de la phrase pour savoir où doit d'abord aller.
Dans Adobe Photoshop, autre exemple respectant le chemin d'accès : "Dans le menu Image, choisissez Taille de l'image. Dans la fenêtre Taille de l'image, dans la zone Dimension de pixel, dans le champ Largeur, saisissez la valeur souhaitée". J'indique bien d'abord le menu, puis la commande de ce menu, le nom de la fenêtre qui est affichée, le nom d'une zone précise dans cette fenêtre et le nom du champ où doit se faire une saisie.
Et pas : "Saisissez la valeur souhaitée dans le champ Largeur, pour y accéder, utilisez la commande Taille de l'image dans le menu Image."

Nous devons systématiquement indiquer l'ordre logique d'exécution dans une phrase la plus simple possible, en supprimant tous les mots inutiles à la compréhension de la phrase. De plus, chaque élément d'interface doit être parfaitement nommé (sujet d'un futur article).

Le manque de cohérence de l'interface des logiciels

Les libellés des logiciels sont parfois étonnants, pour parler "gentiment". Je prendrais comme premier exemple le logiciel de conception de site web Adobe Dreamweaver (anciennement Macromedia).

Quand vous insérez un tableau, vous pouvez sélectionner deux cellules pour en faire qu'une seule. C'est une fonctionnalité très classique. Là où je "râle", c'est l'incohérence des libellés des commandes pour accéder à cette fonctionnalité.
En passant par le menu, la commande est libellée : "Fusionner les cellules". Le libellé est court, simple et parfaitement compréhensible. En choisissant le bouton de raccourci correspondant, l'info-bulle qui apparaît au survol de la souris est : "Combiner la sélection rectangulaire des cellules".
Première remarque : pourquoi utiliser deux libellés différents, là où un seul suffit ? Le premier libellé est très clair !
Deuxième remarque : pourquoi utiliser des verbes d'action différents ? Fusionner ou Combiner ? Nous pouvons discuter pendant longtemps sur le sens de ces deux verbes, mais pourquoi deux choix ?
Enfin, pour le deuxième libellé l'utilisation de "sélection rectangulaire" est franchement difficilement compréhensible ! Comment une sélection dans un tableau peut être autrement que rectangulaire ? Qu'est-ce que le mot rectangulaire apporte de plus ? Rien !

Tout cela complexifie inutilement l'interface utilisateur, surtout pour les novices.

Comment s'adresser au lecteur

Dans un ouvrage papier ou dans un tutoriel web, comment s'adresser au lecteur ?

Ne pas utiliser le on
Premier élément de réflexion : le "on" est à proscrire ! Pourquoi ? Parce que le "on" est tout ce qu'il y a de plus impersonnel ! C'est qui "on" ? Vous connaissez "on" ? A titre de provocation, l'adage bien connu "On est un con" est à retenir.
Il faut impérativement ouvrir le dialogue avec le lecteur et ce n'est pas en s'adressant à lui avec "on" que nous allons y arriver !

Tiens, cela fait deux fois que je m'adresse directement à vous : j'ai d'abord utilisé vous, puis ensuite nous et je viens de dire je.

Utiliser le vous
Première possibilité : utilisez le "vous". Là je m'adresse directement à mon lecteur, je l'interpelle : "Hé vous, je vous parle ! Vous et moi communiquons, partageons ." Avec le "vous", j'en appelle à la réflexion de mon lecteur. Mais surtout, je rends acteur le lecteur : il doit agir. Le lecteur n'est plus passif.

Utiliser le nous
Deuxième possibilité : utilisez le "nous". Dans ce cas je l'adresse au lecteur et en même temps à moi-même. Je me fais "complice" du lecteur. Je l'interpelle pour que nous fassions un travail commun, pour que nous analysions ensemble un problème. Je me fais solidaire de mon lecteur.

Utiliser le je
Dans ce dernier cas, c'est bien moi qui m'adresse au lecteur, c'est moi qui parle. Je veux faire passer au lecteur un message : pourquoi j'ai fait cela, pourquoi je dis cela... Je m'expose, je m'engage.

En guise de petite conclusion, les trois possibilités sont toutes à utiliser à bon escient. Il ne faut pas prendre qu'une seule locution, ce qui limiterait les formes d'écriture et d'expression. Il faut pouvoir varier et s'adresser au lecteur de différentes manières. C'est à la rédaction qu'il faut bien veiller à utiliser le bon pronom personnel, celui qui convient le mieux au contexte en cours de rédaction.

L'importance des titres dans les chapitres

Nous savons l'importance des titres pour les articles publiés sur Internet. Les lecteurs lisent d'abord les titres et seulement ensuite lisent le texte s'ils jugent le titre pertinent. Nous pouvons nous poser la question pour les ouvrages papiers. Les titres ne sont-ils pas aussi importants ?

Les fonctions d'un titre
- le titre doit structurer le chapitre,
- le titre doit indiquer ce qui va suivre,
- le titre doit donner envie de lire la suite.

Les titres structurants
Les titres sont faits pour structurer les chapitres d'un livre ou d'un tutoriel. Il faut donc que les titres découpent le chapitre de manière logique et pédagogique. La succession des titres doit refléter la démarche engagée dans le chapitre : d'où nous partons et où nous voulons aller, comment emmener le lecteur là où il doit arriver.

Les titres informatifs
De ce fait le libellé des titres doit impérativement donner l'aperçu de la structure du chapitre. Il ne faut pas écrire alors des libellés passe-partout, genre "Les principes", "La création", "Ajouter l'élément".
Le lecteur va se dire : Les principes de quoi ? La création de quoi ? Le titre doit se suffire à lui-même, il doit être informatif : il doit expliquer par ses propres mots ce qui va suivre. Rien qu'à lire les titres, le lecteur doit avoir un aperçu très clair de ce qu'il va lire et apprendre.

Les titres informatifs
Le titre doit être aussi incitatif : il doit donner envie de lire la suite du texte. Si dès le titre vous indiquez des mots et termes techniques, vous allez faire fuir le lecteur. Comment voulez-vous qu'il ait envie de lire quelque chose dont il ne comprend même pas les titres ? Il fait inciter le lecteur à lire la suite du texte, en employant des mots simples et compréhensibles dans le titre.