Bonjour
merci beaucoup pour ton implication.
Je suis d'accord avec beaucoup de tes remarques y compris l'impression
de "cacophonie" lié à l'emploi pas toujours judicieux de guillemets et
de gras.
Par contre pour ce qui est du style de puces, je ne suis pas d'accord :
le style de puces utilisé dans ce document est celui "normalisé" des
How-To (plus joli d'ailleurs que celui que tu as mis pour le remplacer).
Idem pour les styles de caractères qui sont ceux présents dans les
How-To sur writer : j'ai utilisé, suite à des échanges que j'ai pu avoir
sur cette liste l'année dernière, les styles "MenuOption",
"ChoixUtilisateur", "BoutonOption" et "Touche" (qui fait l'effet "tache"
que tu décris).
Je veux bien adopter le nouveau style que tu proposes pour les touches
(c'est vrai que c'est plus joli). Par contre je préférerai conserver le
style de puces adopté précédemment (flèches bleues).
Sinon j'adhère à toutes tes remarques sur les tournures de phrase
induisant en erreur.
Par ailleurs, je fais suivre des remarques trés pertinentes envoyées par
Jean-Yves Royer (à moi même mais pas à la liste). Elles concernent
davantage le fond que la forme :
"D'abord, je n'ai pas compris quels sont les destinataires cibles de ce document. Il est
fait référence à des connaissances préalables : "Nous présumons que le lecteur connaît
les mots usuellement utilisés pour les fonctions automatiques des suites bureautiques, tels
que clic droit et clic gauche, point d'insertion, pointeur, fenêtre et fenêtre de
dialogue" (p. 4). Les exemples cités ne s'appliquent pas directement à une suite
bureautique mais aux systèmes de commande standardisés des ordinateurs et nulle part il n'est
fait référence aux connaissances génériques à tout traitement de document. La connaissance des
destinataires cibles serait utile pour effectuer la relecture.
Dans la page de garde, le paragraphe de sous-titre est encore coupé en trois
paragraphes, bien que Pierre ait pris soin de remplacer les fins de paragraphe
par des fins de ligne. Les majuscules intempestives ont bien été remplacées
mais les codes de mise en page qui provoquaient la pose automatique d'une
majuscule n'ont pas été corrigés. Ceci laisse supposer que l'auteur travaille
sans visualiser les codes de mise en page et ne connaît pas la différence
fondamentale entre fin de paragraphe et fin de ligne, commune à tous les
logiciels de traitement de documents destinés au papier ou à l'écran.
Ceci m'a donné envie d'arrêter là la relecture d'un guide sur le logiciel. La
meilleure formation n'est-elle pas l'exemple ? J'ai pris mon courage à deux
mains pour poursuivre. Je passe sur quelques erreurs mineures qui justifient
une relecture et sur l'absence encore fréquente d'espaces insécables, bien que
Pierre en ait ajouté beaucoup. J'ai noté et apprécié la disparition de nombreux
paragraphes vides.
Le chapitre 2 "Mise en page d'un document" donne quelques exemples.
"Plutôt que de surcharger le style de page par défaut (i.e. le style « Standard »),
il est préférable de créer son propre style" : cette assertion demanderait une
justification. Personnellement, je suis tenté de penser que les styles prédéfinis, y
compris ceux de page, sont la véritable couche de normalisation qui intéresse les
rédacteurs. Je ne comprends absolument pas l'acharnement des utilisateurs d'OOo à fuir
les styles prédéfinis, mais c'est un autre sujet...
Pourquoi dès la page 6 traiter de : "Insérer une page en mode paysage" ? Ceci d'autant plus que, de mon point de vue, cette partie induit le lecteur en erreur en proposant un cas virtuel que l'on ne rencontre jamais dans la réalité : une page en paysage suivie automatiquement d'une page en portrait. Ne faudrait-il pas repartir de la construction d'un document en diverses parties ? Si une partie du document doit être en paysage, il est exceptionnel (je ne connais pas de cas pratique) que le basculement en portrait doive être automatique à la page suivante. Il y a des cas fréquents où le changement de page peut se faire automatiquement, par exemple, dans une lettre où la première page est généralement différente des suivantes. On peut aussi prendre le cas du modèle d'how-to où la page de garde pourrait être différente de celles du corps de texte. C'est notamment dans le cas dans le modèle que j'ai proposé :
http://fr.openoffice.org/files/documents/67/4110/Modele_HowTo2.ott
Dans le cas de page en paysage, dans toutes les situations que je connais, il est
impératif de donner une nouvelle instruction de changement de sens du papier à la fin de
la zone qui doit être en paysage et dont il est généralement impossible de prévoir la fin
au moment où l'on décide du changement, car il faut toujours envisager les modifications
postérieures et leurs conséquences (principe de base de toute expression avec un
ordinateur). Il faudrait donc recommander que la page suivante soit encore en paysage.
L'exemple, me semble donc mal choisi et arriver beaucoup trop tôt car traitant d'un cas
exceptionnel qui fait l'objet d'un how-to auquel il faudrait reporter le lecteur. En
revanche, mais probablement un peu plus tard, il serait utile d'expliquer de manière
schématique la construction des documents par Writer et leur transformation en pages par
le mécanisme retenu par ce logiciel de "moulage" d'une partie de document dans
une séquence de pages aux propriétés pouvant différer. J'ai tenté de le faire page 18 de
ce document :
http://fr.openoffice.org/files/documents/67/4276/ConceptionStyles.odt.
"Le raccourci Ctrl + ENTER permet d'insérer un saut de page à partir d'un point précis sans
changement de style" (de page ?) (p. 6) est un autre exemple où le lecteur ne peut pas s'y
retrouver. En effet, OOo Writer n'insère pas de saut de page au sens de presque tous les logiciels
que je connais (code hex 0C) mais insère un paragraphe auquel il donne la propriété saut de page
avant (tout en paraissant stocker la propriété dans le symbole de fin de paragraphe qui précède le
saut). Il est donc important de signaler qu'un saut de page est toujours provoqué par une propriété
attachée à un paragraphe (si possible à travers un style). Il y a beaucoup de questions sur ce
point dans "users" car ce n'est pas évident à comprendre. Encore un point délicat qui
mériterait une illustration, mais comment la réaliser ?
Je vais arrêter là les exemples, car la densité de mes remarques est stable dans les pages qui suivent.
Dernier point concernant la terminologie. Je préfère éviter les termes de "saisie", "frappe", etc. pour les remplacer par les opérations réellement
effectuées par les utilisateurs : "écriture", "rédaction", "relecture", etc. Un élève ou un étudiant ne doit pas faire de
"saisie" ou de "frappe". Il doit "rédiger" ou "écrire" en utilisant correctement un moyen d'expression moderne, c'est-à-dire un
clavier connecté à un ordinateur supportant un logiciel adapté à la tâche à réaliser. C'est purement symbolique, mais je pense que cela a des conséquences fondamentales
sur l'usage de l'ordinateur.
En espérant avoir l'occasion d'échanger oralement pour contribuer à valoriser
le travail que tu as effectué et pour le rendre utile, notamment à des jeunes
qui doivent prendre de bons réflexes pour rédiger confortablement avec un
ordinateur et OOo Writer. De mon point de vue, il reste du boulot !
Bien cordialement.
Jean-Yves ROYER"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
