Tout à fait, c’était l’idée
Et à terme, un journal des modifications qui indique précisément qui a fait quoi et quand, uniquement accessible aux contributeurs.
Tu peux me faire une issue ? merci !
EDIT : je pense à un truc, ça fait pas mal de paquets qui circulent car potentiellement tous les utilisateurs qui sont sur la page d’accueil recoivent aussi cette info pour chaque micro-modif (un média déplacé dans une publi = une modif) si le projet n’est pas invisible… Vu le « coût » en terme de performances surtout pour des instances de de plusieurs centaines d’utilisateurs, ça m’interroge…
Aîe on retombe dans le problème de surcharge serveur à cause du suivi des auteurs
Il faudrait limiter l’actualisation de cette date. Par exemple en actualisant quand l’auteur ferme ou sort du projet.
Exemple : J’ouvre le projet, je travaille dessus (collecte + remix + publication) ça ne remonte pas en temps réel, mais quand je sors/ferme le projet ça remonte l’info et actualise la date pour tout le monde.
Surtout qu’il n’y a pas d’horodatage, c’est juste le jour… donc pas forcement besoin de temps réel
Edit : je viens de me rendre compte que c’est cliquable et que ça affiche l’heure
Pas tout à fait, car ici il y a déjà une stratégie beaucoup plus fine qu’avant : seuls les personnes qui consultent la page des projets ou ce projet recevraient l’info d’une modification (contrairement à « toute personne connectée » avant) et le paquet ne contient que le champ modifié (et pas « toutes les métadonnées du projet »). Mais au regard de ce qu’apporte cette fonctionnalité, j’ai un doute sur son intérêt.
En fait l’intérêt principal de l’avoir aussi sur la page des projets, c’est de pouvoir classer les projets par date de dernière modification et avoir ceux modifiés en dernier en haut (actuellement sur dodoc 9 c’est par date de création par défaut). Mais l’inconvénient majeur, c’est donc que n’importe quelle modif dans le projet remonte à toutes les personnes connectées sur cette page.
Soit on supprime l’info et on a que le journal, pour les contributeurs, pour la retrouver.
Soit on la garde et on est vigilant là-dessus, notamment si on voit que ça consomme bcp de ressources si bcp de visiteurs.
Soit on la rend « non réactive », c’est à dire qu’elle ne se met pas à jour automatiquement, il faut recharger la page pour qu’elle soit rafraichit (contrairement au titre d’un projet, par exemple, qui est synchronisé sans action de la part du visiteur).
Ça me semble un peu aléatoire comme comportement et pas forcément compréhensible pour les usagers. Je comprends l’idée mais pas trop fan…
Et si on la rend non-dynamique mais avec un petit bouton « rafraichir » à côté ?
le retour du stopmotion (pas possible encore de le compiler)
navigation entre les médias dans le panneau collecter
remise en place des remixes – mais il reste pas mal de boulot
amélioration de la publication page à page, notamment pour la nav entre les pages et la gestion des marges et du bord de la page, qui apparait au-dessus des médias
Personnellement, je pense qu’une recharge de la page devrait suffir. En tant qu’instit, c’est souvent sur un temps différé que j’irai à la recherche des modifs de la journée, pour surligner des mots en vue de correction ou mettre des commentaires çà et là.
Avec un affichage par date de dernière modif, est-il quand même possible d’avoir un champ qui indique la date de la modif? Par exemple, si je jette un coup d’oeil aux publications à midi et que je corrige quelques trucs, ça serait pratique que le soir je puisse visualiser rapidement les publications modifiées après 13h00. Donc : classement, mais aussi indication d’un timecode, si besoin.
Bravo pour le travail accompli @louis. Si je rejoins @matthieu sur l’essentiel de ces remarques, je dirais plutôt qu’un projet sans auteur revient à l’administrateur do.doc par défaut. Dans les fablabs, les contributeurs ne sont pas constants et il faut penser à garder la possibilité de faire administrer le contenu de la documentation déjà réalisé par le Fabmanager qui doit pouvoir la finaliser pour publication. Donc si le fabmanager est admin, alors la suppression du dernier auteur lui basculerait automatiquement le projet dans sa liste de projet à lui, en mode en cours non publié. A lui de prendre le temps de compléter/lisser le contenu et de le préparer pour publication.
Désolée d’avoir repris le cours de ce fil avec autant de retard, mais ça y est, j’ai commencé à faire des tests.
D’abord un énorme respect pour les phénoménales contributions des beta-testeurs et ta réactivité légendaire Louis.
Avec le recul de quelqu’un qui n’avait pas testé depuis novembre, les avancées sont spectaculaires.
Pour les bugs et améliorations à suggérer:
(J’ai immédiatement essayer la publication récit puisque c’est celle que nous utilisions en V9 pour je fabrique).
Au test de ma première publication, je n’avais pas accès au menu texte. Une fois refermée je ne pouvais plus l’ouvrir ou modifier, seulement le titre, pas d’accès à l’interface texte non plus. Je l’ai donc effacer. Et j’ai recommencé de zero, avec une nouvelle publication récit et là l’interface texte est apparue. Je précise que j’utilise Chrome avec une version à jour sur un pc Windows 10.
Je n’arrive pas à comprendre de façon intuitive comment je peux ajouter un media dans le récit. Est-ce que récit correspond à la fonction Texte de la V9 plus que la recette Récit.
Pour la mise en page d’un récit je dois faire document page à page du coup. J’avoue être un peu perdue (encore une fois pardon de raccrocher les wagons si tard, le seul avantage est une lecture grand débutant des dernières modifications et fonctionnalités=)
J’ai remarqué la même chose dans les recettes page à page. Lorsqu’on clique sur ajouter une page rien n’apparaît, du coup on clique plusieurs fois sans que rien ne se passe. Si on recharge la page (web) toutes les pages apparaissent enfin. Ensuite ça fonctionne normalement, c’est juste à la création.
Bien noté, ça marche. On testera pour voir ce qui est pertinent (en mode hotspot/raspberry notamment).
C’est un bug effectivement, comme @julien l’indiquait. Je viens de le résoudre normalement, à retester pour me confirmer que c’est bien résolu chez vous !
C’est encore bancal oui ! L’interface reprendra les éléments qui marchent bien dans la recette récit de dodoc 9 (notamment le bandeau d’ajout de média) :
J’ai toujours le bug à la création d’une publication page à page.
Si je clique sur « ajouter une page », rien ne s’affiche. Il faut recharger la page pour qu’elle apparaisse.
Est -ce qu’on ne pourrait pas avoir une première page par défaut ?
Pour le stop motion, je trouve que c’est une très bonne idée d’avoir ajouté un bouton pour la lecture, ça évite de générer les vidéos juste pour contrôler.
Par contre le bouton pour assembler avec le picto de lecture est très visible et trop ressemblant avec la lecture. Est-ce qu’on pourrait utiliser un picto de film à la place pour le différencier de la lecture seule, ou autre chose mais qui soit plus en rapport avec l’export et pas seulement la lecture de la séquence.
Exemple
Bonsoir,
D’abord bravo pour tout ce travail déjà fait. Je me joins au test de la V10 en ligne.
J’ai créé un projet puis un récit puis un texte. Si je change de Style Normal → Titre 1 → Tiitre 2 a chaque fois j’obtiens ce petit message sans conséquence car je peux écrire le titre.
La fonction qui permet de bouger une image ou de l’ajouter à une autre image ne fonctionne qu’après avoir rechargé la page.
J’ai mis les remarques des choses qui me semblent peu ergonomiques pour la mise en page. Dans le récit:
Pourquoi les numéro de ligne s’affichent? Elle disparaissent en publication ?
ça serait chouette de pouvoir rajouter du texte dans un bloc à côté d’un média, comme si c’était un média… (mise page en L…)
Dans le page à page, je n’arrive pas à sélectionner du texte, pointer avec le curseur un endroit du texte pour correction: je ne peux y aller qu’avec les flèches, c’est peu pratique, et pas intuitif. Je ne sais pas si c’est un bug… Du coup pas de possibilité de faire de copier coller…
Un truc sympa serait que le bloc s’agrandisse au fur et à mesure qu’on écrit et accompagne le volume du bloc.
Une question: comment exporter les publications (pdf, txt, html?)
Comme @Cat_FacLab-Numixs j’ai du texte qui s’affiche en miroir dans les blocs de texte.
Mais ça ne se produit pas à chaque fois, je n’arrive pas à le reproduire ni à savoir ce qui déclenche ce doublon de texte inversé.
Bonjour @louis
Je viens de voir que tu avais modifié la pelure d’oignon de l’animation en la cachant derrière un bouton.
Autant je trouve pratique les deux boutons pour le time lapse et le retardateur, autant celui pour la pelure d’oignon me gêne. C’est l’une des fonctionnalités principales de la capture en animation et on a toujours un œil dessus pour la modifier et contrôler sur quelle vue nous sommes. Je trouve que ça manque beaucoup à l’interface de ne pas l’avoir sur l’interface principale.
J’imagine que tu as fait ça pour une question de place dans le bandeau mais je préfère encore l’avoir dans une autre fenêtre si elle ne rentre pas dans celle du bas mais qu’elle soit présente en continue.
De plus à chaque chargement de page elle disparaît et se réinitialise.
Sans vouloir faire du à ton travail, je milite pour le retour de la pelure d’oignon… avec les larmes aux yeux
Ha oui alors c’est des propositions en cours, j’ai pas eu le temps de développer mais l’idée était de libérer le coin inférieur droit pour y placer l’encart « assembler » (pour que le triptyche de bas d’écran soit « annuler » « prendre une photo » « terminer/assembler les photos », qui me semble être un déroulement logique).
Tu as raison oui, trop difficile à identifier/trouver et important aussi que des gens le découvrent par pur sérendipité (« c’est quoi pelure d’oignon ? ha mais c’est utile ce truc »).
Je propose qu’on vire le bouton pour révéler ce menu, et qu’on le rende toujours visible quand on a le flux « vidéo » sous les yeux. Et on lui trouve un endroit plus adapté ? à la place de l’encart assemblage du coup ?
OK pour ce point, ça me va aussi et c’est cohérent avec les autres menus
Autre proposition :
on garde le bandeau en bas pour annuler / photo / assembler
on déplace le curseur de la pelure d’oignon sur / au dessus des deux images concernées (= les deux dernières dont le live)
Je trouve que ça serait bien à cet endroit et que ça suive les 2 images.
Quelques arguments :
Le bandeau de la séquence d’image est central et est conservé même sur les affichages réduits. C’est un élément important que l’on utilise en permanence.
C’est à cet endroit que s’applique cet effet de superposition
On visualise directement le lien entre la vue affichée en grand et la place du curseur : sur l’image de gauche / entre les deux / sur l’image de droite (live)
même si on cache légèrement le haut des deux vignettes avec le curseur, on a l’affichage principal en grand juste au dessus. Les vignettes sont justes là pour identifier la vue et non pour avoir un affichage de contrôle.
Est-ce que c’est jouable que le curseur suive les images à la manière du picto « direct » sur la dernière ou de la « corbeille » qui se déplace sur les images visualisées ?
Dans tous les cas le curseur apparaîtrait après la première capture (avec 1 image + 1 live) et serait assez rapidement du côté droit (dès qu’on a fait les premières vues. Si on déplace dans la séquence vers les premières vues le curseur sortirait vers la droite avec les deux dernières images ( 1 + Live ). On ne pourrait plus y accéder mais ce serait même plus logique qu’actuellement puisque le curseur ne serait visible et actif que si on voit la vignette « live ».
Et si on veut conserver le texte on pourrait l’écrire dans le curseur pour gagner de la place
Oui ok, j’aime beaucoup l’idée !
Je pense qu’on peut éviter au maximum la superposition et que les éléments interactifs ne se chevauchent, et utiliser l’espace de la vignette vidéo d’aperçu pour ça car elle n’est pas utile quand on est dessus (ça fait doublon avec l’image en grand).
J’ai fais un test rapide (non fonctionnel) dans l’interface :
On pourrait aussi imaginer que ce slider apparaisse sur les images capturées quand elles sont séléctionnées, de manière à pouvoir activer une pelure d’oignon sur n’importe quelle image (par exemple, je prends comme référence l’image 1 pour toutes les captures car c’est le point de départ de tous les éléments de ma scène) mais je ne suis pas sur que ça soit vraiment pertinent, et ça complexifie l’interface.
Ça te/vous semble bien comme proposé dans mes captures ? à priori fonctionnel aussi sur tablette/smartphone.
à ton travail, je milite pour le retour de la pelure d’oignon… avec les larmes aux yeux 
