Interopérabilité de do•doc

Idées
1

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…

2

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:

3

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 ».

image
image1028×640 139 KB

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.
4

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

5

Ok.
Est-ce qu’une solution qui pourrait convenir serait de pouvoir exporter en markdown un récit ?

Par exemple ici :

image
image1652×1652 276 KB

Quand on clique sur CRÉER :

image
image1398×1774 337 KB

Et en choisissant Markdown :

image
image884×374 25 KB

Il faudrait clarifier concrètement comment intégrer chaque type de média (images, vidéos, audio, fichiers STL, PDF, ou autre) mais ça peut s’envisager. Pas mal de boulot cela dit.

L’exemple codepen suivant montre que le HTML de Quill peut être transformé en MD :

(écrire dans le bloc texte en haut, scroller en bas de page pour voir le MD qui correspond).

Qu’en pensez-vous ?

1 « J'aime »
6

cette proposition à l’air interessante :wink:

7

Cette proposition semble bien répondre à la question de l’interopérabilité. On pourrait exporter une publication classique de dodoc dans un nouveau format supplémentaire.
En voyant la capture d’écran de l’export en MD je comprends que ça ce passe comme l’export HTML avec une archive contenant les dossiers médias et un fichier MD. Je ne connais aucun éditeur MD à part HedgeDoc, savez-vous comment un autre Editeur MD ouvrirait ce type d’archive ?
Est-ce qu’on pourrait l’ouvrir avec autre chose que dodoc, modifier le contenu et revenir dans dodoc pour ajouter d’autres médias par exemple.

Si on peut passer de dodoc à un autre éditeur et revenir continuer dans dodoc ce serait une vraie interopérabilité, mais cet exemple correspond plus à un export de type archive et pas vraiment à un document de travail qu’on peut ouvrir et modifier à la volé dans l’un ou l’autre logiciel comme on le ferait avec un fichier en .ODT par exemple.
Est-ce que les utilisateurs concernés par le MD ne vont pas se tourner directement vers un éditeur en MD. Les utilisateurs qui utilisent le MD dans mon entourage l’utilisent pour la rapidité de saisir du texte en utilisant quelques balises. Je ne suis pas certains que l’utilisation d’un éditeur comme Quill correspondent à leur utilisation même si l’export en MD était possible.

Sinon serait -il possible de basculer l’éditeur de Quill pour faire de la saisie directement en MD ? Mais ça reviendrait à copier HedgeDoc…

8

Je connais cryptpad et Hackmd
https://cryptpad.fr/

et il est possible d’écrire en markdown sur observable et aussi via une app sur nextcloud Markdown Editor - Apps - App Store - Nextcloud

j’aime bien l’interopérabilité