Journal Elaboration collaborative de documents

Posté par JoeBar le 12 juillet 2005 à 10:04.

Étiquettes :

juil.

2005

Bonjour

Je profite que mon MS Word est planté pour vous présenter quelques réflexions sur un sujet qui me tracasse.
Avant que ça ne plante, je travaillais sur le document de spécifications fonctionnelles de notre application, qui est un document Word de 250 pages, pesant 20 Mo.
Je trouve que c'est très peu pratique de travailler avec Word pour ce genre de tâche, même sorti des bugs de Word (il parait que ma version est notoirement boguée, mais passons).
Voila la liste des problèmes que cela engendre :
- lourdeur du document (même avec un réseau rapide, 20Mo c'est parfois long)
- perte de temps sur la mise en page. Soit c'est que le document est mal fait, soit que je ne sais pas bien utiliser word, mais je perds beaucoup de temps sur la mise en page des titres, tableaux, images etc.
- impossibilité de gérer efficacement les versions du document avec un gestionnaire de version et de voir les différences entre deux révisions.

Il est vrai, je crois, que word propose la gestion des versions, au prix d'un augmentation du poids du fichier. Je ne sais pas ce que ça vaut, mais j'ai tendance à préférer CVS. Sinon dans ma boîte quand on fait une montée de version on crée un nouveau fichier. Je ne trouve pas non plus cela très pratique.

Vous aurez compris que je cherche une alternative à Word. Les contraintes sont que le fichier est éditable par plusieurs personnes de façon pas forcément concurrente. Je pense qu'il faut une interface pratique et visuelle pour que ça puisse être d'une édition efficace et que les gens ne soient pas rebutés. Il est à noter que ces documents de specs sont édités par des ingénieurs, donc des utilisateurs avancés et capables de se former.

J'ai pensé aux solutions suivantes :
- OpenOffice, évidemment, mais cela ne résout aucun des points ci-dessus. Je préfère le gestionnaire de styles d'OO mais je suppose que c'est parce que je connais mal Word. Les documents sont tout de même plus légers, c'est un bon point, par contre pour être efficace il faudrait que le gestionnaire de source connaisse le format Oasis et dézippe les documents avant de les archiver, pour pouvoir avoir des rapports de diff clairs. Encore faudrait-il pouvoir les exploiter...
Les deux qui apportent vraiment de la nouveauté sont les suivantes :
- Latex. Là je n'y crois pas, ou alors avec un bon éditeur WYSIWYG ? Pour une utilisation en production par plus d'une personne, cela me semble trop complexe.
- DocBook. Peut-être la bonne solution, bien que ça pose une partie des problèmes de latex. Les éditeurs que j'ai essayés n'avaient rien
de transcendant.

Peut-être que j'oublie des solutions ? Dans ce cas je serai ravi de les entendre. Les propositions d'éditeurs efficaces (entendre : permettant d'éditer le document rapidement) sont bienvenues aussi.

Je considère donc en opposition la solution traitement de texte (word / OOo) et la solution Latex / DocBook.
------ traitement de texte ------
* les plus :
gestion simplissime des images
simplicité de la mise en oeuvre (pas de CVS, un partage réseau et ça roule)
pas besoin de former les utilisateurs

* les moins (déjà donnés au dessus)
lourdeur du document
mise en page à gérer à la main, souvent foireuse
gestion de version peu pratique

------ latex/docbook avec gestionnaire de version -------
* les plus
gestion automatique des titres et de la mise en page
document de sortie propre, voire dans plusieurs formats
vue facile des révisions
édition concurrente

* les moins
nécessite d'avoir un projet CVS dédié aux documents, ou de les
intégrer au dépôt des sources
format d'échange moins pratique notamment en cas d'élaboration commune avec le client
nécessite un apprentissage
gestion manuelle des images

Maintenant que je vous ai donné mon avis, j'aimerais savoir, tout d'abord si vous êtes d'accord avec ce que j'ai dit, et ensuite si l'un d'entre vous a déjà eu l'occasion d'utiliser pour ce genre de besoin autre chose qu'un traitement de texte. Est-ce que ça marche, est-ce que c'est plus efficace, quelles sont les réactions des gens ?

Je ne crois pas une seconde convaincre qui que ce soit dans mon entreprise (ou alors au mieux pas les bonnes personnes) donc je fais cette démarche uniquement dans un but rhétorique, en quelque sorte...

Merci de m'avoir lu, toutes les réactions sont bienvenues !

# ma vision a moi que j'ai

Posté par zerchauve le 12 juillet 2005 à 10:46. Évalué à 7.

Latex ca roxe. On l'utilise ici (entreprise petite taille), avec CVS. Le probleme du positionnement des images ne se pose qu'a la fin, donc c'est pas la peine de galérer.

Sinon pourquoi ne pas utiliser un wiki pour l'élaboration du document, sur une machine en interne et développer un export XSLT potable pour générer le doc final ? (personnellement c'est l'avenir tel que je le vois pour notre boite).
- [^] # Re: ma vision a moi que j'ai
  
  Posté par JoeBar le 12 juillet 2005 à 14:40. Évalué à 3.
  
  Je ne comprends pas ta remarque sur les images qu'on ne positionne qu'à la fin...
  
  Pour le wiki, c'est vrai que j'y avais pensé mais le document est bien trop gros pour tenir sur une page, et dans ce cas comment le découper ? Ca demanderait un bon coup de développement, mais une plate-forme de gestion de documents + wiki d'édition, qui génère du xhtml propre dont on fait ce qu'on veut, c'est peut etre la bonne solution. Faudrait que je cherche si ça existe. Et la syntaxe wiki, c'est vite appris, même le client peut apprendre ça ;)
  - [^] # Re: ma vision a moi que j'ai
    
    Posté par scand1sk (site web personnel) le 12 juillet 2005 à 17:12. Évalué à 2.
    
    Ben intégrer une image dans un document Latex, c'est quelques lignes dans le code du doc, et l'image se place dans le texte toute seule plus ou moins intelligemment.
    
    Par exemple, pour insérer l'image nommée "unsat.ps" avec une légende et une référence :
    
    \begin{figure}[h]
    \centerline{\includegraphics[height=3in,angle=-90]{unsat.ps}}
    \caption{Proportion of detected unsat instances when establishing the consistencies}
    \label{fig:unsat}
    \end{figure}
    
    En général c'est suffisant, si on est tatillon on peut essayer de les repositionner à la main à la fin, mais je pense pas que ce soit indispensable.
    - [^] # Re: ma vision a moi que j'ai
      
      Posté par JoeBar le 13 juillet 2005 à 10:16. Évalué à 2.
      
      Bien sûr, c'est pourquoi j'avais mis cela dans les avantages (pas de mise en page manuelle).
      
      En revanche, pour ce que j'avais mis dans les inconvénients, la gestion manuelle des images, je voulais dire que tu dois sauvegarder ton image qqpart, lui donner un nom, la placer au bon endroit, et mettre son chemin et son nom dans le fichier latex. Sous OO/Word, ctrl-c, cltr-v. Incomparable :)
      Et il y a autre chose aussi : c'est les diagrammes ; c'est énormément plus facile de modifier un diagramme fait directement dans le traitement de texte. Si le diagramme est fait avec autre chose, c'est toute une histoire s'il faut le retrouver, modifier, et enregistrer au format image à la place de l'autre.
# ça n'aide pas...

Posté par ploum (site web personnel, Mastodon) le 12 juillet 2005 à 10:52. Évalué à 3.

..mais ça te consolera de savoir qu'on pense à toi ;-)

http://lists.gnu.org/archive/html/criawips-devel/2005-05/msg00003.h(...)
Mes livres CC By-SA : https://ploum.net/livres.html
- [^] # Re: ça n'aide pas...
  
  Posté par olosta le 12 juillet 2005 à 14:13. Évalué à 2.
  
  Grrmgrml....
  
  Ils pourraient pas diffuser leur document dans des formats ouverts ET répandus.
  
  Désolé, c'est tellemnt rare de pouvoir pester contre du abiword.
  
  Et ploum tu sors de cette liste ;-)
# Et les documents maitre OOo ?

Posté par olosta le 12 juillet 2005 à 10:52. Évalué à 4.

Tu trouvera peut-etre un peu de souplesse du coté des documents maitres dans OOo. Je ne m'en suis jamais vraiment servis mais ça te permet de découper ton fichier en parties indépendantes et d'utiliser le document maitre pour les inclure dedans et unifier les styles, les index...

Tu pourrait déjà avoir une taille de document gérable avec ça. Il me semble qu'OOo fait également du controle de révision mais j'ai jamais testé.

(ma vie)
J'ai fait une infidélité a LaTeX au profit d'OOo pour mon rapport de stage mais je crois que je ne retenterais pas l'expérience.

Je pense qu'actuellement rien ne vaux un bon LaTeX propre, peut etre Docbbok aussi.
(ma vie)
- [^] # Re: Et les documents maitre OOo ?
  
  Posté par Laurent Godard le 13 juillet 2005 à 09:57. Évalué à 3.
  
  Il me semble qu'OOo fait également du controle de révision mais j'ai jamais testé.
  
  Il ya deux choses et ca marche meme plutot bien ;)
  
  - le controle de revision, accessible par Edition > Modifications et les sous menus. Permet d'enregistrer les modifications, de les afficher, le tout colorisé par intervenant
  
  - la creation de version par le menu Fichier > Versions sur un fichier deja existant. permet de metre des commentaires etc ...
  
  Tu as un HowTo disponible à ce sujet ici
  http://fr.openoffice.org/Documentation/How-to/indexht.html(...)
  section Writer N°10
  
  Laurent
- [^] # Re: Et les documents maitre OOo ?
  
  Posté par Laurent Godard le 13 juillet 2005 à 13:00. Évalué à 1.
  
  Je pense qu'actuellement rien ne vaux un bon LaTeX propre, peut etre Docbbok aussi.
  
  Pour DocBook, peut etre egalement regarder du coté de ooo2dbk qui te permet d'ecrire dans OOo et ensuite d'exporter au format DocBook
  http://www.indesko.com/sites/fr/telechargements/ooo2dbk/view(...)
  
  Laurent
# Elaboration collaborative de documents

Posté par TemPi le 12 juillet 2005 à 10:53. Évalué à 2.

Pour de l'élaboration collaborative de documents, rien ne vaut un wiki.
Bon, par contre, ca demande une petite education pour la syntaxe...
- [^] # Re: Elaboration collaborative de documents
  
  Posté par Lawrence P. Waterhouse (site web personnel) le 12 juillet 2005 à 15:32. Évalué à 2.
  
  Pour de l'élaboration collaborative de documents, rien ne vaut un wiki.
  
  Oui, c'est ce à quoi on pense tout de suite, mais pour transmettre le document à un tiers? Existe-t-il un wiki qui génère un document MS-Word ou OOo?
  - [^] # Re: Elaboration collaborative de documents
    
    Posté par Beretta_Vexee le 12 juillet 2005 à 16:33. Évalué à 2.
    
    Mediawiki et beaucoup d'autre on des extentions qui sortent du PDF, du XML ou autre. Donc a priorit pas de probléme de ce coté la, il faut juste revoir un peut la mise en page et les styles par defauts qui sont un peut frustre.
    - [^] # Re: Elaboration collaborative de documents
      
      Posté par cedric le 12 juillet 2005 à 19:19. Évalué à 1.
      
      Mouais, sauf que l'edition en ligne, c'est vraiment pas ca. Je ne comptes plus le nombre de fois ou j'ai perdu du contenu. C'est vite frustant, sans compter la syntaxe...
      - [^] # Re: Elaboration collaborative de documents
        
        Posté par TemPi le 15 juillet 2005 à 09:45. Évalué à 1.
        
        Perdre du contenu ?????
        Normalement, avec un wiki, tu as l'historique des modifications... alors ????
    - [^] # Re: Elaboration collaborative de documents
      
      Posté par JoeBar le 13 juillet 2005 à 16:09. Évalué à 3.
      
      > Mediawiki et beaucoup d'autre on des extentions qui sortent du PDF, du XML ou autre.
      
      C'est une bonne idée oui, mais comme dit plus haut il faut voir comment gérer le sommaire et le découpage du document en parties qui seraient automatiquement rassemblées lors de la sortie PDF ou autre. Parce qu'un document de 250 pages A4 en une seule page médiawiki, je n'y crois pas une seconde...
      Et pour ça je pense qu'il y a besoin de développement spécifique, non ? J'imagine qu'ils n'ont pas ce besoin dans MediaWiki.
      
      Au fait : on écrit frustes et non frustres, l'erreur est commune :)
      - [^] # Re: Elaboration collaborative de documents
        
        Posté par Sylvain Sauvage le 13 juillet 2005 à 17:26. Évalué à 4.
        
        Au fait : on écrit frustes et non frustres, l'erreur est commune :)
        
        Quel rustre !
        
        ...ou ruste ?
        
        Ah non, ruste, c'est quand on prononce bien jota et que le prof. d'espagnol nous dit « c'est ruste ! »
# vue facile des révisions

Posté par dripple le 12 juillet 2005 à 14:04. Évalué à 1.

Word propose aussi une vue facile des révisions... Il suffit des les activer...

Sinon, si tu as une solution, je suis intéressé... :-)
- [^] # Re: vue facile des révisions
  
  Posté par cedric le 12 juillet 2005 à 19:17. Évalué à 1.
  
  Mouais, sauf qu'il ne propose pas vraiment de maniere simple de gerer plusieurs editeurs en parallele. Le process que veut imposer Word, c'est une intervention de chaque personne impliquer au fur et a mesure. Alors que la logique voudrait que chacun puisse intervenir comme sur un CVS.
  
  Avec Word, on finit par dir qu'il y a un mainteneur qui integre tous les changements dans son doc a coup de copier/coller et donc aurevoir les notes de changement...
# kile

Posté par riba le 12 juillet 2005 à 14:23. Évalué à 2.

Tu peux utiliser Kile (un projet) + repo CVS.
Kile permet d'oublier le long apprentissage de latex (mais pas à la mode lyx où on change tout, ici ça reste du code latex propre).
Si t'es très motivé, tu code un "outil externe de l'éditeur", genre KCVSText, qui fait:
- côté cvs: co, update, ...
- appel à kompare en externe (pour voir les diff).
Sinon, en rajoutant juste quelque raccourcis (juste du shell) dans le menu outils, ça doit aller.
- [^] # Re: kile
  
  Posté par vrm (site web personnel) le 12 juillet 2005 à 14:40. Évalué à 1.
  
  ca existe en gnome/gtk/pas-qt ?
  - [^] # Re: kile
    
    Posté par riba le 12 juillet 2005 à 15:10. Évalué à 2.
    
    heuhhh.. Gile?
    En tout cas, début 2004 ( http://linuxfr.org/~rb14/8998.html(...) ) ça existait pas.
# et l'html ?

Posté par ZeroHeure le 12 juillet 2005 à 16:58. Évalué à 3.

Comme d'autres j'ai immédiatement pensé au Wiki. C'est un outil presque "universel": il y a quelques jours un journal racontait comment le wiki a remplacé la base de connaissance dans une boite... et là j'en suis à prendre des notes avec mon wiki.
Il me semble qu'il y a un ou des éditeur qui envoient directement ton texte sur le Wiki. Je pense qu'on utilisera de plus en plus les Wiki, pour un tas de choses.

Bref, je voulais surtout parler de l'html: Nvu, Amaya ou l'éditeur de Mozilla sont parfaits (avec enregistrement sur le cvs), présentent une interface "traitement de texte", nécessitent peu d'apprentissage... Normalement ce paragraphe devrait être plus long que le précédent, voici donc un extrait du 13ème apôtre (de Jean-Pierre Rosnay http://www.poesie.net/apotre1.htm(...) pour changer de sujet:
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire.
Je ne sais plus laquelle de mes vies est vraie, si c'est une de celles que j'ai vécues ou celle que j'ai imaginée. Et, mon crayon titubant entre les lignes, ressemble étrangement à un homme ivre, qui raconterait des histoires dans la nuit aux becs de gaz. Des histoires dont tout le monde se fiche. Je n'ai rien que moi. Je ne puis aller plus loin que moi, et je me hais.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Tu n'es pas le seul

Posté par cedric le 12 juillet 2005 à 19:50. Évalué à 2.

J'ai deja pas mal reflechi a une solution a ce probleme et surtout comment faire pour la gerer.

L'idee que j'ai serait d'utiliser un fichier qui decrirait le repository (CVS, SVN, cogito, ...) la maniere de s'y connecter et un pointeur sur un cache local.

Ensuite serait sauvegarder directement a la racine du module du SCM un fichier OASIS non compresser (pour avoir les changements par ligne). L'etape suivante, c'est l'integration des notes de changements et finalement la resolution des conflits.

Maintenant, la premiere etape est la plus simple, et il me parait possible de pouvoir aisement l'integrer dans Koffice. L'etape suivante demandera deja plus de travail, mais vu que les informations affiches restent de meme nature que celle des notes de modification ca reste encore faisable. Par contre la derniere etape me parait tres difficile, car je ne vois pas vraiment comment integrer ce genre d'interface dans un logiciel de type traitement de texte, mais encore moins sous un truc comme un tableur ou un logiciel de presentation.
# Une solution ?

Posté par ploum (site web personnel, Mastodon) le 13 juillet 2005 à 09:45. Évalué à 3.

http://gosu.pl/php/simpledoc.html(...)

ça a l'air pas mal du tout !
Mes livres CC By-SA : https://ploum.net/livres.html
- [^] # Re: Une solution ?
  
  Posté par JoeBar le 13 juillet 2005 à 10:23. Évalué à 2.
  
  Tout à fait, ça a l'air bien !
  Si je trouve le temps, j'essaie ça un de ces jours et je réponds dans ce fil pour donner mon avis.
# Docbook !

Posté par Nicolas Delsaux (site web personnel) le 13 juillet 2005 à 11:28. Évalué à 1.

Docbook est la solution :
- des documents XML simples à comprendre sans souci de mise en page
- des éditeurs totallement wisiwyg, comme par exemple abiword (avec le plugin docbook)
- un rendu de folie dans de multiples formats (pour peu évidement que quelqu'un connaisse XSL dans ta boîte).

Pour info, ils utilisent, je crois, docbook pour l'écriture des bouquins chez Eyrolles (genre les cahiers du programmeur) ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.