Adam continue sa série d'articles sur le travail collaboratif en nous présentant des études de cas et des conseil pointus pour vous aider à réussir votre prochain projet de travail en commun. Retour également de Joe Clark qui cette fois nous parle des solutions offertes aux non-voyants voulant utiliser un Mac. Dans les infos de la semaine, nous notons une offre intéressante de mise à jour pour les propriétaires de PowerBook 190 et 5300, notons la sortie du Handspring Visor Edge, de Photoshop 6.0.1 et de AirPort 1.3 (enfinc compatible avec PPPoE !), analysons la réaction de Napster face aux décisions de la justice américaine. Enfin nous accueillons un nouveau sponsor.
Cette édition de TidBITS est rendue en partie possible grâce au soutien financier de :
Dans mes deux précédents articles, je détaillais les obstacles à l'utilisation du Mac par des usagers handicapés, quels étaient les logiciels et les matériels disponibles pour remédier à ces obstacles (technologies adaptatives) et déplorais le fait qu'Apple ait délaissé les questions d'ergonomie informatique pour handicapés ces dernières années. (Voir "Accessibility on the Mac" dans TidBITS-568.)
De nos jours, évidemment, quasiment tout Mac vendu dispose d'une connexion à Internet, tout comme bon nombre de modèles plus anciens d'ailleurs - à commencer par mon coelacanthe personnel, un PowerMac 7100/66. Mais Internet a soulevé des tous nouveaux problèmes en matière d'accessibilité des personnes handicapées, avec une difficulté de plus : rendre le web accessible aux handicapés nécéssite non seulement d'importantes technologies adaptatives sur le Mac, mais aussi une conception du site très étudiée et des choix concernant le codage par les auteurs de sites. Si vous pensiez que l'accessibilité du Mac aux handicapés était déjà pas folichone, dites-vous bien que l'accessibilité au web est encore pire. Mais ne perdez pas espoir, les choses s'améliorent rapidement, quand même.
Attendre une version agrandie, ou en braille, ou une version audio qui sortira un jour (des mois plus tard, si jamais ça arrive dans l'absolu).
http://www.loc.gov/nls/web-blnd/bph.html
http://www.rfbd.org/catalog.htm
http://www.telesensory.co m/products2-1.html
Utiliser une machine à lire qui reconnait automatiquement les lettres et les lit à voix haute (une technologie quasi miraculeuse lorsque Raymond Kurzweil l'inventa en 1976 et qui, maintenant, est assez banale). Au début les machines à lire étaient des périphériques autonomes, mais de nos jours elles font partie du système et utilisent généralement Windows - mis à part le lecteur de texte électronique L&H Kurzweil 3000 qui tourne sur Mac.
http://www.ccs.neu.edu/home/elan/ray.html
http://www.LHSL.com/kurzweil300 0/mac/
En d'autres termes, pour rendre un livre imprimé accessible à un mal voyant, vous devez utiliser quelque chose d'autre que le livre en lui-même.
Sur le Web. -- Par contraste, pour rendre un site accessible, le site doit non seulement être organisé correctement mais, dans la plupart des cas, doit aussi faire appel à une technologie adaptative. Il faut faire une distinction importante entre l'accessibilité sur le Web et sur le Mac en général. Même à l'époque de Napster et de QuickTime, le Web reste malgré tout un médium visuel essentiellement composé de texte et d'images. Par conséquent, l'accessibilité ou l'inaccessibilité du Web concerne principalement les aveugles et les malvoyants.
Les internautes sourds ou malentendants risquent de rencontrer des problèmes d'accessibilité avec le multimédia, tout comme les personnes ayant des difficultés d'apprentissage ou souffrant de dyslexie, risquent d'avoir du mal à lire les textes multicolores que l'on trouve en ligne. Mais l'étendue de ces problèmes est faible comparée aux simples problèmes de visualisation et de compréhension de l'affichage.
Le site du W3C (Consortium du World Wide Web) propose toute une section très abordable sur l'acces au Web pour les personnes handicapées. Ces pages donnent des exemples ficitfs de gens avec divers handicaps et présentent les moyens qu'ils utilisent pour surfer sur le Web.
http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/Overview.html
En fait, rendre accessible son site web aux handicapés est synonyme d'augmenter le nombre d'options disponibles pour naviguer ce site. L'image affichée ne peut être vue pour une raison ou une autre ? Pas de problème, on vous fournit du texte à lire à la place. Malheureusement, des mesures aussi simples sont rarement mises en place. Les créateurs de sites web sont intéressés par beaucoup de choses : gagner leur vie, respecter les dates limites, faire de l'esbrouffe, s'exprimer, faire plaisir aux clients. Ce qui ne les intéresse en général pas du tout est l'accessibilité aux handicapés. Pourquoi ?
Méconnaissance. En général, les livres ou les formations traitant de la conception pour le web mentionnent rarement ce sujet. Les ateliers spécialisés ont rarement sous la main la technologie adaptée pour tester leurs créations, pas plus qu'ils ne testent l'accesibilité auprès de personnes handicapées (pour autant qu'ils fassent de quelconques tests).
Priorités (souvent mal placées). Les concepteurs web passent beaucoup de temps à coder des pages en JavaScript et peaufinent à l'excès des animations Flash, mais laissent trop souvent de côté les attributs ALT et autres aides à l'accessibilité.
Paresse. Comme on l'a vu dans des articles précédents, les handicaps mettent mal à l'aise. Coder pour rendre le web accessible aux handicapés nécessite de l'imagination - par exemple, concevoir comment un aveugle pourrait naviguer dans un site exige de se penser en aveugle.
Bien que ce ne soit pas simple, concevoir son site en tenant compte de l'accessibilité peut s'avérer utile même pour des publics non handicapés. De même que des accès de plain pied et des rampes d'accès facilitent l'accès des bâtiments aux personnes en fauteuil roulant, un site web accessible fonctionnera même pour des visiteurs dotés de navigateurs anciens, sur des navigateurs dont la fonction "affichage d'images" a été désactivée ou encore sur des téléphones portables ou des assistants personnels connectés au Web.
Les ressources. -- La responsabilité de cette situation ne repose pas entièrement sur les épaules des créateurs Web ni sur celles des clients qui paient le travail. Disons le clairement, la situation actuelle est aussi due au fait que les ressources disponibles pour la programmation de pages web accessibles aux personnes handicapées sont médiocres.
La norme définissant le langage HTML actuel inclut de nombreuses fonctionnalités permettant une meilleure accessibilité les balises ALT ne sont que la pointe de l'iceberg (bien qu'elle sont désormais obligatoires dans la version actuelle de HTML, 4.0.1). Les sources de ces spécifications HTML proviennent de la "World Wide Web Consortium's Web Accessibility Initiative" (WAI) ("initiative pour le développement de l'accessibilité du Web"), qui fournit des directives, des listes de points à ne pas oublier et propose des techniques pour créer des pages accessibles. Cependant, dans l'imposante tradition des documents produits par le Consortium, ces documents explicatifs sont longs, confus, sinueux, et soit beaucoup trop généralistes, soit détaillés à l'excès.
http://www.W3.org/WAI/
http://www.W3.org/TR/WCAG10/
Il y a étonnamment peu d'autres sources d'information en ligne pour la programmation web adaptées aux personnes handicapées. On peut trouver des liens sur les sites du "HTML Writers Guild Aware Center" ou sur celui dont je m'occupe, Web AccessiBlog.
http://www.awarecenter.org/
http://www.joeclark.or g/accessiblog.html#specs
Il n'y a que deux livres qui parlent de l'accessibilité dans la création web : "Universal Web Design", par Crystal Waters (épuisé), et "Web Accessibility for People with Disabilities" par Mike Paciello. (J'ai la semaine dernière signé un contrat avec New Riders Publishing pour écrire un livre concurrent).
http://www.typo.com/store/web books.html
http://www.webable.com/book_desc.htm
http://www.amazon.com/exec/obidos/ASIN/1929629087/tidbitselectro00A/
En résumé, il est difficile d'apprendre à coder en HTML pour rendre un site accessible. Et les outils de créations tels que Adobe Golive ou Macromedia Dreamweaver, et même le fidèle BBEdit, ne facilitent pas l'insertion de fonctions d'accessibilité. En général, il faut taper le code manuellement.
Voir le Web à travers un voile obscur. -- La conception des pages web est un aspect du problème ; les technologies adaptatives en sont un autre. Les personnes mal voyantes utilisent des logiciels d'agrandissement de l'écran tel que l'utilitaire CloseView d'Apple ou InLarge du Alva Acces Group.
http://www.aagi.com/aagi/inlarge.asp
(Pourquoi ne pas simplement sélectionner une police plus grande dans votre navigateur web ? N'oubliez pas que votre navigateur tourne sur un Mac. C'est tout le système qui doit être ergonomique, pas seulement le contenu de la page affichée. De belle grandes typos sur une page web ne vous aideront pas beaucoup si les polices dans votre barre de menu et les boîtes de dialogues s'affichent toujours en 12 malheureux points. De plus, à cause de pratiques douteuses d'écriture de pages web, beaucoup de sites s'affichent de manière affreuse et sont presque toujours inutilisables avec des polices plus larges.)
Si votre vue est médiocre au point que vous ne pouvez réellement voir ce qui est affiché à l'écran, même agrandi, vous avez besoin d'un lecteur d'écran - un programme qui interprète ce qui s'affiche à l'écran (texte, menu, icône et autres éléments). Toutefois, vous ne trouverez qu'un seul un lecteur d'écran pour Mac, "Outposken" par le Alva Access Group, et il n'interprète pas le HTML. Ceci est d'autant plus humiliant que du côté de chez Windows, les lecteurs d'écran sont diablement sophistiqués, interprétant les tableaux, les cadres et plusieurs des fonctionnalités d'ergonomie HTML
http://www.aagi.com/a agi/outspoken_products.asp
http://www.joeclark.o rg/accessiblog.html#screen
Et encore, même des sites web bien écrits peuvent rester inaccessibles parce qu'aucun navigateur n'est compatible à 100% avec HTML, laissant de côté toutes les fonctions d'ergonomie du langage.
http://www.joeclark.org/gloriou s.html
Netscape 4 est connu pour ses incompatibilités, même avec des balises HTML courantes depuis 1997. Microsoft Internet Explorer 5 pour Macintosh est supposé coler étroitement à HTML 4, mais ce n'est pas vrai (des fonctionnalités comme LONGDESC, utilisée pour un long texte d'explication d'une images, sont absentes). Le projet Mozilla conserve une liste importante de balises HTML non compatibles avec le nouveau Netscape 6, qui prétend pourtant être conforme aux normes
ht tp ://www.mozilla.org/newlayout/faq.html#Which%20open%20standards
Pendant ce temps là, le petit navigateur iCab (petit, mais costaud) gère de manière bien plus complète les balises HTML 4, notamment presque toutes les balises d'ergonomie (LONGSDESC est reconnu), et ce alors que les fonctions d''iCab en direction des handicapés ne soient pas mentionnées dans la documentation.
http://www.icab.de/
Et naturellement, avec seulement un lecteur d'écran pour Mac, qui de l'aveu même de ses concepteurs n'interprète pas le HTML, la fine intégration navigateur/lecteur d'écran que l'on trouve sous Windows est tout bonnement absente du Mac. Pour être franc, faire fonctionner la chose sous Mac, relève du miracle
En conclusion, l'ergonomie web pour les utilisateurs Mac malvoyants ou aveugles, est dramatiquement mauvaise. À court terme, ces personnes feraient mieux de se tourner vers Windows. Dans un prochain article, je mentionnerai les ruses qu'il faut déployer pour lire des contenus multimédia quand on est affublé d'un Mac. Comment "voir" toutes ces séquences QuickTime et ces animations Flash ?
[Joe Clark, ancien journaliste à Toronto, s'intéresse activement aux problèmes des handicapés depuis une vingtaine d'années. On peut trouver de nombreuses ressources en matière d'ergonomie/accessibilité sur son site web.]
http://joeclark.org/access/
par Adam C. Engst ace@tidbits.com
La semaine dernière, je me suis penché sur certaines des variantes en jeu lorsqu'on élabore un système de travail collaboratif pour élaborer un document à plusieurs. J'ai illustré mon propos avec l'organisation que nous avons mis en place ici chez TidBITS. Cette semaine, je vais présenter plusieurs autres systèmes de travail collaboratif que j'ai eu l'occasion d'expérimenter. Par ailleurs, sur le forum TidBITS Talk des lecteurs ont fait référence à des outils de travail collaboratif que je ne connais pas du tout ; consultez donc les liens suivants pour être sûr d'être au courant de toutes les possibilités qui s'offrent à vous.
http://db.tidbits.com/ getbits.acgi?tbart=06327
http://db.tidbits.com /getbits.acgi?tlkthrd=1312
Aux livres. -- J'ai écrit des livres pour un certain nombre de maisons d'édition, et, à une exception près, elles utilisent un système de travail collaboratif similaire au nôtre. Dans la plupart des cas, je travaille seul avec un ou deux correcteurs, ce qui veut dire que nous nous envoyons des chapitres par courrier électronique et c'est tout. Parfois les maisons d'édition demandent que je dépose les ébauches des chapitres sur un serveur via FTP, mais l'expérience prouve que ça ne vaut pas la peine.
Dans tous les cas, les maisons d'édition imposent le format Microsoft Word pour les documents qu'ils acceptent. Alors que j'ai écrit mes deux premiers livres dans Nisus Writer et les ai exportés dans Word au moment où je devais les remettre, je suis depuis complètement passé à MS Word. Je préfère - et de loin, utiliser Nisus Writer, mais l'exportation et la re-importation de fichiers pose à chaque fois tant de problèmes et m'oblige à revenir sur tant de petits détails - souvent plusieurs fois par chapitre, que j'ai fini par faire violence à mes préférences personnelles.
Avant Word 6, les grands changements au texte étaient indiqués par de simples couleurs (jamais par des changements de styles de caractères, qui pouvaient rester inaperçus jusqu'à la mise en page), mais lors de mes derniers projets je me suis plutôt servi des fonctions "Révision" offertes par Word et les résultats ne sont pas toujours bons. Ces fonctions sont utiles, surtout avec plusieurs correcteurs, car elles permettent d'établir qui a fait quel changement et quand, mais les documents ainsi anotés deviennent vite illisibles. On arrive à cacher une certaine partie du désordre en choisissant l'option "Masquer les modifications" au lieu du réglage par défaut qui barre le texte des passages supprimés ou corrigés. Mais même dans ce cas là il est facile de se perdre parmi toutes les annotations et de finir par plus savoir ce qu'il faut garder et ce qu'il faut supprimer dans le paragraphe corrigé. De plus, bien que Microsoft ait fait un effort pour rendre plus agréable le processus final qui consiste à passer en revue toutes les corrections pour les valider ou les rejeter, quand il y a beaucoup de révisions dans un document de la taille d'un livre, le processus devient si fastidieux qu'on finit par accepter mécaniquement les modifications sans discrimination pour pouvoir en finir.
Les conventions d'annotations pour les commentaires ont également été similaires dans tous mes projets ; le commentaire est toujours placé à l'écart après le paragraphe en question, utilisant en général une feuille de style de paragraphe spéciale "Commentaire" pour le rendre plus facile à repérer. Quand plusieurs correcteurs interviennent, la convention veut également que chacun paraphe son commentaire avec ses initiales. Cette organisation marche si bien que même quand MS Word a ajouté la fonction "Commentaire" à sa barre d'outils "Révision", on ne m'a jamais demandé de l'utiliser dans la préparation d'un livre. Je soupçonne que cette fonctionnalité est trop lourde à manier pour un emploi sérieux : les fenêtres contextuelles jaunes sont embêtantes, le volet commentaires est peu commode et utilise par défaut des caractères trop petits (et dans Word 2001 version Mac, le volet commentaire ne se ferme que par double-clic - une erreur de conception). En plus, puisque Word exige que les commentaires soient rattachés à au moins un mot, les correcteurs ont tendance à sélectionner de larges pans de texte pour y accoler un commentaire. Au bout d'un moment, si un document est fortement corrigé, il est parsemé de grands tronçons d'un jaune criard.
Quand j'ai écrit mon ouvrage "Eudora Visual QuickStart Guide" je n'ai pas utilisé le processus décrit ci-dessus. La maquette de cette collection est caractérisée par relativement peu de texte, de nombreuses copies d'écran et légendes, le tout présenté d'une manière particulière. En conséquence j'ai rédigé le texte et fait la mise en page directement dans QuarkXPress. Etant donné que QuarkXPress 3.3 ne dispose pas d'une méthode efficace pour anoter le texte, j'ai fini par envoyer les fichiers à mon éditeur qui les imprimait et annotait les épreuves papier au stylo rouge avant de me les renvoyer par coursier UPS. Cela peut paraître archaique comme méthode mais comme la majorité des annotations concernaient des problèmes de mise en page (interlignage, alignement, etc), il y a fort à parier que si nous avions utilisé une forme d'annotation électronique du fichier, cela aurait été plus difficile à manier et représenté plus de travail pour intégrer les corrections.
Écrire pour les magazines et pour le Web. -- Le travail collaboratif sur des documents destinés à la presse ou au web ressemble au travail sur des livres dans le sens qu'il y a souvent peu de rédacteurs (un ou deux au maximum) et qu'on a tendance à se passer et repasser les épreuves par courrier électronique. La majorité des magazines vous impose MS Word comme format de documents. En revanche, les publications sur le Web préfèrent un texte au format "texte seul" ou bien un courrier électronique, voire, dans certains cas, du HTML.
Étant donné les délais de publications serrés auquels sont soumis ces publications, le va et vient des corrections est généralement minime. Par contre, dans le cas d'un article plus consistant a paraître dans une publication mensuelle le processus fait généralement appel à plusieurs correcteurs et bon nombre d'allers-retours avec l'auteur. J'ai écrit pour un magazine qui utilisait un système de travail collaboratif mis en place progressivement et à l'emporte-pièce, sans grande cohérence. Ils avaient pris un bon départ mais n'étaient pas allés jusqu'au bout. Les corrections étaient soit notées en bleu, soit indiquées via la fonction "Révision" de Word, soit indiquées mais non définies. Non seulement ces méthodes étaient utilisées indistinctement mais de plus leur utilisation n'était pas cohérente, ce qui perturbait les auteurs.
Par ailleurs, alors que la plupart des correcteurs insèrent leurs commentaires après le paragraphe concerné, d'autres l'inséraient au beau milieu du texte. Il suffit alors de deux ou trois commentaires un peu longs dans un paragraphe pour vous faire complètement perdre le fil du discours. Tout comme dans les milieux de l'édition, je n'ai jamais rencontré quiconque dans la presse écrite ou magazine qui utilise la fonction "Commentaire" de la barre d'outils "Révision" de MS Word. Par contre, dans d'autres situations professionnelles, j'ai fait des expériences variées.
Documents légaux. -- Quand j'aidais au démarrage de l'organisation publique XNS, nous avons travaillé, les autres directeurs et moi, sur de nombreux documents longs et complexes - tels que notre charte, les termes définissant globalement le XNS, et quelques agréments légaux divers. Bien qu'il y ait simplement quatre membres du bureau, et notre avocat, nous n'étions pas dans une configuration auteur/rédacteur, nous n'avions pas de serveur centralisé, ni de relecteurs professionnels
http://db.tidbits.com/ getbits.acgi?tbart=06133
Notre approche a été d'envoyer par courriel des documents Word. Nous étions tous très occupés, aussi avons nous opté pour un tour de rôle, de façon à ce que chacun de nous soit en mesure de voir les commentaires précédents, à l'exception de notre avocat, qui travaillait parallèlement à nous (j'ai essayé, sans le moindre succès, d'utiliser les fonctions "Comparaison" et "Fusion" offertes par MS Word, afin de fusionner les commentaires et les changements). Nous révisions assez souvent, mais au moment où nous avons repris et discuté ces documents, quelques menus changements ont été nécessaires. Cependant, nous avons terminé en utilisant intensivement la fonction "Commentaire" de Word (à peu près 100 commentaires pour 2 documents), et bien qu'elle ait fonctionné de façon acceptable, je l'ai trouvé pataude pour un usage intensif.
Il est arrivé quelque chose d'inhabituel au moment où nous finalisions les définitions générales du XNS, juste avant de lancer l'opération. Nous étions dans des délais très serrés, un jour avant l'échéance, et dix personnes environ étaient engagées, dont la moitié étaient des juristes. Initialement, nos essayions de donner les documents à une seule personne, en résolvant les problèmes restants lors d'une conférence téléphonique, mais cela s'avéra très peu pratique. L'un des juristes recommandait de récupérer les documents à partir du courriel, mais qu'une personne soit responsable de chaque document. Comme les documents originaux étaient au format Word, nous les avons laissés en l'état, même si notre but était de les extraire pour les convertir en HTML ce soir-là. De plus, même si nous utilisions une grande variété de modèles de Mac et de PC, chacun avait une version récente de Word.
La fonction de repérage des révisions de Word a trés bien fonctionné dans ce cas, car tous les changements étaient clairement indiqués. Nous n'avions pas de secrétaire de rédaction en fin de projet, il était donc important de s'assurer que les plus petites modifications soient prises en compte. Nous avons utilisé la fonction "Commentaire" de Word sporadiquement, pour noter des éléments du texte que seul le "propriétaire" du document avait besoin de voir, mais la plupart des commentaires sont passés via des messages électroniques qui assuraient le transfert des documents en annexe. Ce système a permis aux échanges d'être rapides et libres (j'avais configuré Eudora pour une vérification de courrier toutes les minutes) sans nous forcer tous à ouvrir et à éplucher chaque document. Contrairement à mes autres projets, ici nous n'avons pas inclus de commentaire entre les paragraphes, parce que nous craignions d'ajouter du texte qui pourrait s'avérer difficile à isoler du document au moment de la "couture", d'ailleurs nous n'avions pas le temps d'établir un mode de commentaire systématisé.
La leçon que j'ai tirée de ces expériences est que l'utilité des documents Word est gravement diminuée s'ils contiennent beaucoup de feuilles de styles définies par l'utilisateur. Sans une bonne dose d'attention, et surtout d'une bonne connaissance du fonctionnement des feuilles de style dans Word, un document Word contenant plusieurs styles est un vrai champ de mines pour les relecteurs. Les documents de ces collaborations étaient excellents en termes de contenu, mais un vrai bourbier pour le reste. Quelques paragraphes étaient dans le mauvais style, d'autres paraissaient corrects, mais avaient en fait été "réparés" manuellement ; presque tout ce que Word avait fait automatiquement (comme les listes numérotées - élément essentiel d'un documents légal) était systématiquement vicié. Bien sur, nettoyer un document est plus facile que de tout re-formatter en partant de zéro, mais guère plus.
Un système collaboratif d'échange de documents simple. -- Pour résumer mon expérience avec les processus décrits ci-dessus et le système de TidBITS que j'ai décrit la semaine dernière, voici six conseils pour créer un système collaboratif efficace de partage de documents destinés à la publication sous toutes ses formes : mémoire, rapport en équipe, article de magazine, ou livre technique.
Avant tout, choisir un format. En toute probabilité, ce sera Microsoft Word, mais si on choisit autre chose, s'assurer que chacun a un logiciel qui peut ouvrir et éditer les fichiers. Attention aux problèmes de compatibilité entre plates-formes. Se fier à différents programmes pour importer-exporter est souvent un sérieux obstacle.
Vérifiez que votre choix de type de correspondance fonctionne bien. Les pièces attachées de courriel sont très fiables aujourd'hui, mais il vaut mieux tester cette fiabilité pour ne pas risquer des maux de tête sans fin. N'oubliez pas de consulter notre série d'articles sur les pièces attachées pour vous aider dans votre choix.
http://db.tidbits.com/g etbits.acgi?tbser=1159
Mettez vous d'accord sur des conventions minimales pour ce qui est des corrections. Choisissez des couleurs, ou encore les fonctions de traçage de corrections qu'offre Word pour enregistrer vos modifications, et si votre traitement de texte ne vous permet pas d'utiliser des couleurs, décidez d'une convention typographique quelconque (que vous n'oublierez pas d'effacer avant publication). Ne signalez que les modifications majeures. Dans Word, il vaut souvent mieux masquer ce qui a été effacé pour améliorer la lisibilité.
Un autre point d'accord à trouver entre les différents collaborateurs est celui de savoir la manière dont les commentaires apparaîtront. On peut soit les mettre entre chaque paragraphe (dans un style différent ou en les faisant précéder d'une chaîne de caractère prédéfinie) ou bien en utilisant la fonction commentaire dans Word. Si vous utilisez Word, n'oubliez pas de faire figurer par chaque participant dans l'onglet "Informations Utilisateur" du menu "Préférences" de manière à ce que chaque commentaire soit identifié, et si vous n'utilisez pas cette fonction, faites signer chaque commentaire.
Il faut encourager avant tout la cohérence et le respect des règles que vous vous êtes données. C'est essentiel quand plusieurs personnes font des contributions d'égale importance à un document dont le formatage est complexe. Lorsqu'il ne s'agit que de commentaires ou si vous travaillez sur un document peu formaté, il est plus facile de laisser la bride sur le cou à vos correcteurs.
Assurez vous que tout le monde sait qui sera en charge du document final et assurera donc les dernières tâches, telles que l'intégration des commentaires, la validation des changements, le nettoyage des marques et commentaires, ainsi que le fignolage de dernière minute.
En ligne. -- Toutes les procédures décrites ci-dessus ne se servent d'Internet que comme moyen de transport des informations. Dans la suite à paraître de cet article, je m'attarderai sur plusieurs services qui offrent des environnements multiutilisateurs accessibles via le Web, sans que vous ayez besoin de recourir à des logiciels spécifiques.
Les publications et les sites web sans but lucratif peuvent réimprimer ou créer des liens vers nos articles en référençant leur origine. Pour les autres, contactez-nous, SVP. Nous ne garantissons pas l'exactitude de nos articles. Caveat lector. Les noms de publication, de produit et de compagnie peuvent être des marques déposées. TidBITS ISSN 1090-7017.
Accueil | Archives francophones de TidBITS | Sommaire des quatre derniers TidBITS traduits | L'Equipe francophone de TidBITS
