État des lieux de l'atelier et do•doc version 10

Bonjour,

une nouvelle version de do•doc est en préparation ! Il s’agit de la version 10, qui sera une refonte complète du code « serveur » (celui qui gère le stockage des contenus et les échanges entre les appareils connectés en même temps) et du code « client » (l’interface de do•doc, avec ses boutons, menus, options, etc.). Un gros gros chantier donc.

Pour rappel, il existe deux variantes de dodoc :

  1. une variante « application à installer sur un ordinateur » (trouvable sur l’atelier des chercheurs | do•doc)
  2. et une variante « hébergée en ligne » (à tester sur https://test.dodoc.fr/ par exemple).

Elles ont 95% de leur code en commun pour la partie serveur, et 100% pour la partie « client ». L’ensemble du code est libre et open-source et se trouve sur github.

État des lieux

Cette année marque aussi les 10 ans du collectif l’Atelier des chercheurs !

Nous avons démarré ce collectif avec l’animation d’ateliers périscolaires de design en école primaire en 2013 (plus d’infos ici) et c’est à l’occasion de ces ateliers que nous avons commencé à expérimenter des dispositifs de captation/documentation pensés pour et avec les élèves. L’équipe était constituée à l’époque de @pauline.gourlet, Juliette Mancini, Ferdinand Dervieux et moi-même, et notre premier prototype, La Publication des chercheurs, ressemblait à ça :

Et sur l’écran de l’ordinateur :

Après ces ateliers, Ferdinand et Juliette ont embrayé sur d’autres projets (Ferdinand dans la VR, Juliette en BD) et @sarah nous a rejoint !

Depuis ces premières expériences, nous avons continué à concevoir une myriade d’outils, le plus souvent des versions plus ou moins proches de do•doc et qui partagent le code « serveur » :

Petit aparté mais je (Louis) réalise d’ailleurs que ça en fait presque 1 par an depuis 2014 ! Pas de nouveaux outils prévu pour 2022 mais il faut dire que je viens d’avoir un enfant, et ça occupe au moins autant que la création d’un outil de l’atelier :slight_smile:

Ces outils sont le plus souvent le résultat de rencontres et de collaborations, souvent sous le format résidence, avec des partenaires divers et variés : associations culturelles, enseignants et classes de tous niveaux, fablabs et tiers lieux, collectifs d’artistes ou d’urbanistes, institutions publiques, etc. Parfois ils sont motivés par des besoins émergents de nos propres pratiques.

Les modalités de ce travail de conception et de développement nous ont beaucoup posé de questions. Par exemple quel statut juridique adopter avec quel modèle d’affaires ? quelles relations établir avec nos partenaires, sur quelles bases ?

Plusieurs éléments ont guidé notre réflexion. Nous tenions d’une part à ce que tout ce que nous produisions soit accessible librement et puisse être approprié / modifié par d’autres. D’autre part, nous n’imaginions pas décorréler le travail de conception et de développement d’un travail d’élaboration de connaissances partagées et au potentiel transformateur. Nous avons été attentifs depuis le début à ne pas limiter nos activités à la dimension de « design » ou aux seuls « produits/outils » que nous concevions, mais bien à développer une réflexion commune avec tous nos partenaires sur ce que l’élaboration d’instruments nouveaux implique tant sur les pratiques et les situations, que sur les formes d’organisation, la formation de valeurs et d’objectifs renouvelés, etc. Ce faisant et comme nous intervenions dans des milieux variés, nous avons cherché à ouvrir cette réflexion, à la mettre au travail, en fédérant une communauté autour de problématiques communes, dont nos outils étaient les reflets.

Finalement, nous sommes encore un collectif de fait et nous dessinons au cas par cas les modalités de collaboration avec nos partenaires. Bien que nous soyons mieux armés aujourd’hui pour savoir ce que nécessite un développement réussi, il est toujours difficile de faire valoir les activités de recherche et les temps d’accompagnement – surtout lorsque l’on travaille avec des personnes ou des organisations qui ont peu de moyens. Une autre difficulté tient au fait que malgré une diffusion du code source, je suis le seul contributeur effectif. Vu le nombre d’outils maintenus et d’interventions/formations qui nous sont demandées, nous cherchons des manières de faire contribuer de nouvelles personnes.

Au sein de l’atelier, ces dernières années, nous avons réparti nos responsabilités selon nos sensibilités et centres d’intérêts ainsi :

  • @pauline.gourlet pour la partie recherche et partenariats, mais aussi conception et tests/mises en situation des outils,
  • @sarah pour l’animation d’ateliers notamment en milieu scolaire, et aussi en soutien pour l’élaboration des outils
  • @louis pour le design, le développement et la maintenance des outils et l’animation d’ateliers

En parallèle de la conception de ces outils, @pauline.gourlet a soutenu en 2018 une thèse en ergonomie et design baptisée Montrer le faire, construire l’agir : une approche développementale de la conception mise en œuvre à l’école primaire. Elle s’appuie notamment sur un temps de résidence en classe de CP, qui a également été un temps précieux d’élaboration des principes qui structurent do•doc encore aujourd’hui.

Il y a environ 1 an, @sarah est partie dans le Vercors suivre une formation Cuisine du Terroir et @pauline.gourlet a démarré un post-doc au médialab de Sciences Po, ce qui a un peu changé la dynamique mais pas arrêté nos activités pour autant.

En ce qui me concerne, le développement des outils de l’atelier est devenue au fil du temps mon activité principale et j’adore toujours autant ça. L’économie qui est derrière reste un peu fragile, et il n’est pas toujours simple de dégager du temps pour de la maintenance ou pour gérer les retours « j’ai un bug » « comment ça s’installe » « j’arrive pas à faire ça » que l’on reçoit très régulièrement mais c’est une chance incroyable de pouvoir vivre de cette activité ! Nous espérons arriver à développer de réels communs numériques à partir de ce travail, il manque encore quelques étapes… notamment sur les aspects de gouvernance partagée.

Design et code, partie serveur

Les outils de la liste ci-dessus (sauf l’opendoc) sont basés sur le code « serveur » de do•doc. Cela nous permet de mutualiser le développement de manière à ce que les financements et contributions du code puissent bénéficier à l’ensemble des outils.

Par exemple, le développement de la fonctionnalité d’écriture collaborative temps réel (comme dans un Etherpad/Framapad) a été financée à la fois pour les Cahiers du Studio par le Studio-Théâtre de Vitry-sur-Seine, et pour Plateau, qui est développé avec Aurélien Tabard, du LIRIS (l’Université de Lyon 1).

La réécriture du code « serveur » est un chantier qui améliorera donc l’ensemble des outils – d’ailleurs cette réécriture se fait à la fois sur do•doc et Plateau, les financements provenant en particulier :

Cette réécriture est assez ambitieuse et il s’agit d’un travail de plusieurs mois déjà bien entamé, qui a les objectifs suivants (c’est assez technique mais j’ai essayé de vulgariser !) :

  • mettre à jour le code pour se conformer aux bonnes pratiques en cours, le code date par endroit de 2015 (!).

  • faciliter et inciter à la contribution par d’autres développeurs node.js au code, permettre la reprise par d’autres et que le développement dépende moins de ma disponibilité,

  • alléger la charge serveur, en réduisant la circulation des données au strict minimum entre les fonctions et en évitant que le processeur soit trop sollicité à chaque instant (particulièrement intéressant pour les version Raspberry Pi)

  • optimiser l’utilisation du cache pour accélérer le chargement de dodoc sans saturer la mémoire vive (utile aussi sur les petites configurations et la version en ligne)

  • réduire le poids des paquets qui transitent par le réseau en n’envoyant que les données visibles à un utilisateur qui consulte dodoc, ce qui améliorera grandement l’utilisation avec plusieurs dizaines voir centaines de contributeurs simultanés (concept de rooms avec socketio)

  • suivant l’architecture logicielle REST, pour fiabiliser l’envoi des données au serveur et facilitant l’interopérabilité avec d’autres services

  • en simplifiant la hiérarchie des contenus dans le dossier de stockage Documents/dodoc et en changeant le formatage des métadonnées pour suivre le standard TOML

  • en permettant de choisir n’importe quel dossier comme emplacement de stockage (ce qui permet par exemple de connecter nextcloud ou dropbox pour sauvegarder les contenus dans le cloud, ou de connecter un stockage plus conséquent et moins cher à un serveur dédié)

  • éviter les pertes de contenus texte en versionnant les modifications pour pouvoir revenir en arrière à chaque instant

  • mettre au point un système pour dissocier les tâches « légères » (gérer la mise à jour des contenus, la rédaction collaborative) des tâches « lourdes » (création de vidéos et de PDF) pour éviter que les secondes impactent les premières

  • revoir les outils de compilation de la version application pour Windows, macOS et Linux pour que ce soit plus robuste

  • développer des scripts d’installation et des images toute prête pour le Raspberry Pi,

  • stabiliser les procédures pour installer avec docker, une plateforme d’installation automatisée de services

  • faciliter l’installation de mises à jour depuis la version application (bouton « Rechercher des mises à jour » et proposer le téléchargement de ces versions à jour)

Il y a donc un très gros focus sur la simplification et la mise à jour de la syntaxe du code, la diminution de la consommation de ressources (côté processeur, mémoire vive et utilisation du réseau) et la facilité d’installation et de déploiement sur une variété d’appareils, de l’ordinateur dernier cri aux vieilles machines fond de classe présentes dans certaines écoles, en passant par des serveurs en ligne peu chers et des Raspberry Pi ou des NAS, par internet et hors ligne mais toujours collaboratif.

Design et code, partie client

Pour la partie « client » (ou interface graphique) les enjeux sont un peu moins précis mais il s’agit entre autre de revoir l’articulation projets/marmite/partage pour aller vers quelque chose de plus simple à prendre en main et de plus facile à consulter par des personnes non familières de dodoc. Le tout sans perdre de fonctionnalités présentes dans la 9e version : bibliothèque partagée de médias, capture de photos, vidéo avec effets, son, compilation de films, création de documents imprimables ou de pages web, etc.

Par exemple dans le cadre du projet Fablab à l’école, il faut que do•doc soit un espace de consultation de documentation par projet, et la vue projet de la version actuelle qui affiche l’ensemble des médias à tous les visiteurs n’est clairement pas adaptée. L’idée ici est de bien marquer la différence entre l’affichage « consultation » (simplifié, très lisible, avec principalement des contenus rédigés) et la vue « contribution » (plus brutes, avec davantage d’options visibles).

On avait déjà tenté quelques interfaces dans ce sens (par exemple https://fabriqueedu.tierslieuxedu.org/), mais il s’agit maintenant d’améliorer ces premières versions, notamment en jouant sur des gabarits d’export / de lecture.

La collaboration avec les lycées lors de la résidence évoquées ci-dessus amènera probablement aussi des fonctionnalités supplémentaires.

Enfin, il est aussi question de revoir l’interface dans la version « smartphone » pour que do•doc soit plus simple à utiliser depuis un écran de petite taille.

Prochaines étapes

Globalement la liste est bien bien chargée, et il y a de quoi faire pour les mois qui viennent ! En plus de nos contributions, il y aura probablement besoin de faire intervenir des personnes expertes sur certains sujets (potentiellement les scripts de déploiement, l’installation docker, et il y a aussi du travail sur l’interface de la recette mise en page qui mériterait d’être repensée).

Évidemment toutes les contributions sont les bienvenues :

  • sous la forme de retours rédigés, de préférence à la suite de ce post,
  • ou de croquis, ou de capture d’écran provenant d’autres outils, d’autres interfaces,
  • ou de contributions de code, en utilisant git

Des version alpha préliminaires arriveront prochainement, ce qui vous permettra de vous rendre compte des évolutions proposées et de les tester en situation.


À noter qu’il ne sera pas possible de récupérer des contenus produits sur la version 9 dans do•doc 10. C’est une conséquence malheureuse des modifications prévues – la dernière fois qu’une mise à jour non-rétrocompatible a eu lieu c’était lors du passage de la v6 à la v7 en 2018. Une fois stabilisé le nouveau format ne devrait plus bouger par la suite :slight_smile:

Concrètement, la version 10 créera un nouveau dossier Documents/dodoc pour y stocker ses contenus et aucun contenu ne sera écrasé ou récupéré de votre version 9 (une sauvegarde est néanmoins conseillée). Vous pourrez ensuite faire cohabiter 2 versions de dodoc sur la même machine pour pouvoir tester la version 10 tout en continuant à utiliser la version 9, si vous le souhaitez. N’hésitez pas à poster dans ce sujet si vous avez des questions – la documentation sera re-rédigée pour expliquer tout ça en détail.

À vous lire !

(rédigé à 4 mains avec Pauline)

3 « J'aime »

Merci beaucoup pour cet état des lieux très clair et motivant

1 « J'aime »

Merci pour ce débrief. très intéressant car il permet à la fois de saisir la genèse, la logique de fonctionnement du collectif, vos ambitions et les projets en devenir.
Pour ma part, je reste intéressé ( depuis fab 14 en 2018 déjà) pour poursuivre l’accompagnement de l’évolution de dodoc et le mettre à l’épreuve d’un usage intensif dans une classe de cycle 3 qui l’utilise pour construire des exposés, ou des cahiers de charges de projets « makers » entre autres.
Depuis l’année dernière et cette année encore, dodoc est utilisé pour favoriser le travail collaboratif de 6 classes que j’ai embarquées pour répondre ensemble à une problématique, soumise par une équipe de recherche du cnrs en écologie. Cette année encore, je m’intéresse à voir comment dodoc favorise cette coopération avec des collègues qui le découvraient pour l’occasion. Je cherche du temps pour faire un retour plus exhaustif sur le sujet s’il a des choses utiles à en tirer.
Je continue sinon à tester diverses manières de le faire découvrir et faciliter sa prise en main par les élèves pour un usage autonome à terme, idem dans le cadre d’une formation en direction de collègues prochainement à l’édulab Pasteur à Rennes, il est souvent intéressant d’avoir les retours à chaud de primo utilisateurs pour y voir des choses que l’on ne voit plus à force.
J’y trouve toujours des choses que j’aimerai moi aussi voir mises sur le haut de la liste des choses à faire évoluer, mais dodoc est devenu un programme absolument incontournable dans ma classe pour un usage autonome des élèves qui devient progressivement quasi quotidien et qui n’a pas d’équivalant pour accompagner et « ludifier » un travail visant à favoriser le gout de produire de l’écrit en classe; qui plus est un écrit qui a vocation à faire échanger, partager, documenter.

À bientôt,

Erwan @wanerspid

2 « J'aime »

Hate de mettre cela en production au fablab :wink:

Bonjour et merci pour vos retours @talaron @spiderwan @AnonSylDen !

J’ai mis à jour le post initial en mentionnant 2 autres projets qui participent au développement de cette v10 :

Merci à @spiderwan et @Cat_FacLab-Numixs :slight_smile:


Et sinon ça avance bien, la version appli tourne très bien et la version en ligne aussi. Ça arrive !

2 « J'aime »

Une après-midi à faire du stop motion avec un groupe de 15 enseignants sur do•doc… les retours sont unanimes et très positifs. Je remets ça demain après-midi avec un autre groupe.

Hâte de tester la nouvelle version !

1 « J'aime »

Bonjour !

Le temps a filé depuis l’ouverture de ce post, mais do•doc 10 a bien avancé depuis et il n’était pas très logique de vous partager l’avancement avant la mise en place des fonctionnalités de publication.

Voici donc une première vidéo de présentation de l’avancement, pour vous faire une idée de la direction que ça prends et avoir vos questions / retours :

J’ai essayé de faire court (mais 17 minutes déjà !), donc il manque des infos :

  • le stockage maintenant ressemble à ça :
    image
    pour le dossier de stockage


    pour le dossier d’un projet

    pour le dossier d’une publication
    Une publication est donc liée à un projet, et fait appel aux médias du projet. Déplacer un projet emmène aussi les publications.

  • ajout d’un système de versionnage du texte : les blocs textes collaboratifs gardent trace de leurs contenus, de manière à toujours pouvoir revenir en arrière si besoin :
    image
    image
    image
    L’enregistrement de versions se fait automatiquement par paquet de modification.


Tester en ligne

Pour aller tester par vous-même c’est ici : https://164.92.187.49:8080/

Si vous rencontrez un avertissement de sécurité, c’est normal (le site n’a pas de domaine et de certificat) et vous devriez pouvoir contourner ce message en cliquant sur « accéder quand même » ou équivalent.

Merci !

1 « J'aime »

Je reprends le message que j’ai posté dans le sujet de @Boris (Disparition de projet/importation d'un ancien export? - #7 par louis) ici :

L’idée est de proposer un écran d’accueil à la première ouverture, qui oblige à :

  1. choisir un emplacement pour le stockage du dossier des contenus, ou utiliser l’emplacement par défaut dans Mes Documents (ou utiliser un emplacement masqué, dans le disque dur, pour éviter que des projets protégés ne soient modifiés par des gens qui savent ou trouver le dossier des contenus ?)

  2. créer un compte auteur qui est admin, protégé par un mot de passe

Et en facultatif, qui propose :

  1. proposer de créer un mot de passe à l’ouverture (seuls les visiteurs munis de ce mdp peuvent consulter son contenu), utile aussi pour la version web pour controler l’accès par URL

  2. proposer de créer un mot de passer pour limiter la création de compte (exemple d’un dodoc public pour montrer la documentation mais éviter que les visiteurs puissent faire n’importe quoi). Ça pourrait aussi être de la modération sur la création de compte : un des admins doit valider l’inscription d’un nouveau compte par exemple.

Cet écran d’accueil sera accessible à tout moment pour modifier ces valeurs après coup.

Qu’en pensez-vous ?

1 « J'aime »

Avec mot de passe facultatif ? Ou prenant en compte l’enregistrement d’un mot de passe vide ?
Dans notre usage le plus fréquent (ici, dans notre appartement) nous n’avons pas besoin de mdp.
Par contre parfois on prépare le doc chez nous puis on ouvre le réseau sur place pour les participants afin qu’ils abreuvent la bête.
Donc peut-être un mot de passe au coup par coup, activable/désactivable à volonté ?

Oui toujours, sauf peut-être celui de le/les admin(s) potentiellement (vu tout ce qu’un admin peut faire). Ça te paraît bien ?

Rien n’empêche de modifier ces paramètres en cours de route et sécuriser le dodoc ponctuellement du coup. Le seul truc que je vois qui peut être laborieux, c’est si tu as plusieurs comptes auteurs sans mdp (par exemple, documentation sur un petit réseau local ou les gens se connaissent, pas besoin de mdp) et si tu souhaites ouvrir/déplacer le dispositif ailleurs pour montrer la doc. Il faudrait ajouter un mdp à chaque auteur à la main pour éviter que les gens s’identifient en tant qu’auteur sans mot de passe. Un admin peut éditer n’importe quel compte et lui ajouter/enlever son mot de passe.

Il faudra voir à l’usage si c’est pas trop compliqué à comprendre/utiliser. Et trouver les bons règlages par défaut, ceux qui marcheront pour la majorité des lieux. Peut-être prendre en compte la version. Je m’explique :

Pour la version application à installer
Scénario type fablab ou ordinateur fond de classe, fenêtre qui s’affiche au premier lancement (puis modifiable par la suite) :

  • création d’un admin avec mdp obligatoire
  • choix de l’emplacement de stockage par l’admin
  • mettre en retrait l’option demander un mot de passe pour consulter (désactivé par défaut, activable)
  • mettre en retrait l’option demander un mot de passe pour pouvoir créer un compte (désactivé par défaut, activable)
  • mettre en retrait l’option à la création d’un compte, un mot de passe est demandé (désactivé par défaut)

Version webapp (comme test.dodoc.fr)
Scénario type dodoc d’un établissement scolaire, ou pour un projet spécifique qui implique plusieurs classes dans plusieurs endroits, ou pour une association ou un collectif :

  • création d’un admin avec mdp obligatoire
  • pas de choix de l’emplacement (cela se règle au niveau de l’installation par le dev, qui connait son disque)
  • mise en avant de l’option demander un mot de passe pour consulter (désactivé par défaut, activable)
  • mise en avant de l’option demander un mot de passe pour s’inscrire et contribuer (désactivé par défaut, activable)
  • mise en avant de l’option à la création d’un compte, un mot de passe est demandé (activé par défaut, désactivable)

Ça paraît suffisamment souple ?

Une petite chose : je ne sais pas si il faut conserver la possibilité de rester anonyme dans la contribution/modification. L’idée pour le moment est plutôt de forcer à créer un compte avec un pseudo, comme pour ce forum par exemple, ce qui permet de mieux suivre qui fait quoi. Si besoin on peut toujours régler le dodoc pour pouvoir s’inscrire et s’identifier sans mot de passe.
Par contre, seuls les contributeurs pouvant modifier le projet, il faut que moi ou d’autres contributeurs ajoutent les comptes pour qu’ils puissent mettre du contenu. Donc le mode « open bar contributif dans un projet existant » n’est plus possible. Les nouveaux comptes pourront toujours créer leur propre projet, s’ils ne souhaitent pas attendre qu’on les ajoute à un projet existant pour pouvoir contribuer à la plate-forme. Ou utiliser un compte « par défaut » sans mot de passe, pour se faire passer pour qqun.

Désolé pour le pavé ! Vaste sujet :slight_smile: :sweat_smile:

@spiderwan @julien @sarah @pauline.gourlet @ypaubert @YonL votre avis ?

Cette gestion stricte par auteur identifié et mot de passe ne me parait pas trop contraignante et adaptables aux situations rencontrées. Cela a aussi une vertu pédagogique concernant la protection et le partage des contenus en direction des élèves avec des degrés de restriction ajustables par l’admin (selon le cadre et l’âge des usagers).

Par contre, je trouve qu’à terme un outil de gestion plus riche de l’historique des actions menées pour l’admin faciliterai la compréhension des erreurs de manip rencontrés ( qui quoi quand) et de pouvoir contrôler un retour en arrière vers un état précédent, mais cela risque d’être trop gourmand en espace de stockage. Pour le moment, j’avoue que le journal, lorsqu’il veut bien se générer ne m’aide pas toujours à capter un truc qui a pu se passer , une disparition de données par exemple.

Si un admin peut paramétrer à l’aide d’une fenêtre les règles de la plateforme et les modifier au besoin ça devrait vraiment simplifier le fonctionnement.

Je prends comme exemple mon usage.
En local sur ma machine c’est surtout en mode ouvert et anonyme pour faire des tests et démonstration de dodoc. Donc pas de mot de passe à l’entrée et les participants peuvent ou non se créer un compte auteur pour tester mais c’est toujours provisoire, ils n’ont pas d’occasion de se reconnecter sur mon dodoc local. J’ai seulement 1 compte auteur pour moi mais qui pourrait très bien être aussi l’admin… même s’il est préférable d’avoir un compte dans chaque mode pour les tests.
Idem en situation de formation ou d’événement : mon dodoc local sert de partage de fichiers sur le temps de la formation ou pour faire de la capture et recette vidéo sur un atelier stopmotion avec un groupe. Là encore un compte provisoire ou une connexion en invité suffit. C’est l’outil de partage ou de capture que l’on utilise sur un temps court et non la plateforme sur un temps long. Donc pas de compte auteur qui reste.

Pour le dodoc en local à l’Atelier : Pas non plus de mot de passe à l’entrée pour consulter puisque les personnes sont forcement sur place et déjà sur le même réseau wifi.
Par contre, pour contribuer sur les projets et garder une trace de qui fait quoi et qui peut modifier quoi, je demande de créer un compte auteur avec mot de passe. Pour cet usage j’aimerai bien avoir la fenêtre de paramétrage pour obliger la création d’un compte avec mot de passe.

Pour le dodoc sur le serveur de Réseau Canopé pour nos projets, nous avons pour le moment un mot de passe à l’entrée de la plateforme car on rentre directement sur la page des projets. Avec la version 10, l’idée est justement d’enlever le mot de passe à l’entrée de la plateforme pour avoir la possibilité de voir les projets et publications directement dans l’interface de dodoc en mode « publique ». Pour contribuer il n’y a pas de compte obligatoire mais il serait vraiment souhaitable. Donc la fenêtre de paramétrage pourrait aussi être très utile pour forcer la connexion avec une fenêtre d’identification Auteur / mot de passe dès que l’on clique sur s’identifier.

Dans les cas où l’on force une identification sur la plateforme on pourrait très bien imaginer qu’il existe un compte automatique du type Auteur : démo / Mot de passe : démo qui pourrait servir occasionnellement pour éviter la création d’un compte dans certains cas. Le mode invité actuel (= non identifié) serait remplacé par un compte standard authentifié mais non personnel qui existerait dans dodoc dès que l’on choisit l’option Authentification obligatoire.
Ça permettrait de faire un ou deux projets en démo et de montrer en conditions réelles les paramétrages : non identifié on ne voit que ce qui est publique et authentifié avec un compte (démo / démo) on peut tester les outils dans un ou deux projets de démo sur la plateforme mais pas accès en modification aux autres projets donc le risque serait limité.
Les personnes n’aurait aucun avantage à utiliser ce compte de démo à la place de la création de leur propre compte.

Tant qu’on est sur le sujet de la fenêtre auteur, je trouve que l’affichage de la liste de tous les auteurs n’est pas nécessaire à chaque connexion. Surtout sur des instances avec beaucoup de personnes ça charge beaucoup la page pour une information qui n’est pas forcément utile.

Avec une simple fenêtre "S’identifier " qui s’ouvrirait sur deux champ à remplir avec autocomplétion

Auteur :
Mot de passe :

Créer un auteur

Et pourquoi pas un bouton « Afficher la liste de tous les auteurs » pour déplier l’ensemble de la liste et rechercher les infos sur un auteur (contact…)

Sur mon dodoc local ce n’est pas un problème puisque je reste authentifié d’une ouverture à l’autre et qu’il n’y a que très peu de compte.
Mais pour une classe ou un fablab où il peut y avoir un compte par personne et où on se déconnecte / reconnecte à partir du même poste ça simplifierait la fenêtre.

Je viens de comprendre l’astuce pour ouvrir plusieurs panneaux sur un même écran en cliquant sur la petite croix du bouton.

C’est super d’avoir la possibilité de voir les images de la capture arriver dans la partie collecter et de contrôler en même temps.
Je ne compte pas le nombre de fois où je ferme la partie capture pour retourner dans la bibliothèque du projet de dodoc 9 pour vérifier que l’image ou le média est bien enregistré et ouvrir la capture pour continuer.
Sur un écran d’ordi avec de la place c’est juste génial !

« Le seul truc que je vois qui peut être laborieux, c’est si tu as plusieurs comptes auteurs sans mdp »

Arrive aussi le moment où, si les gens n’ont pas d’hygiène de travail, vous n’allez pas non plus leur apprendre à se laver ! (Dis le type dont le nettoyage a été un peu trop radical…)
Sinon dans mon usage ça parait très bien, oui (application locale).

La version 10 promet !!!
:slight_smile:

1 « J'aime »

Bonjour
Je vais tenter de placer modestement une réflexion du point de vue du PE et de ses élèves. Public non averti. Je pense qu’il faut simplifier les accès.
L’accès à un outil quel qu’il soit (me semble-t-il) nécessite une authentification dès lors qu’il est question de « laisser » une « publication » après son passage. Dans l’idée d’accompagner les élèves à mesurer leurs usages de ces outils, il nous faut expliquer ce que l’utilisation de tels outils génère : historique des actions par exemple. L’accès à DoDoc (en local comme en ligne) nécessite, selon moi, une authentification par pseudo/mdp. Le contraire doit être optionnel. Par contre, la lecture des projets ouverts peut se faire sans cette authentification.
Se pose alors le souci des plus jeunes élèves pour lesquels cette saisie est source d’erreur : est-il possible d’imaginer qu’un QR code soit délivré à chaque auteur de telle sorte que DoDoc ouvre l’accès à l’auteur dès lors qu’il présente le QR code à la caméra ? Sur la page d’accueil, cela supposerait qu’une caméra soit disponible…

Bonjour @YonL

Oui c’est la direction que l’on souhaite aussi pour la version 10.

  • Pouvoir obliger les contributeurs à s’identifier
  • Avoir une interface de consultation uniquement pour les publications pour les visiteurs qui ne sont pas identifiés. L’accès à la bibliothèque des médias d’un projet sera réservé aux seuls contributeurs.

Et oui pour un accès par code QR.
Pour le moment il existe le moyen de s’identifier via un dispositif NFC mais qui n’est pas courant dans les écoles.
J’avais déposé une demande pour utiliser la caméra et un code QR qui serait plus simple dans le cadre scolaire mais qui complique le système d’authentification. La caméra ne peut pas rester allumée à attendre un code QR contrairement au NFC. Il faudrait trouver une astuce pour ça.

Sinon pourquoi pas un code barre avec un douchette comme pour les bibliothèques d’écoles.

Bonjour !

Ok, merci pour les retours – j’ai l’impression que la proposition prends en compte pas mal de scénarios.

Oui, ça serait plus simple. La liste en second, masquées par défaut, ça me paraît pas idiot.

Oui, par contre si ce code QR a un mot de passe associé, que fait-on ? Je vois deux options :

  • on affiche une fenêtre de saisie de mot de passe, à rentrer directement après avoir scanné
  • le mot de passe est chiffré dans le code QR, mais tout le monde peut se faire passer pour tel utilisateur du coup…

La question se pose aussi sur l’identification par NFC.

Si vous le voulez bien gardons ces sujets (et le code-bar) pour un peu plus tard, quand la brique Auteur est opérationnelle. Aucun soucis pour développer ça par la suite, c’est une surcouche indépendante.

Haha oui ça devrait bien faire avancer le schmilblick ! Merci pour la participation aux échanges :slight_smile:

Exact pour la saisie du mot de passe, si c’est dans le code QR il suffit d’avoir le code sous la main pour s’identifier à la place d’un auteur.
Sinon il y a l’exemple de Sugarizer avec un code assez simple à base de picto. Pour les plus petits ça peut fonctionner.
https://try.sugarizer.org/index.html

image

Bonjour à tous,

J’ai cherché ailleurs dans le forum pour vois si l’idée avait été discutée… sans succès. Donc je poste ici :

La V10 pourrait-elle prévoir une désactivation de la fonctionnalité « Discussion ».

Je m’explique :

Après une formation de collègues à Dodoc en collège, les retours d’expériences en classe montrent que très souvent les élèves s’emparent vite de cette fonctionnalité… au point, sur une séance de 55 minutes, de distraire « fortement » les élèves des objectifs poursuivis par le prof.
Alors, oui, dans un monde idéal, il faudrait former les élèves à gérer leur envie de jouer, et de n’utiliser l’outil qu’à bon escient pour collaborer ou aider un camarade (à titre personnel, je me lance régulièrement le défi de corriger mon paquet de copie avant de manger la tablette de chocolat qui me fait de l’oeil sur le coin du bureau) mais on a pas toujours le temps, ou ce n’est pas toujours l’objectif premier de la séance.
De mon côté, j’ai fini par ranger le chocolat dans le placard de la cuisine et plus sur mon bureau.
Est-ce que l’admin dodoc pourrait avoir le choix de faire pareil avec les listes de discussion ?

Pour les collègues qui testent l’outil, qui se mettent prudemment à la collaboration en classe, cela les rassurerait de pouvoir le faire.

Merci, et désolé si le sujet a déjà été abordé ailleurs.

Matthieu