Verbesserungen an 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 „Gefällt mir“
2

Gibt es Neuigkeiten dazu? Wir haben es „behoben“, indem wir

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

zu den CSS hinzugefügt haben, aber offensichtlich ist das eine Behebung und keine Lösung …

3 „Gefällt mir“
3

Sie haben wirklich klar artikuliert, wie die Wiki-Funktionalität und die gemeinsamen Bearbeitungen interagieren. Und es ist nicht schön. Danke für den Workaround / die Lösung!!

Ich habe es in meine kleine Wikified Posts Component integriert, da es eine nette kleine Verbesserung der Wiki-Funktionalität ist.

1 „Gefällt mir“
5

Ah – das wusste ich nicht über unsere Komponente, sehr nützlich (ich habe gerade die alte verwendet, um Wiki-Beiträge zu färben und werde jetzt wechseln)

2 „Gefällt mir“
7

Sie können dies zu Ihrem Thema auf der Registerkarte common > header (oder in /common/header.html in einer Remote-Komponente) hinzufügen. Dies fügt der Klasse shared-edits-post Beiträge mit gemeinsam genutzten Bearbeitungen hinzu, wenn der aktuelle Benutzer diese bearbeiten kann.

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

dann in CSS

.shared-edits-post {
  // do some work
}
5 „Gefällt mir“
8

Erledigt!! Es ist jetzt alles in der Wikified Posts Component zusammengefasst:

Danke Joe – du hast alles möglich gemacht!!

Ich muss wirklich den ersten revision-footer-button (mit dem Text „Edit Wiki“) ansprechen und ihn nur für Shared Edits-Posts ausblenden. Gibt es eine Möglichkeit, diese Klasse auch auf das Revisionsfenster/-dialogfeld anzuwenden?

3 „Gefällt mir“
9

Ich habe ein paar Änderungen vorgenommen.

Dies ist behoben. Das Umschalten von Wiki auf einem Shared Edits-Beitrag zeigt nun die richtige Beschriftung an.

Dies ist ebenfalls behoben. Wenn Sie auf den Button aus dem Revisionsverlauf-Modal klicken UND der Beitrag auf shared-edit gesetzt ist, wird der Shared Edits-Composer anstelle des Standard-Composers geöffnet.

Ich habe die Klasse im Plugin hinzugefügt. Sie können den von Ihnen hinzugefügten Snippet also entfernen. Das Plugin fügt diese Klasse nun hinzu, ohne dass Änderungen erforderlich sind.

Ich vermute, Sie wollten das, weil der Button früher den Standard-Composer geöffnet hat? Das ist jetzt behoben, sodass Sie ihn nicht mehr ausblenden müssen.

6 „Gefällt mir“
10

[Zitat=“Ralf_Stockmann, Beitrag:1, Thema:232713”]
Ich würde gerne eine Option sehen, bei der das Recht, gemeinsame Bearbeitungen zu starten/stoppen, an das Recht zum Starten/Beenden eines Wikis gekoppelt ist. Die Funktionalität ist recht ähnlich, warum also unterschiedliche Rechte wählen (nur Mods)?
[/Zitat]

Das ist für uns immer noch ein Dealbreaker: Wir versuchen, aus Datenschutzgründen so wenige Moderatoren wie möglich zu haben. Daher würden wir es LIEBEN, eine Option zu haben, bei der jeder, der ein Wiki starten kann, auch die gemeinsamen Bearbeitungen starten kann - im Grunde ist es dasselbe. Übrigens: Wir haben diesen Modus “WikiPad” genannt - er ist einprägsamer als gemeinsame Bearbeitungen.

4 „Gefällt mir“
11

Sicher, ich bin absolut offen dafür, eine Einstellung für „Gruppen, denen das Starten gemeinsamer Bearbeitungen gestattet ist“ hinzuzufügen. Standardmäßig ist diese auf „Mitarbeiter“ eingestellt, aber Sie können sie nach Belieben ändern.

8 „Gefällt mir“
13

Wie hoch sind die Chancen, dass dies geschieht? Nochmals – diese kleine Änderung wäre ein Wendepunkt in unserer täglichen Arbeit.

5 „Gefällt mir“
14

Vielen Dank für dieses großartige Plugin, das sich sehr gut in unsere Anwendungsfälle einfügt, um Discourse für gemeinsame Notizen, Brainstorming usw. zu nutzen. Bei der Untersuchung des Plugins habe ich jedoch gelegentlich Störungen erlebt, die leider schwer konsistent zu reproduzieren sind.

Was ich erlebt habe, ist, dass eine Änderung von Benutzer A rückgängig gemacht wird, wenn Benutzer B das Dokument aktualisiert, wobei beide Änderungen explizit mit der Schaltfläche “Speichern” gespeichert werden. Ich gehe davon aus, dass dies durch Netzwerkprobleme verursacht werden könnte, und es ist mir gelungen, das Verhalten wie folgt zu reproduzieren:

Ich weiß, dass dies ziemlich künstlich erscheint, aber es war die einzige Möglichkeit, das Verhalten zu reproduzieren, das ich immer wieder erlebe. Ist dieses Problem schon bei anderen aufgetreten? Gibt es vielleicht sogar eine Lösung dafür?

5 „Gefällt mir“
15

Ja, ich bin auf ein ähnliches Problem mit einer schlechten Internetverbindung gestoßen, manchmal gehen dabei ziemlich viele Bearbeitungen verloren. Das ist sehr frustrierend. Vielleicht könnte eine Art Disconnect-Erkennung funktionieren und auf einen localStorage-Puffer oder so etwas umgeschaltet werden. Vielleicht erst localStorage und später synchronisieren… Ich bin mir nicht sicher, wie es technisch umgesetzt ist, aber es gibt sicherlich Zeiten, in denen es besser wäre, die Synchronisierung um ein paar Millisekunden zu verzögern, als Text zu verlieren.

3 „Gefällt mir“
16

Dies ist immer noch ein riesiges Problem auf unserer Website. Vielleicht helfen diese Informationen: siehe diese Änderung im Verlauf:

image
image1177×229 14.6 KB

„system“ ist das System-Root-Konto. Warum wird kein Benutzerkonto angezeigt? Eine weitere Variante ist diese:

image
image1187×188 14.8 KB

Es ist immer noch dem System zugeordnet, aber mit zusätzlichen Informationen „bearbeitet von xy“. Seltsam.

1 „Gefällt mir“
17

Hallo @Ralf_Stockmann :slight_smile:

Ich habe deine Beiträge in ein neues #ux-Thema verschoben, damit sie nicht vom Thema-Timer gefressen werden. Ich glaube, es gibt ein paar Probleme, die es wert sind, separat verfolgt zu werden (ich glaube, @Johani’s Fix hat sich mit einigen befasst?). Wenn ja, lass es mich wissen und wir können ein oder mehrere neue Themen dafür erstellen. :+1:

3 „Gefällt mir“
18

Danke – aber mir fehlen jetzt die Beiträge von @literarymachine zu diesem Thema (ein Kollege von mir), in denen er einige netzwerkbezogene Race Conditions dieses Plugins aufzeigte, die a) immer noch nicht behoben sind und b) dieses ansonsten fantastische Plugin für ernsthafte Arbeiten eher nutzlos machen…?

3 „Gefällt mir“
19

Ich glaube, das sollte alles sein. :crossed_fingers:

3 „Gefällt mir“
20

Das ist auch bei uns aufgetaucht und wäre sehr hilfreich.

Wäre ein PR hierfür nützlich? Offizielle Plugin-PRs sind für Hacker wie mich ziemlich herausfordernd, da sie mehr Einrichtung und Fachwissen erfordern, als ich zur Verfügung habe!

21

Tl4 dürfen jetzt gemeinsam genutzte Bearbeitungen umschalten, was Ihnen deutlich mehr Flexibilität gibt.

Pr kann dies in eine gruppenbasierte Website-Einstellung ändern.

2 „Gefällt mir“
22

Wie sieht es mit Moderatoren aus? Oder müssen sie auf TL4 hochgestuft werden?

Da sie sich ohnehin auf TL4 hochstufen können, wäre es sinnvoll, ihnen die Möglichkeit zu geben, gemeinsame Bearbeitungen zu aktivieren.

1 „Gefällt mir“