Miglioramenti Shared-Edits

Contribuisci UX
1

Abbiamo eseguito ulteriori test su alcuni comportamenti strani della modalità modifica condivisa — che, per il resto, è ottima. Ecco alcune scoperte:

image
image423×303 12 KB

Nota che il plugin non abilita di per sé l’accesso alla modifica. Ciò significa che se desideri che gli utenti non moderatori possano modificare collaborativamente il post, devi anche impostare il post come Wiki (verde, opzionale):

Se abilito le Modifiche Condivise, ho anche l’opzione di renderlo un wiki. Tuttavia, se lo faccio tramite l’opzione Rendi Wiki, il testo mostra ancora “Rendi Wiki”. Anche se entra effettivamente in modalità Wiki, non esiste alcun modo per revocare la modalità Wiki.

I moderatori possono attivare o disattivare le modifiche condivise in un argomento (rosso) tramite l’icona dell’ingranaggio nella barra del compositore

Vorrei vedere un’opzione in cui il diritto di avviare/fermare le modifiche condivise sia collegato al diritto di avviare/terminare un wiki. La funzionalità è piuttosto simile, quindi perché scegliere permessi diversi (solo moderatori)?

Ora ecco il punto critico:

  1. Imposto un post in modalità wiki e in modalità modifica condivisa
  2. Alcune persone iniziano a modificare tramite il compositore per le modifiche condivise
  3. Alcune altre persone utilizzano l’editor wiki “classico” — tramite il link delle revisioni sullo stesso post, contemporaneamente:

image
image849×235 24 KB

e poi in basso Modifica Post

image
image1163×141 8.16 KB

A questo punto le cose si complicano rapidamente. Molto rapidamente. Molti contenuti vengono sovrascritti, le modifiche non vengono salvate, si verificano conflitti di revisione. La mia comprensione è che le modifiche condivise non sono progettate per funzionare contemporaneamente alla modifica wiki classica (completamente comprensibile da un punto di vista tecnico).

Penso che il modo migliore per risolvere il problema sia reindirizzare il pulsante Modifica Post verso il nuovo compositore per le modifiche condivise.

Poiché il compositore per le modifiche condivise non offre l’opzione per modificare i metadati del post (titolo, tag, ecc.), deve esserci anche una soluzione per questo aspetto.

Si potrebbe obiettare: “Basta dire alle persone di stare lontane dalla matita delle revisioni”, ma non funziona così: molti dei nostri utenti preferiscono questo metodo piuttosto che scorrere fino alla fine di un lungo post su WikiPad.

So che potrebbe non essere facile da risolvere, ma al momento la funzionalità di modifiche condivise è piuttosto rotta. L’abbiamo provata su diversi post con persone diverse e sempre sono sorti conflitti.

9 Mi Piace
2

Ci sono novità a riguardo? Lo abbiamo “risolto” aggiungendo

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

al CSS, ma ovviamente questa è una correzione, non una soluzione…

3 Mi Piace
3

Hai articolato in modo davvero chiaro come interagiscono la funzionalità wiki e le modifiche condivise. E non è un bello spettacolo. Grazie per la soluzione alternativa / correzione!!

L’ho integrata nel mio piccolo Wikified Posts Component poiché è un piccolo e piacevole miglioramento della funzionalità wiki.

1 Mi Piace
5

Ah, non ero a conoscenza del nostro Component, molto utile (ho appena usato quello vecchio per colorare i Wiki-post e ora passerò a questo)

2 Mi Piace
7

Puoi aggiungere questo al tuo tema nella scheda common > header (o in /common/header.html in un componente remoto), e aggiungerà una classe shared-edits-post ai post di shared-edit se l’utente corrente può modificarli.

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

quindi in CSS

.shared-edits-post {
  // fai qualcosa
}
5 Mi Piace
8

Fatto!! Ora è tutto integrato nel componente Wikified Posts:

Grazie Joe - hai reso tutto possibile!!

Quello che devo davvero mirare è il primo revision-footer-button (con il testo “Edit Wiki”) e nasconderlo solo per i post di Shared Edits. C’è un modo per far coprire quella classe anche al pannello/dialogo di revisione?

3 Mi Piace
9

Ho apportato alcune modifiche.

Questo è stato risolto. L’attivazione/disattivazione del wiki su un post di modifiche condivise ora mostrerà l’etichetta corretta.

Anche questo è stato risolto. Se fai clic sul pulsante dalla modale della cronologia delle revisioni E il post è impostato su shared-edit, si aprirà il composer di modifiche condivise invece di quello predefinito.

Ho aggiunto la classe nel plugin. Quindi, puoi rimuovere lo snippet che hai aggiunto. Il plugin ora aggiungerà quella classe senza bisogno di modifiche.

Suppongo che tu lo volessi perché il pulsante una volta apriva il composer predefinito? Ora è stato risolto, quindi non avrai più bisogno di nasconderlo.

6 Mi Piace
Wikified Posts Component
10

[citazione=“Ralf_Stockmann, post:1, topic:232713”]
Vorrei vedere un’opzione in cui il diritto di avviare/interrompere modifiche condivise sia collegato al diritto di avviare/terminare un wiki. La funzionalità è abbastanza simile, perché scegliere diritti diversi (solo mod)?
[/citazione]

Questo è ancora un punto critico per noi: cerchiamo di avere il minor numero possibile di moderatori per motivi di privacy. Quindi ci piacerebbe avere un’opzione che permetta a chiunque possa avviare un wiki di avviare anche le modifiche condivise - in pratica è la stessa cosa. A proposito: abbiamo chiamato questa modalità “WikiPad” - è più incisivo di modifiche condivise.

4 Mi Piace
11

Certo, sono totalmente aperto ad aggiungere un’impostazione per “gruppi autorizzati ad avviare modifiche condivise”, con impostazione predefinita su “staff”, ma che permetta di cambiarla in qualsiasi altro gruppo.

8 Mi Piace
Discourse Shared Edits
13

Quali sono le probabilità di realizzarlo? Ancora una volta, questa piccola modifica cambierebbe le regole del gioco nel nostro lavoro quotidiano.

5 Mi Piace
14

Grazie per questo fantastico plugin, che si integra molto bene nei nostri casi d’uso per utilizzare Discourse per prendere appunti in modo collaborativo, fare brainstorming, ecc. Tuttavia, durante l’esame del plugin ho occasionalmente riscontrato dei glitch, che purtroppo sono difficili da riprodurre in modo coerente.

Ciò che ho riscontrato è che una modifica apportata dall’utente A viene annullata quando l’utente B aggiorna il documento, entrambe le modifiche essendo state esplicitamente salvate utilizzando il pulsante Salva. Presumo che ciò possa essere causato dalla connettività di rete e sono riuscito a riprodurre il comportamento come segue:

So che questo sembra piuttosto artificiale, ma è stato l’unico modo per riprodurre il comportamento che riscontro ogni tanto. Qualcun altro ha riscontrato questo problema? Esiste forse anche una soluzione?

5 Mi Piace
15

Sì, mi sono imbattuto in un problema simile con una connessione Internet scadente, a volte perdendo un bel po’ di modifiche. Questo è molto frustrante. Forse potrebbe funzionare un qualche rilevamento della disconnessione e passare a un buffer localStorage o qualcosa di simile. Forse usare prima localStorage e sincronizzare dopo… Non sono sicuro di come sia implementato tecnicamente, ma sicuramente ci sono alcuni momenti in cui avere la sincronizzazione ritardata di pochi millisecondi sarebbe meglio che perdere testo.

3 Mi Piace
16

Questo è ancora un grosso problema sul nostro sito. Forse queste informazioni possono aiutare: vedi questa modifica nella cronologia:

image
image1177×229 14.6 KB

“system” è l’account root di sistema. Perché non viene visualizzato alcun account utente? Un’altra variante è questa:

image
image1187×188 14.8 KB

È ancora assegnato a system, ma con un’informazione aggiuntiva “edited by xy”. Strano.

1 Mi Piace
17

Ciao @Ralf_Stockmann :slight_smile:

Ho diviso i tuoi post in un nuovo argomento UX per evitare che vengano persi dal topic-timer. Penso ci siano un paio di problemi inclusi che potrebbero valere la pena tracciare separatamente (penso che la correzione di @Johani ne abbia gestiti alcuni?). Se è così, fammelo sapere e possiamo creare un nuovo argomento/nuovi argomenti per loro. :+1:

3 Mi Piace
18

Grazie, ma ora mi mancano i post di @literarymachine su questo argomento (un mio collega) in cui ha evidenziato alcune race condition relative alla rete di questo plugin, che a) non sono ancora state corrette e b) rendono questo plugin, altrimenti fantastico, piuttosto inutile per un lavoro serio…?

3 Mi Piace
Test our new composer!
19

Penso che dovrebbe essere tutto. :crossed_fingers:

3 Mi Piace
20

Questo è emerso anche per noi e sarebbe molto utile.

Un PR sarebbe utile per questo? I PR dei plugin ufficiali sono piuttosto impegnativi per hacker come me, poiché richiedono più configurazione e competenza di quella che ho a portata di mano!

21

Tl4 ora può attivare le modifiche condivise, il che ti offre molta più flessibilità

Pr è invitato a impostarlo su un’impostazione del sito basata sul gruppo

2 Mi Piace
22

E i moderatori? O devono essere promossi a TL4?

Dato che possono comunque promuoversi a TL4, avrebbe senso concedere loro la possibilità di attivare le modifiche condivise.

1 Mi Piace