do•doc 12 est sortie en octobre, en même temps que démarrait le travail sur la version 13.
Voici un petit point d’étape pour vous présenter le travail en cours, et pour expliquer la direction que ça prends
Ce chantier se fait en parallèle de plusieurs projets avec des partenaires qui financent son développement, ce qui nous permet d’y passer du temps (merci à eux !).
Les projets qui accompagnent la v13
dans le cadre de l’Appel à communs des tiers-lieux, création avec le collectif A3 de fonctionnalités permettant la création d’un format de documentation type poster A3, avec une logique d’organisation de contenus texte+images en grille.
dans le cadre de la création d’une plate-forme de documentation pour Atelier LUMA, reprise de certaines fonctionnalités de publication PDF pour simplifier leur utilisation et création d’un système de mise à jour automatique des différentes versions (déploiement avec docker, pour la partie technique). Maintenance du tronc commun (le code server, les composants agnostiques).
en lien avec le projet européen Slash qui avait permis de créer un première base pour la publication multisupport, expérimentation dans un autre outil/plate-forme de composants d’interface qui seront (peut-être) rapatriés vers dodoc. Maintenance du tronc commun (le code server, les composants agnostiques).
Encore merci à ces projets d’aider au développement continu et non-interrompu de nos outils, en nous permettant de consacrer du temps à la fois à la partie serveur (commune à tous) ainsi qu’à la partie interface, spécifique à chaque outil (que nous vous présenterons bientôt !).
Évolution de dodoc 13
Voici la liste des changements déjà réalisés (disponibles sur la branche next, donc) :
Principales évolutions
Multisupport (édition multi-supports)
Refonte de l’édition : grilles par zone, chaînes de blocs (avec lignes SVG pour les indiquer), gestion des médias en grille, import d’images en grille, affichage des débordements, adaptation des médias dans les cellules, identifiant de zone par cellule. Amélioration du rendu HTML/CSS en multisupport, injection de @page dans le CSS personnalisé. Correction des blocs chaînés, du tri des grilles, des médias déjà présents et de la compatibilité avec les anciennes grilles.
Intégration de PDF et contenus embarqués
Intégration des PDF dans le multisupport, taille « full » pour les médias, raccourcis CSC pour gérer les cas limites. Les publications exportées en page web n’incluent plus de fichiers JS inutiles.
Discussions
Panneau de discussion (activé par défaut), possibilité de le lier aux projets affiché dans le panneau, correction du compteur de messages non lus et du défilement vers le dernier message. Amélioration de l’interface (édition des messages, hauteur des nouveaux messages).
Optimisation et traitement des médias
Optimisation en lot (batch) des médias, champ $processing pour enregistrer les modifications réalisées (recadrage, etc.). Indicateur « redimensionné » sur les médias. Option de flou ciblé sur les médias (pour masquer des visages, par exemple).
Éditeur de texte
Nouvel éditeur de texte optimisé, contenu non éditable par défaut avec focus au passage en mode édition, confirmation avant fermeture pour continuer à éditer. Aide au markdown (snippets, explications pour l’embedding de médias). Saut de ligne dédié pour insérer des médias.
Publications et navigation
Filtres et tri pour espaces, publications et projets (sauvegardés dans le navigateur), vue liste des publications, mode d’affichage mémorisé. Zoom avec Ctrl/Cmd + molette, navigation type « infinite-viewer » commune pour les publications, bouton d’accueil affiché seulement quand on s’éloigne du contenu. Réorganisation par glisser-déposer dans les mosaïques de médias pour définir la répartition visuelle.
Import et ressources
Sélecteur de ressources libres en ligne, import de tout type de fichier depuis un site de référence (sélection faite à la main, en cours).
Projets et dossiers
Option pour ajouter un groupe entier en un clic (admin/contributeurs). Pouvoir personnaliser les panneaux affichés dans un projet – choisir ceux qui sont utiles ou non selon le projet (affichage pour tous les référents/contributeurs d’un projet).
Liste de tâches
Dans chaque projet, possibilité de créer un ou plusieurs listes de tâches à faire. Chaque liste peut contenir jusqu’à plusieurs milliers d’éléments, qui peuvent être cochés/dupliqués/supprimés. Quand ils sont cochés, la date est enregistrée et ils passent en bas de la page, en grisé. Chaque élément peut contenir une note en lien (champ texte collaboratif).
Corbeille
Suppression définitive des dossiers et fichiers de la corbeille après 30 jours, avec un message d’information.
Sécurité et technique
Support Docker (fichiers et configuration). Détection des settings.json mal formés, politique de sécurité « same-site », vérification de la version de Node au démarrage. Logique de sortie de l’application améliorée, logs et préchargement corrigés. Mise à jour d’Electron (39.5.2) et des dépendances. Composants lourds (AuthorPicker, PositionPicker) chargés à la demande pour alléger le chargement initial.
Corrections et ajustements
Bugs corrigés
Reprise champ et affichage de la licence ; masquage de « rendre la publication publique » sans mot de passe général ; recherche (normalisation) qui pouvait faire planter ; type de zone correct pour les éléments d’une chaîne ; compteur de messages non lus (sujets non accessibles pas comptés) ; invalidation des autres connexions à un compte au changement de mot de passe ; résolution de couverture limitée à 320 en petit ; liaison du projet au chat ; et pleins d’autres que je n’ai pas listé.
Traductions et contenu
Traductions manquantes, désactivation de la langue « fon », titre de page dynamique en fonction de la langue (dans l’onglet).
Dépendances et build
Mise à jour des dépendances (Electron, Puppeteer, etc.), suppression de paquets inutilisés (pad-left, scena guides), cache-busting de build.js, correction des exclusions du builder et des deps Electron.
Divers
Nettoyage de code inutilisé, composants supprimés ou simplifiés, correction d’import manquant, version Node mise à jour, permissions et README Docker.
Généré à partir des commits sur la branche next qui ne sont pas dans main.
Bonjour,
Merci pour ce journal de bord !
J’avais raté plein de choses.
Petite question sur les panneaux : est-ce qu’on peut paramétrer l’affichage par défaut des panneaux de manière générale pour l’instance (par exemple ne pas afficher “discussions” ou “tâches” et l’afficher si besoin sur un projet en particulier ?)
Je trouvais la sobriété Capter / Collecter / Fabriquer / Publier assez efficace. J’ai peur qu’on perde la logique des étapes pour arriver à la publication. Mais ce n’est que mon avis.
Les publications multi-supports et les bibliothèques de ressources libres sont très intéressantes.
Discussion n’est dispo/visible que si l’instance active la discussion (actif par défaut). Tâches est toujours visible par défaut effectivement.
Une autre approche possible serait que tâche et discussion n’apparaissent que s’il y a du contenu dedans (si la fonctionnalité n’est pas utilisée (0 listes de tâches, 0 discussion lié au projet, 0 recettes dans fabriques), on pourrait ne pas l’afficher). Mais du coup je ne sais pas trop comment donner accès à cette fonctionnalité de manière intuitive si le nom du panneau n’apparait pas, on risque de passer à côté systématiquement. Je comprends bien la problématique de ne pas complexifier l’interface pour des utilisateurs qui n’ont pas besoin de ces modes là… Je mets @maxime-gi dans la boucle, il aura peut-être des idées.
En effet la problématique de l’accumulation de panneaux se pose. Pour palier à cela l’idée serait de pouvoir choisir lesquels apparaissent en fonction des besoins.
Pourquoi pas proposer ce choix dès la création du Projet dans la fenêtre modale dans laquelle on choisit son titre, choix qui reste modifiable après la création du Projet. L’enjeu est alors de faire comprendre que l’on peut enlever/rajouter des panneaux à tout moment.
Pour ne pas manquer cette information, je pense qu’un pictogramme pourrait apparaître à côté des panneaux traditionnels et faire office de paramètres. On ne peut pas le manquer à cet endroit. Celui que j’ai redessiné en partant de Bootstrap n’est peut-être pas encore le bon :
La fenêtre modale qui s’ouvre en cliquant sur le pictogramme
La question de l’ordre des panneaux se pose aussi. Celui des versions précédents la version 13 suggère effectivement une manière efficace de travailler. Faut-il mettre Tâches et Discussions (si le chat est activé dans l’instance) au début ou à la fin plutôt qu’au milieu ?
En tout cas, il vaut sûrement mieux toujours laisser le choix des panneaux à afficher plutôt que l’interdire depuis l’instance (ce qui est déjà plus ou moins possible avec le chat).
Pour être plus clair.
Je trouve que Tâches est une bonne idée pour organiser un projet.
Je pense qu’il faut afficher par défaut les éléments Capter / Collecter / Fabriquer / Diffuser
C’est juste l’emplacement de Tâches et Discussion dans de menu qui sont intercalés dans le flux pour produire de la documentation. Je le verrais plus comme des outils en parallèle de cette chaine.
Je trouvais l’idée de mettre la discussion dans un autre panneau assez bonne.
Suite à tes retours @julien et quelques tests, on tente des changements à ce niveau là :
sortir ces 2 fonctionnalités des 4 principales, pour les caler à droite.
la couleur de la todo est maintenant le noir/gris foncé pour éviter la confusion avec le bleu marine des fabrications
les pictos pour avoir plusieurs panneaux simultanés sont plus visibles et faciles à cliquer
il est plus facile de changer la taille d’un panneau par rapport à l’autre (s’affiche quand on a plusieurs panneaux actifs, s’applique aussi dans la publicaiton multisupport et carto).
Je trouve ça plus clair, c’est beau !
Super idée pour les gros + qui incitent à cliquer pour ajouter les panneaux.
Maintenant que tout est plus gros et lisible, je propose de grossir un peu (ou dans un bouton ?) la flèche tout à gauche dans le bandeau pour remonter sur le projet. Elle semble un peu différente du reste.
Très bien aussi pour le curseur pour glisser la séparation, c’est beaucoup plus facile trouver.
Merci
je n’ai rien changé là-dessus, la v13 a pas spécialement besoin de plus de RAM que la v12 pour tourner (c’est étrange, ça fait 2 ans que le fichier de config spécifique à la version yunohost indique qu’il faut 1go de RAM pour l’installation de do•doc…).
EDIT : après je suis très étonné des prix que tu m’annonces, les VPS les moins chers aujourd’hui fournissent souvent 1, 2 ou 4go de RAM pour 5 à 10 euros par mois. Ça serait pas du luxe d’avoir plus de RAM, notamment pour l’export PDF ou la création de vidéos.
Oui je ne sais pas trop comment ca marche car dodoc est déjà installé. Il calcul avec la ram encore dispo et fais comme si j’allais installer un autre dodoc. Je met une issue sur le git du paquet.
Pour les prix, je suis déjà à 10€ /mois pour 4Go de ram mais c’est que sur mon serveur j’ai ( ou 6 wiki, un nextcloud… Donc en fait le tout est vite à l’étroi.
C’est les prix d’OVH il faudrait que je regarde si je peux pas avoir mieux ailleurs. En fait là je suis à me demander si j’aurai pas intérêt à avoir dodoc sur un serveur indépendant du reste ca me ferait 15 à 20€/ mois au lieu de 35€.
Chez OVH ils ont des offres avec de très grosses marches. Si je veux passer au VPS supérieur c’est passer de 4 à 16go de ram et le stockage de 70 à je sais plus trop combien.
Je viens de voir que les règles de visible/masqué ont changé.
AVANT : si je sélectionne « Privé » pour un espace ou un projet et que je sélectionne contributeurs « Tous » on pouvait partager le lien pour que les personnes contribuent mais c’était bien masqué à l’affichage dans dodoc pour les autres.
MAINTENANT : si je sélectionne « Privé » et « Tous » en contribution, l’espace ou le projet sont visibles par tout le monde.
Je sais qu’on a souvent discuté des ces règles d’accès mais je ne sais plus si ce changement était prévu.
effectivement, c’est une régréssion introduite dans do•doc 13 en reprenant la logique de « privée » – qui signifie « limité aux contributeurs ». Si les contributeurs sont réglés à Tout le monde, ça serait une exception à cette règle de ne pas lister les espaces ou projets à des personnes qui peuvent y contribuer.
Ce que tu décris me semble mieux correspondre à « non listé », c’est à dire un dossier qui n’apparait pas avec les autres depuis sont parent. On y accède que depuis son URL. C’est bien ça qu’il te faut ?
Oui c’est bien un projet ou un espace « masqué / non listé » à l’affichage pour tous mais utilisable en contribution ouverte à tous quand on a le lien direct.
Ça évite d’ouvrir des comptes pour une utilisation ponctuelle.
Une option de contournement actuel serait de créer un compte utilisateur générique qu’on ajoute aux contributeurs et on donne l’ID/mot de passe à tout ceux qu’on veut inviter, mais ça complique pas mal l’accès que j’aimerais garder le plus simple possible.
Je te suis, c’est pratique de pouvoir faire ça et pas pratique de créer un compte « standard ».
Ça te va si à court terme on corrige la v13 avec ce comportement là ? Et on voit sur la 14 si y a quelque chose à changer ?
Oui si on peut remettre le comportement sur la V13 ça me facilitera les ateliers collectifs. Je sais que @laet_b l’utilise aussi beaucoup de cette façon.
Et on peut faire un tour des usages des autres utilisateurs pour voir si besoin de faire évoluer sur la V14.
Sortie d’une nouvelle version de do•doc, 13.0.43, qui résout un soucis identifié par @julien et quelques failles de sécurité dans des dépendances dans la version appli – si vous utilisez do•doc 13 (ou versions plus anciennes) en local je vous recommande chaudement de mettre à jour.
Petite mise à jour de https://dodoc.fr/ également, traduction en anglais et amélioration de la lisibilité du site.
