à vrai dire il n’est pas prévu de reprendre la fonctionnalité Discussion pour le moment dans la v10.
Celle-ci a été développée hâtivement au début du premier confinement pour permettre aux usagers de la version en ligne de communiquer facilement en parallèle d’un travail de groupe.
Dans la v10 il pourrait être intéressant de penser plutôt une fonctionnalité type « commentaire » sur les publications ou les projets, et qui puisse être faits par des auteurs non-contributeurs (« je n’ai pas bien compris vos explications », « merci pour le partage de ce tutoriel », etc.). Mais tout ça n’est pas à l’ordre du jour des développement en cours, et quand ça le sera le sujet sera abordé sur le forum d’abord
Merci pour le retour en tout cas, je comprends bien le soucis. Vu que la v10 est loin d’être prête, on pourrait imaginer une dernière version 9 (je sais que @julien l’a déjà évoqué) qui permettrait de couper ce mode là si c’est vraiment gênant.
Merci pour ce retour !
J’imagine que votre priorité c’est la V10, pas de développer la V9, donc ne changez pas les plans suite à ma demande… ou alors sauf si la V10 a besoin de bcp de temps pour arriver (pas prête avant la rentrée 2023 par exemple). Dans ce cas, et si je ne suis pas le seul à porter la demande d’évolution… pourquoi pas !
Merci encore !
Matthieu
petit point d’avancement avec des captures d’écran – le système de mot de passe général et d’identification par compte est pas tout à fait opérationnel. Je n’ai pas mis à jour la page de test.
Je pense pouvoir mettre en ligne en début de semaine prochaine voir un peu avant.
Page d’accueil revue avec :
la possibilité de s’inscrire en haut de l’écran,
l’indication de langue et la possibilité de traduction en haut à droite (à voir s’il est possible de rédiger le titre et la présentation pour chaque langue (?))
le logo, le titre, et la présentation de l’instance
En cliquant sur le bouton « réglages » et en étant identifié avec un compte qui est admin une fenêtre modale s’ouvre :
édition du titre, de la présentation, du mail de contact et du logo de l’instance (utilisé comme favicon dans la barre d’onglet, et comme picto sur l’écran d’accueil d’un smartphone qui aurait ajouté un lien web comme raccourci sur son android/iphone)
En cliquant sur les petits i pour avoir une explication de chaque champ (l’idée est de trouver des manières d’intégrer des explications directement dans l’interface, pour éviter d’avoir à aller consulter la doc en permanence).
Onglet stockage, pour régler l’emplacement du stockage. J’ai hésité pas mal à en faire la première chose à régler à l’installation du dodoc, mais ça me semble être plutôt à ranger dans la catégorie « réglages avancées », ça me semble pas pertinent que le premier lancement de dodoc pose cette question avant même d’avoir vu comment ça marche. Je propose donc : Documents par défaut, avec la possibilité de sélectionner n’importe quel autre dossier en étant admin et depuis ce menu.
À noter aussi que ce réglage est uniquement possible sur la version « appli », depuis l’appli et pas depuis un appareil connecté à l’appli car il faut pouvoir naviguer dans l’ordinateur et récupérer le chemin sélectionné (pas possible pour des raisons de protection de donnée depuis un navigateur web).
Après un clic sur « afficher les projets », page des projets si l’instance de dodoc est protégée par un mot de passe et qu’on ne l’a pas encore entré.
Ma proposition ici est qu’une instance protégée par un mot de passe donne quand même accès à la page d’accueil pour pouvoir lire la présentation de l’instance, et avoir les infos pour contacter les admins par mail si on souhaite obtenir le mot de passe.
Les choses se mettent en place et les premiers visuels donnent une bonne idée de la suite.
Première question : Est-ce que le dossier de stockage pourrait être un dossier en ligne par exemple sur un Nextcloud ?
N’importe quel dossier dans n’importe quelle partition ou disque de l’ordinateur qui a lancé l’appli dodoc, donc j’imagine que oui.
La nuance étant que si ce dossier est utilisé par deux machines et deux dodoc à distance, les modifications de l’un ne serait pas répercutées en direct sur l’autre (car pas de surveillance des dossiers/fichiers par dodoc). Ce serait possible de surveiller les modifications de dossiers/fichiers avec qqchose comme GitHub - paulmillr/chokidar: Minimal and efficient cross-platform file watching library mais il faudrait prendre le temps de bien tester l’impact sur les performances, faire attention à ne pas détecter les changements provenant du dodoc local, etc.
Sur un serveur en ligne, il est possible d’utiliser un autre volume sans problème. En l’occurrence c’est ce que je fais sur https://164.92.187.49:8080/ : un serveur VPS avec 1 cpu et 1gb de RAM pour faire tourner dodoc, et une autre partition « block storage » de 10gb pour le stockage.
À vrai dire le mieux serait que j’exporte bientôt des versions à installer pour rapidement voir si ça tourne et comment – peut-être une des prochaines étapes après la finalisation des mots de passe et inscription contributeur.
Donc, la feuille de route serait :
finalisation inscription contributeur et mdp général
release + export de versions .dmg .appimage .exe
rétablissement des modes de capture (stopmotion en particulier)
la création d’auteurs (on peux choisir le rôle, à terme je pense qu’on ne pourra pas choisir d’être admin mais juste le devenir grâce à un admin existant). La modification, la suppression de son compte, etc.
si on est identifié en tant qu’admin, pouvoir modifier les règlages de l’instance (mots de passes, présentation, adresse mail de contact, etc.)
la sélection du chemin de stockage des contenus (dans la version application)
Je vais fabriquer des versions applis à tester sur les différentes plate-formes, pour valider que tout fonctionne bien – comme il s’agit d’une réécriture complète qui utilise par endroit d’autres dépendances il peut y avoir des surprises !
J’ai fait un premier tour, je testerai plus en détail dans les prochains jours.
Ça pourrait-être pratique de pouvoir basculer dans la vue « non identifié » pour voir ce que les autres personnes ont comme affichage sans forcement se déconnecter / reconnecter à chaque fois.
Par exemple avec un petit bouton à cocher à côté du nom d’auteur.
Je trouvais ça très pratique sur la version de test juste avant celle ci, on cochait / décochait la case en haut à droite et on voyait directement le résultat pour les autres personnes.
bonjour à tous
petit mot rapide: grand bravo pour cette motivation et ce travail collaboratif, hâte de mettre en place au sein du fablab #madeiniki
jean-philippe
Ok, tu peux en faire une issue taggée dodoc 10 sur github ? Merci !
Merci @jp.clerc N’hésite pas à faire un tour ici de temps en temps pour tester et donner ton avis par rapport à ton expérience et tes besoins/envies !
Une petite question pendant la finalisation de la gestion des autorisations :
dans un projet, les publications et remix possèdent-ils des auteurs propres ? Est-ce que ça a bien du sens de pouvoir leur donner des auteurs différents du projet qui les contient ? Le scénario suivant semble-t’il logique / attendu : un projet collaboratif qui contient des médias importés/capturés par un groupe (une classe) contenant une variété de publications créés seulement par quelque personnes et qui ne peuvent être modifiées/supprimées que par ces personnes ? Si oui, à la création d’une publication ou d’un remix on attribue comme auteurs tous les auteurs du projet, par défaut, avec la possibilité de modifier ça ?
Et il ne sera pas possible de sélectionner des auteurs qui ne sont pas aussi auteurs du projets, car on se retrouvera coincé pour importer des nouveaux médias dans sa publication. Logique aussi ?
un auteur peut-il se retirer de la liste des auteurs d’un projet, et, le cas échéant, un projet peut-il n’appartenir à aucun auteurs ? Si oui, quel est le comportement le plus désirable :
le projet n’est plus éditable (modification des métadonnées, capture, importation, création de publication, etc.) par personne sauf les admins du dodoc
Le risque de permettre une gestion des droits trop précise serait de compliquer la gestion et l’usage du mode collaboratif de dodoc.
Si un auteur se connecte à dodoc, il crée un projet et peut attribuer des droits à d’autres personnes qui pourront participer à ce projet. Les autres personnes seront aussi identifiées et pourront ajouter/modifier/supprimer des médias dans le projet. Chaque média possède un auteur, par défaut celui qui l’importe ou le capture mais c’est plus comme un mot clé, pas un système de droit de modifier ou d’y accéder. Tous les auteurs du projet ont les mêmes droits dans le projet.
Je pense que les remix doivent être sur le même modèle qu’un média puisque qu’on produit un nouveau média et qu’on est déjà autorisé à produire/modifier/supprimer des médias dans le projet. Donc un remix est identifié par défaut avec simplement UN nom d’auteur, celui qui est identifié sur dodoc avec possibilité d’ajouter des co-auteur.
Créer un remix revient à capturer / modifier un média = > un auteur par défaut qui est repris dans le nouveau média créé par le remix.
Par contre une publication est plus une production collective utilisant plusieurs médias et du contenu rassemblés par les différents auteurs du projet. Donc je pense qu’on peut ajouter par défaut l’ensemble des auteurs du projet comme auteurs de la publication avec la possibilité de modifier.
Et contrairement à la version actuelle de dodoc, la création d’une publication ne demande pas (comme pour une recette dodoc 9) qui peut contribuer/voir car la publication est directement liée au projet. Donc la publication n’est modifiable QUE par les contributeurs ayant les droits de modifier le projet et est visible par TOUS si le projet est « Public ».
Un auteur peut se retirer d’un projet mais un projet ne peut pas être orphelin. Donc s’il ne reste qu’un auteur il reste obligatoirement auteur du projet.
Idem pour les médias / remix / publication.
Chaque personne qui souhaite contribuer est identifiée et toute contribution est identifiée par au moins un auteur.
Rien n’empêche d’avoir un seul compte commun pour toute une classe par exemple sur un dodoc en local si on ne souhaite pas identifier chaque participant. Tous les élèves auront les mêmes droits sur tous les projets avec le même compte « classe »
Bonjour @louis
Je rejoins @julien sur le nécessité de garder l’ensemble aussi simple à utiliser qu’actuellement, au moins dans la version locale. Le côté « plug and play » du do.doc actuel rassure les enseignants pas forcement très habiles avec le numérique. S’il faut forcément jouer avec des droits d’accès, de lecture, d’écriture… avant d’utiliser, ça va les freiner. Pour la version locale, créer « anonymement » est un confort apprécié.
Sinon, je pense qu’un projet orphelin, à minima, ne doit pas pouvoir être publié… La désinscription du dernier contributeur pourrait être possible en acceptant de supprimer le projet ?
Matthieu
Ps : et la dernière version de test est vraiment sympa, on arrive mieux à se projeter.
C’est sans doute trop tôt pour faire remonter ce type de détails : je trouve les boutons/icônes parfois trop petites pour une utilisation avec tablettes (je n’imagine pas avec Smartphone, pas testé).
Je suis en train de tester la version… test. Je vois que depuis hier, l’import fonctionne mieux! J’apprécie que les fichiers .stl montrent une miniature. Par contre, pour l’instant, il faut cliquer sur le fichier pour voir à quoi correspondent les fichiers .hex (code Microbit) ou .mp3. Il y aura moyen d’avoir le nom et l’extension du fichier directement dans la fenêtre de médias sans avoir à cliquer sur le fichier? Autre petit truc qu’il n’y a pas sur la V9 et qui m’aurait bien aidé en classe : trier les publications par date/heure de dernière modification.
Bon travail en tout cas. J’essaierai de jeter un oeil pour tester régulièrement.
Ah si, un p’tit truc qui m’embêtait sur Wordpress et que je retrouve ici : quand on tape un tiret, dans un bloc de texte, il est automatiquement transformé en puce « point », qu’on peut changer en numéro. Il n’y aurait pas moyen de garder ça en tiret par défaut, de désactiver la mise en forme automatique? Je pense aux enfants qui tapent un texte avec des dialogues et s’arrachent les cheveux parce que l’ordinateur leur transforme ça en point automatiquement. C’est un peu la galère de retrouver de bons vieux tirets, même si c’est possible en jouant avec la suppression ou le CRTL+Z.
Je suis d’accord. Partons sur des permissions les plus simples possibles, au niveau des projets, et nous verrons bien si ça fonctionne pour tout le monde.
À voir oui, ça paraît pas mal. Mais je m’interroge quand même sur la possibilité d’avoir un projet sans auteur, qui pourrait servir de boîte de dépot partagée de documents, sans avoir à se soucier de la liste des contributeurs. Si on a par exemple des participants/élèves pas encore inscrits, il faut attendre qu’ils créent leur compte pour pouvoir les ajouter comme contributeurs à un projet. Avec un projet « ouvert » on pourrait leur communiquer l’url du projet et ne pas avoir à gérer cette question. On pourrait même imaginer qu’avoir un compte auteur n’est pas nécessaire pour éditer ce projet (ce qui va à l’encontre de ce que j’imaginais quelques postes plus haut) et permettrait de retrouver un fonctionnement sans auteurs, complètement anonyme. Et sans rajouter de complexité je pense, si c’est bien présenté/expliqué dans l’interface.
Qu’en pensez-vous ?
Hello Yves ! Oui, c’est un bug, merci de l’avoir fait remonter. Je viens de le résoudre, ça fera parti des modifications apportées dès la prochaine mise à jour en ligne.
Tout à fait envisageable oui. Je pense qu’elles seront organisées par date de création, par défaut (comme les projets, et comme les fichiers), mais on pourra demander un autre tri.
Oui, c’est le comportement par défaut et admis pour les éditeurs de texte (celui de ce forum fait aussi ça…). Dans l’idéal il me semble qu’un dialogue utilise un tiret cadratin (– et pas -), mais pas simple à faire sur un clavier… ça donne ça :
– Bonjour
– Hello
J’ai peur que changer le comportement par défaut pose problème à pas mal d’utilisateurs, c’est souvent une mauvaise idée de modifier des conventions de ce type. Je n’ai pas de solutions simples à te proposer
Je trouve aussi que c’est une mauvaise idée de contourner une utilisation classique pour un cas particulier, sachant qu’en plus ce n’est pas le bon caractère à utiliser.
Voir ici : Tiret — Wikipédia
On peut utiliser deux solutions plus simples à mon goût :
_ soit utiliser le tiret bas _ qui ne convient pas exactement mais reste très simple à saisir au clavier. Et ce n’est pas pire que d’utiliser un signe de soustraction à la place.
Soit on peut copier/coller le bon tiret pour les dialogues à partir d’un fichier modèle de dialogue qu’on garde sous la main. Au moins on utilise le bon caractère et un copier/coller s’utilise assez facilement, je le fais toujours pour taper « do•doc » sur un ordi windows par exemple.
— Merci, monsieur.
— De rien !
En effet, j’arrive à faire le tiret cadratin sur mon Mac ou sur un PC avec clavier numérique, mais sans pavé numérique, je n’ai pas réussi… Bon, ce n’est pas un grave problème, ça ne remet pas en cause la V10!
Le risque c’est de retomber sur un simple visiteur qui aurait accès à tous les projets ouverts du dodoc.
J’utilise aussi assez souvent dodoc comme espace de partage en anonyme et ponctuel avec des personnes qui n’ont pas d’intérêt à créer un compte pour une seule journée ou un seul fichier à échanger. Par exemple avec un projet sur mon dodoc local en partage sur le même wifi pour une journée de formation. Une fois que je repars plus personne n’y accède mais c’était juste pour le temps d’une journée en présence.
Je pensais donc pour continuer ce type d’usage à créer un compte standard anonyme. Par exemple avec ID : dodoc / MdP : dodoc
Il suffirait alors de créer le projet et d’ajouter l’utilisateur « dodoc » comme contributeur au projet. Tout le monde se connecte avec l’url/code QR et s’identifie avec dodoc / dodoc dans la fenêtre de connexion.
Une autre solution serait de permettre de créer un projet « ouvert » et de transférer ce lien URL ou code QR mais que les personnes ne puissent pas raccourcir l’URL pour remonter l’arborescence de dodoc. Par exemple je partage : " https://test.dodoc.fr/test-bug-export-pdf " , mais si quelqu’un de non connecté saisi https://test.dodoc.fr/
il n’accède pas à la partie contribution de dodoc, et la vue des autres projets « ouverts » n’est pas accessible aux non connectés. Seule l’URL directe permet de partager un projet « ouvert ».
On aurait le même fonctionnement que sur Nextcloud par exemple.
On partage le lien d’un dossier partagé en modification à l’aide d’un lien mais on ne peut pas remonter dans l’arborescence des dossiers du Nextcloud.
Je sais faire les caractères spéciaux depuis mon linux mais je n’y arrive jamais sur win
C’est pour ça que le copier/coller depuis un autre fichier modèle peut aussi permettre de contourner le problème.
ça demande de bien maîtriser dodoc, et d’expliquer la brique « contributeurs » avant d’expliquer/faire tester les autres
si qqun supprime ce compte, ou le retire des contributeurs alors tout le monde est déconnecté.
Hmm techniquement pas simple, j’aime bien l’idée mais c’est pas compatible avec le socle… Et pas évident non plus à expliquer/utiliser.
Mais avec les projets non-publics on pourra de facto créer des projets qui ne seront accessibles qu’à leurs contributeurs et aux gens qui ont l’url, mais pas visibles sur la home. Si on met en place les projets « sans contributeurs », alors on peut imaginer quelqu’un qui créer un projet non public, sans contributeur, ce qui va créer une boite de dépot uniquement accessible aux personnes qui ont l’URL. Plutôt intéressant non ?
D’ailleurs je me demande si plutôt que de parler de « public » il ne faudrait pas inverser et parler de « invisible » ? Par défaut décoché.
