Miglioramenti Shared-Edits

UX
1

We did some further testings on odd behaviours of the - otherwise great - shared edit mode. Here are some findings:

image

Note that the plugin does not enable edit access per se. This means that if you want non-moderators to be able to collaboratively edit the post you must also make the post a Wiki (green, optional):

If I enabled Shared Edits, I have the option to make it a wiki, too. But if I do so via the Make Wiki option, it still reads “Make Wiki”. It will enter Wiki mode, though. But there is no way to revoke the Wiki.

Moderators can toggle shared edits on a topic (red) via the gear icon on the composer bar

I would like to see an option, where the right to start/stop shared edits is linked to the right to start/end a wiki. The functionality is quite similar, why choosing different rights (mods only)?

Now this is a critical one:

  1. I set a posting into wiki and shared edit mode
  2. Some people start editing away in the shared edit composer
  3. Some other people use the “classic” wiki editor - via the revisions link on the same posting at the same time:

image
image849×235 24 KB

and then at the bottom Edit Post

image
image1163×141 8.16 KB

Now things get ugly real quick. Like - reeeealy ugly. Lots of overwritten stuff, changes not saved, revision conflicts. My understanding is, that shared edits is not designed to work at the same time as classic wiki editing (completely understandable from a technical view).

I figure the best way to solve this would be to redirect the Edit Post button to the new shared edits composer?

Hence the shared edits composer doesn’t offer the option to edit the metadata of the posting (titel, tags etc.), there has to be a solution for that, too.

One could argue “just tell your people to stay away from the revisions-pencil”, but this is not how it works - a lot of our users like this way instead of scrolling down to the end of a long WikiPad posting.

I see this might not an easy one to be fixed, but right now the shared edits feature is quite broken. We’ve tried it on several postings with different people, and always conflicts arose.

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
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
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
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