Améliorations des Shared-Edits

Contribuer UX
1

Nous avons effectué des tests supplémentaires sur des comportements étranges du mode d’édition partagé – par ailleurs excellent. Voici nos constats :

image
image423×303 12 KB

Notez que le plugin n’active pas l’accès à l’édition en soi. Cela signifie que si vous souhaitez que des utilisateurs non-médiateurs puissent éditer le message collaborativement, vous devez également le passer en mode Wiki (vert, optionnel) :

Si j’active les éditions partagées, j’ai aussi la possibilité de le passer en mode wiki. Mais si je le fais via l’option Passer en mode wiki, le bouton affiche toujours « Passer en mode wiki ». Le mode wiki est bien activé, mais il n’existe aucun moyen de révoquer le mode wiki.

Les médiateurs peuvent activer ou désactiver les éditions partagées sur un sujet (rouge) via l’icône d’engrenage dans la barre de composition

J’aimerais voir une option liant le droit de démarrer/arrêter les éditions partagées au droit de démarrer/terminer un wiki. La fonctionnalité est assez similaire, pourquoi choisir des droits différents (réservés aux médiateurs uniquement) ?

Voici maintenant un point critique :

  1. Je passe un message en mode wiki et en mode d’édition partagé.
  2. Certaines personnes commencent à éditer dans le composant d’édition partagé.
  3. D’autres personnes utilisent l’éditeur wiki « classique » – via le lien des révisions sur le même message, en même temps :

image
image849×235 24 KB

Puis, en bas, cliquez sur Modifier le message :

image
image1163×141 8.16 KB

Les choses se gâtent très rapidement. Vraiment très vite. Beaucoup de contenus écrasés, des modifications non enregistrées, des conflits de révisions. Ma compréhension est que les éditions partagées ne sont pas conçues pour fonctionner en même temps que l’édition wiki classique (ce qui est tout à fait compréhensible d’un point de vue technique).

Je pense que la meilleure solution serait de rediriger le bouton Modifier le message vers le nouveau composant d’édition partagée.

Puisque le composant d’édition partagée n’offre pas l’option de modifier les métadonnées du message (titre, balises, etc.), il faut également trouver une solution pour cela.

On pourrait dire « dites simplement à vos utilisateurs de ne pas toucher au crayon des révisions », mais ce n’est pas ainsi que cela fonctionne : beaucoup de nos utilisateurs préfèrent cette méthode plutôt que de faire défiler jusqu’à la fin d’un long message WikiPad.

Je vois bien que cela pourrait ne pas être facile à résoudre, mais pour l’instant, la fonctionnalité d’édition partagée est assez cassée. Nous l’avons testée sur plusieurs messages avec différentes personnes, et des conflits sont toujours survenus.

9 « J'aime »
2

Des nouvelles à ce sujet ? Nous l’avons « corrigé » en ajoutant

div#revision-footer-buttons button:nth-of-type(1) {
    display: none !important;
}

au CSS, mais il est évident que c’est une solution de contournement, pas une solution…

3 « J'aime »
3

Vous avez clairement expliqué comment la fonctionnalité wiki et les modifications partagées interagissent. Et ce n’est pas joli. Merci pour la solution de contournement / correction !!

Je l’ai intégrée dans mon petit composant Wikified Posts Component car c’est une petite amélioration agréable de la fonctionnalité wiki.

1 « J'aime »
5

Ah - je ne connaissais pas notre Composant, très utile (j’ai juste utilisé l’ancien pour colorer les Wiki-posts et je vais changer maintenant)

2 « J'aime »
7

Vous pouvez ajouter ceci à l’onglet common > header de votre thème (ou dans /common/header.html dans un composant distant), et cela ajoutera une classe shared-edits-post aux publications de modifications partagées si l’utilisateur actuel peut les modifier.

<script type="text/discourse-plugin" version="0.8">
  api.addPostClassesCallback((attrs) => {
    if (attrs.shared_edits_enabled && attrs.canEdit) return ["shared-edits-post"];
  });
</script>

puis en CSS

.shared-edits-post {
  // faire quelque chose
}
5 « J'aime »
8

C’est fait !! Tout est maintenant intégré dans le composant Wikified Posts :

Merci Joe - tu as rendu tout cela possible !!

Ce que je dois vraiment cibler, c’est le premier bouton revision-footer-button (avec le texte « Modifier le Wiki ») et le masquer uniquement pour les publications avec des modifications partagées. Y a-t-il un moyen de faire en sorte que cette classe couvre également le panneau / la boîte de dialogue de révision ?

3 « J'aime »
9

J’ai poussé quelques modifications.

Ceci est corrigé. L’activation/désactivation du mode wiki sur un post de modification partagée affichera désormais le libellé correct.

Ceci est également corrigé. Si vous cliquez sur le bouton depuis la modale de l’historique des révisions ET que le post est défini sur shared-edit, le compositeur de modifications partagées s’ouvrira au lieu du compositeur par défaut.

J’ai ajouté la classe dans le plugin. Vous pouvez donc supprimer l’extrait que vous avez ajouté. Le plugin ajoutera désormais cette classe sans nécessiter de modification.

Je suppose que vous vouliez cela parce que le bouton ouvrait auparavant le compositeur par défaut ? C’est maintenant corrigé, vous n’aurez donc plus besoin de le masquer.

6 « J'aime »
Wikified Posts Component
10

C’est toujours un obstacle pour nous : nous essayons d’avoir le moins de modérateurs possible pour des raisons de confidentialité. Par conséquent, nous aimerions avoir une option permettant à quiconque peut démarrer un wiki de démarrer également les modifications partagées - en gros, c’est la même chose. D’ailleurs : nous avons nommé ce mode “WikiPad” - c’est plus frappant que les modifications partagées.

4 « J'aime »
11

Bien sûr, totalement ouvert à l’ajout d’un paramètre pour « les groupes autorisés à démarrer des modifications partagées », par défaut « personnel », mais vous permettant de le changer en ce que vous voulez.

8 « J'aime »
Discourse Shared Edits
13

Quelles sont les chances que cela se produise ? Encore une fois, ce petit ajustement changerait la donne dans notre travail quotidien.

5 « J'aime »
14

Merci pour ce super plugin, qui s’intègre très bien à nos cas d’utilisation pour utiliser Discourse afin de prendre des notes collaborativement, de faire du brainstorming, etc. En examinant le plugin, j’ai cependant rencontré occasionnellement des bugs, qui sont malheureusement difficiles à reproduire de manière cohérente.

Ce que j’ai constaté, c’est qu’un changement effectué par l’utilisateur A est annulé lorsque l’utilisateur B met à jour le document, les deux changements étant explicitement sauvegardés à l’aide du bouton Enregistrer. Je suppose que cela pourrait être dû à la connectivité réseau et j’ai réussi à reproduire le comportement comme suit :

Je sais que cela semble assez artificiel, mais c’était la seule façon de reproduire le comportement que je rencontre de temps en temps. D’autres personnes ont-elles rencontré ce problème ? Y a-t-il peut-être même une solution ?

5 « J'aime »
15

Oui, je suis tombé sur un problème similaire avec une mauvaise connexion Internet, perdant parfois un tas d’éditions. C’est très frustrant. Peut-être qu’une détection de déconnexion pourrait fonctionner et passer à un tampon localStorage ou quelque chose comme ça. Peut-être utiliser un système basé sur localStorage d’abord et synchroniser plus tard… Je ne suis pas sûr de la façon dont c’est implémenté techniquement, mais il y a certainement des moments où avoir la synchronisation retardée de quelques millisecondes serait mieux que de perdre du texte.

3 « J'aime »
16

C’est toujours un problème énorme sur notre site. Peut-être que ces informations peuvent aider : voir cette modification dans l’historique :

image
image1177×229 14.6 KB

« system » est le compte racine du système. Pourquoi aucun compte utilisateur n’est-il affiché ? Une autre variante est la suivante :

image
image1187×188 14.8 KB

Il est toujours attribué au système, mais avec une information supplémentaire « modifié par xy ». Étrange.

1 « J'aime »
17

Salut @Ralf_Stockmann :slight_smile:

J’ai divisé vos publications dans un nouveau sujet UX pour éviter qu’elles ne soient supprimées par le timer de sujet. Je pense qu’il y a peut-être quelques problèmes qui méritent d’être suivis séparément (je pense que la correction de @Johani s’en est occupée ?). Si c’est le cas, faites-le moi savoir et nous pourrons créer un ou plusieurs nouveaux sujets pour eux. :+1:

3 « J'aime »
18

Merci - mais il me manque maintenant les publications de @literarymachine sur ce sujet (un de mes collègues) où il a souligné certaines conditions de concurrence liées au réseau de ce plugin, qui a) ne sont toujours pas corrigées et b) rendent ce plugin par ailleurs fantastique plutôt inutile pour un travail sérieux… ?

3 « J'aime »
Test our new composer!
19

Je pense que ce sera tout. :crossed_fingers:

3 « J'aime »
20

Cela s’est déjà présenté pour nous et serait très utile.

Une PR serait-elle utile pour cela ? Les PR de plugins officiels sont assez difficiles pour les pirates comme moi car elles nécessitent plus de configuration et d’expertise que ce que j’ai à portée de main !

21

Les Tl4 sont désormais autorisés à activer les modifications partagées, ce qui vous offre beaucoup plus de flexibilité.

Les RP sont invités à le transformer en un paramètre de site basé sur les groupes.

2 « J'aime »
22

Qu’en est-il des modérateurs ? Ou doivent-ils être promus au TL4 ?

Comme ils peuvent se promouvoir eux-mêmes au TL4 de toute façon, il serait logique de leur accorder à tous la capacité d’activer les modifications partagées.

1 « J'aime »