Interopérabilité de do•doc

Bonjour,

Tout d’abord je dois dire que je suis super impressionné par la qualité de l’outil do•doc, bravo pour ce boulot c’est vraiment chouette! (j’ai été développeur web, et je comprends la complexité de ce projet).

Travaillant dans un fablab et sur plusieurs projets opensource (vélo bois opensource et maison ossature bois opensource), je trouve votre outils génial, surtout pour les raisons suivantes:

  • outils de captures (tout y est!)
  • mutualisé sur un ordinateur (les documents ne sont pas éparpillé sur plusieurs machines)
  • et en réseau local (pas besoin d’internet :pray: idéal pour des projets en extérieur ou en atelier)

Mais ce qui m’empêche d’utiliser do•doc, c’est son interopérabilité. Je me demande pourquoi les champs textes ne sont plus en markdown (il y a de très bon WISIWIG pour markdown). Le résultat actuel de l’export des textes, donne qlqch d’inutilisable par autre chose que do•doc.

Mais peut-être que ça pourrait se fixer en créant une nouvelle fonction de création de contenu final (le document « page à page » lui aussi est très peu « interopérable »), mais ajouter une option « page continue » où l’on glisse simplement les médias les uns sous les autres (comme un CodiMD/HedgeDoc) et qui export en markdown. Certes moins « fun » et flexible que le document « page à page », mais qui assure un résultat sobre et beau (le WISIWIG poussé à fond, ça peut donner des trucs très kitch et illisibles) et surtout importable sur tout support qui accepte du markdown (Grav, Jekyll ou Wordpress pour des sites webs/blogs, pandoc pour du PDF, …). En gros la fonction « Récit » mais qui export en markdown continu (+ médias en liens).

Je me rends bien compte que la cible première de do•doc c’est les enfants, et pour cela il répond à tous les critères, mais je crois réellement qu’il répond à un besoin plus global de beaucoup de lieux (makerspaces, fablabs, tiers-lieu, associations, coopératives, …). Et pour cela je pense que les documents produit doivent être les plus standards possibles, aussi dans le cas où le projet do•doc ne serait plus maintenu et qui faudrait migrer vers d’autres solutions.

Désolé d’avoir fait un peu mon « chapeau noir », je reste persuadé que votre projet est l’un des plus abouti niveau création documentation.

Dorian

PS: Bon, encore une remarque :sweat_smile: le « point médiant » de « do•doc » le rend presque introuvable sur les moteurs de recherche (problème de référencement), quand je parle du projet à d’autres ils.elles ont du mal à retrouver le siteweb/ les informations. Il y a p-e des solutions niveau « SEO » à regarder…

Bonjour et merci pour votre chouette retour :slight_smile:

Vaste sujet que celui là, et de très nombreuses discussions ont eu lieu pour aboutir à ce choix !

Les champs de texte étaient en markdown il y a quelques années mais peu d’utilisateurs (notamment les plus jeunes, mais pas que) arrivaient à adopter la syntaxe et les textes étaient du coup très peu mis en forme. Le markdown ne permet pas non plus certaines choses qui nous semblent indispensables, comme le changement de famille de caractère ou de taille typo de manière fine. À titre personnel j’utilise beaucoup le markdown pour la prise de note, mais je conçois parfaitement que ça ne fonctionne pas pour beaucoup de publics (et les résidences / observations / discussions avec des partenaires nous l’ont bien montré). Nous avons notamment constaté la difficulté à prendre en main un wiki dans un fablab, et do•doc a également été développé en réaction à cette situation.

Nous avons donc opté pour l’intégration de l’éditeur de texte Quill, dont le rendu HTML est assez propre :

<p>Je veux <strong>écrire</strong> un <em>bout</em> de <span style="background-color: rgb(255, 128, 140);">texte</span>.</p>
<h1 class="">Mon titre</h1>
<h2 class="">Et sous-titre</h2>

La possibilité d’intégrer des blocs personnalisés (média + légende par exemple) et la possibilité de l’associer avec d’autres modules pour que les blocs textes soient collaboratifs a conforté ce choix.
Sans oublier que le HTML est un standard ouvert qu’on peut coller dans un bloc Wordpress tel quel, par exemple.

Mais j’entends bien vos exemples, qui me semblent collé aux pratiques d’utilisateurs un peu plus experts que la moyenne. Du coup on pourrait imaginer l’une des choses :

  • un mode particulier de la recette récit (ou un nouveau type de recette) pour approcher ce que vous décrivez,
  • ou pouvoir indiquer si, pour un bloc texte, on préfère le mode WYSIWYG ou le mode Markdown

Mais il ne faudrait pas que ça ajoute de la complexité à une interface qui se charge un peu plus à chaque version (et ça commence à devenir un soucis, je trouve).

Merci encore pour le retour en tout cas, à voir :slight_smile:

Bonjour,

Nous utilisons aussi de plus en plus CodiMD sur la plateforme AppsEducation pour la prise de note collaborative.
Les documents en Markdown permettent d’écrire du texte avec des médias insérés (son / image / vidéo / iframe…). C’est rapide et propre pour un certain nombre d’utilisations mais c’est assez différent de la logique de do•doc et des blocs de texte.

Je trouve que les blocs texte de dodoc se rapprochent des logiciels de composition graphique (Inkscape / Scribus) alors que CodiMD se rapproche d’un traitement de texte comme LibreOffice.

L’outil texte dans do•doc permet d’intégrer du texte en calque sur une image par exemple pour faire un écran titre d’une vidéo et servir ensuite dans une recette « montage vidéo ».

Les mises en page type « poster » sont assez simples à faire sur dodoc, ce qui n’est pas le cas sur CodiMD.

Je vois bien l’intérêt d’un éditeur MD pour rédiger rapidement et proprement de la documentation dans un fablab, mais pourquoi forcément l’intégrer dans dodoc ?
Une combinaison de CodiMD/Hedgedoc et dodoc sur un serveur pourrait faire la même chose. CodiMD/Hedgedoc pour rédiger et dodoc pour la capture et la gestion des médias. Les médias peuvent être directement importés par glissé/déposé dans un fichier MD.
Je suis incapable de mesurer le travail pour une intégration du MD. Est-ce juste une option de Quill ? Ou faut-il rajouter beaucoup d’éléments extérieurs à maintenir par la suite ?

Et sur la question de l’interopérabilité, je trouve au contraire que dodoc est assez exemplaire :

  • Tous les fichiers médias sont dans des formats standards ouverts.
  • possibilité de déposer dans un projet tous types de fichiers (exemple : fichiers propriétaires de la découpe laser).
  • possibilité d’interfacer le dossier dodoc2 avec d’autres logiciels.
  • toutes les métadonnées des fichiers auteurs / publications / projets sont en .txt
  • publications exportables en format pdf, html et png.

Hello,

je suis preneur également d’un générateur MarkDown. Je vais entamer une formation MIT Fablab et avoir un fichier Markdown va pouvoir accélerer le process de documentation vers le MIT.

Pour info, au fablab , nous l’exploitons de plus en plus et c’est vraiment utile, pratique et rapide

Encore un grand merci pour ce logiciel