Wikipedia:Technische Wünsche/Topwünsche/Bearbeitungskonflikte

• Über das ProjektStartseite
• Aktuelle ProjekteWoran wird gerade gearbeitet?
• Wunsch­park­platzProbleme für die nächste Umfrage
• TreffenTriff das Projektteam
• NewsletterBleib auf dem Laufenden

Bessere Lösung von Bearbeitungskonflikten
Status	Umgesetzt
Ursprung	Technische Wünsche 2015, (internationale Umfrage 2016)
Ergebnis in der Umfrage	39 Stimmen (Platz 1), (28 Stimmen)
Phabricator	T139601
Bearbeitende	Team Technische Wünsche

Wunsch

Beschreibung

Die Auflösung von Bearbeitungskonflikten soll verbessert werden.

Diskussion (in der Umfrage)

• Neuer Anwendungsfall für den einfacheren Umgang bei Bearbeitungskonflikten. Vorschlag hier. --Micha 17:40, 22. Sep. 2015 (CEST) - Wenn nicht dieser Anwendungsfall, dann soll wenigstens nach dem Serverrountrip der Text mit der jeweiligen Änderung des Users im Textfeld angezeigt bleiben. Für c&p. Jetzt muss man ja "back" klicken und den Text aus dem Browsercache holen und das ist umständlich und unnötig. Das wäre eine Kleinere Änderung. Also nach edit conflict nicht den vom anderen user geänderten Text anzeigen, sondern den vom eigenen user. --Micha 18:54, 22. Sep. 2015 (CEST)
  • Dürfte schon funktionieren: Im Falle eines Bearbeitungskonfliktes gibt es zwei Textfelder. Das normale zum bearbeiten oben mit dem neuen Text (wo man seinen einfügen muss), dann ein Versionsunterschied und dadrunter ein zweites (schreibgeschütztes) Textfeld mit den eigenen Bearbeitungen, wo man sie her kopieren kann. Der Umherirrende 19:21, 22. Sep. 2015 (CEST)
    • Was Mcha vorstellt, ist genau das, was ich mir wünsche. Grüße, --Bellini 05:29, 23. Sep. 2015 (CEST)
• Besseres Tool für die Auflösung von Bearbeitungskonflikten (Idee von der WikiCon, siehe auch phab:T108664) -- Daniel Kinzler (WMDE) (Diskussion) 23:23, 3. Okt. 2015 (CEST)
• Leichtere Möglichkeit nach Bearbeitungskonflikten den eigenen Text zu kopieren --Carlos-X 11:15, 19. Sep. 2015 (CEST)
• In manchen anderen Wikis (jedenfalls Klexikon) kann man eine Seite nicht bearbeiten, wenn jemand anders das Fenster offen hat (man erfährt auch, wer es offen hat). Würde das das Problem nicht lösen? Z. (Diskussion) 23:05, 13. Okt. 2015 (CEST)

Konkretisierung des Wunsches

Bei einem Bearbeitungskonflikt werden bereits jetzt 2 Textfelder angezeigt, wovon das eine die neue Version enthält und aus dem anderen der eigene Text kopiert werden kann, um ihn in die aktuellere Textversion einzufügen. Die Darstellung des Bearbeitungskonfliktes ist jedoch verwirrend und es ist unklar, was genau wo zu tun ist.

Recherche, Tests und Feedback

Dokumentation Planungs- und Entwicklungsverlauf

Vorschläge A und B

Um besser zu verstehen, wie derzeit Bearbeitungskonflikte gelöst werden, in welche Richtung eine Verbesserung gehen kann und was eher nicht gemacht werden sollte, wurde im Mai 2016 zur Diskussion von zwei ersten Vorschlägen eingeladen. Auf Basis der Anmerkungen zu den Vorschlägen A und B, Gesprächen mit Autorinnen und Autoren, Gesprächen im Team und mit WMF-Entwicklern wurde ein weiterer Vorschlag entwickelt (Stand 17. Juni 2016).

Vorkommen von Bearbeitungskonflikten

• Täglich kommt es zu ca. 2000 - 2500 Bearbeitungskonflikten in allen Wikis
• Dies nach Einschätzung von vielen in aktiven Diskussionen oder in Artikeln, die aktuelle Ereignisse beschreiben
• Fall 1: Mehrere Benutzer editieren im selben Abschnitt
• Fall 2: Ein Benutzer editiert im "Seite bearbeiten"-Modus, ein Benutzer editiert nur in einem Abschnitt auf derselben Seite

Bisheriger Umgang mit Bearbeitungskonflikten:

• Je nachdem, wo editiert wird und wie groß die eigenen Änderungen sind (aktuelle Artikel, Artikel mit großen Zeiträumen zwischen den einzelnen Bearbeitungen, aktive Diskussionen), werden gegebenenfalls Vorsichtsmaßnahmen ergriffen, um im Falle eines Bearbeitungskonflikts den eigenen Text nicht zu verlieren: Der eigene Text wird dann in die Zwischenablage oder in einen externen Text-Editor kopiert.
• Es wird entweder der eigene oder der andere, neue Text als Vorlage genutzt und entweder die eigenen oder die anderen Änderungen anschließend nachgezogen.
• Viele nutzen die momentan angebotene Lösung nicht. Die Bearbeitungskonflikt-Ansicht dient eher als “Speicherstopper” oder “Warnhinweis”, infolgedessen entweder
  • im Browser zurückgegangen wird, um zur Situation vor dem Bearbeitungskonflikt und zu einer übersichtlichen Darstellung des eigenen Textes zu kommen, dann die Seite mit der aktuellen Version neu geladen wird und schließlich der eigene Text per copy/paste in die aktuelle Version eingefügt wird;
  • abgebrochen und noch mal von vorne begonnen wird. Ein Bearbeitungskonflikt kann auch soviel Frust erzeugen, dass ganz abgebrochen wird.

Rückmeldungen zu den Vorschlägen A und B sowie ergänzende Ideen:

Vorschlag A: WP:Technische Wünsche/Topwünsche/Bearbeitungskonflikte/Vorschlag A

Vorschlag B: WP:Technische Wünsche/Topwünsche/Bearbeitungskonflikte/Vorschlag B

• die +/- Zeichen im Diff sollten nicht mit markiert werden, wäre auch jenseits des konkreten Bearbeitungskonflikt-Problems sinnvoll
• Leute, die Erfahrung mit Software-Lösungen zum Umgang mit sogenannten "Merge-Konflikten" in der Programmierung haben, können sich eine ähnliche Lösung für Bearbeitungskonflikte vorstellen
• Den hinzugefügten Text in der Vorschau hervorgehoben anzeigen und den Nutzer fragen, ob er den eigenen Beitrag ohne Änderungen eines darunter abspeichern oder nochmal ändern möchte
• Bei jedem Klick auf “Bearbeiten” automatisch anzeigen, dass gerade andere Nutzer auf der Seite arbeiten
• Bedenken, dass sich die Software weiterentwickelt und eine Lösung auch idealerweise in Zukunft verwendbar ist
• Auf eine leichte Bedienbarkeit aus dem Visual Editor heraus achten
• Möglichkeit, eine große Änderung zu deaktivieren
• Bisherige Möglichkeiten sind ausreichend

Aus den Rückmeldungen und weiteren Gesprächen sind die folgenden Punkte als “Rahmen” entstanden:

• Die neue Lösung sollte bisherige Gewohnheiten weiter ermöglichen, und diese sinnvoll unterstützen
• Ein Tool bzw. Vorgehen ähnlich der Auflösung von “Merge-Konflikten” in der Software-Programmierung ist zwar für Programmierer attraktiv (inklusive für das Entwicklerteam selbst), aber für Autoren möglicherweise zu weit weg von der bisherigen Vorgehensweise. Zudem ist Schnelligkeit bei Bearbeitungskonflikten in der Wikipedia oft wichtig, dies ist ein entscheidender Unterschied zu Merge-Konflikten in der Programmierarbeit.
• Die Lösung sollte möglichst nachhaltig sein sowie vereinbar mit der Arbeit von Entwicklerteams der WMF.

Auf dieser Grundlage wurde ein neuer Vorschlag entwickelt.

Vorschlag C

Wenn während der Bearbeitung einer Seite ein anderer Nutzer auf “Speichern” geklickt hat, wird ein Hinweis eingeblendet: “Ein anderer Nutzer hat diese Seite gerade gespeichert. Möglicherweise kommt es zu einem Bearbeitungskonflikt.”

Der Hinweis dient als Erinnerung, den eigenen Text zu sichern oder durch früheres eigenes Speichern im Fall eines Bearbeitungskonflikts einen weniger hohen Anteil an überschnittenen oder nicht mehr passenden Änderungen zu bekommen.

Wenn ein Bearbeitungskonflikt enstanden ist, wird nach Klick auf “Speichern” die aktuelle Textversion im Bearbeitungsfenster angezeigt. Der eigene, nicht editierbare Text wird im Feld parallel zum Bearbeitungsfenster angezeigt und hervorgehoben. Der eigene Text kann so leicht gefunden, kopiert und in die aktuelle Textversion eingefügt werden:

Auf die Diff-Ansicht soll im Bearbeitungskonflikt-Modus verzichtet werden.

Denkbar wären auch die Varianten: Nur Anzeige des Hinweises oder: Nur die neue Bearbeitungskonflikt-Ansicht mit den zwei parallelen Feldern und den hervorgehobenen eigenen Änderungen.

Die Option, dass die +/- Zeichen im Diff nicht mit markiert werden, soll unabhängig von der konkreten Situation “Bearbeitungskonflikt” im Hinterkopf behalten werden, da dies von einigen als nützlich erachtet wurde.

Diskussion auf der Wikimania 2016

Beim Wikimania Hackathon (22-23.6.) wurde eine Veranstaltung organisiert, um mit WMF- und freiwilligen Entwicklern die o.g. Ergebnisse und den Vorschlag zu diskutieren. Ziel war es, das Projekt vorzustellen, das Feld des Machbaren weiter abzustecken und Anregungen zu bekommen. Im Community-Village der Wikimania gab es zudem am Sa, den 25.6. von 10-12 Uhr eine “edit conflict & cookies corner” (mit den Keksen, die man essen kann), um mit Leuten aus verschiedenen Wikipedien/Wikimedia-Projekten zum Thema ins Gespräch zu kommen.

Ergebnisse von der Wikimania

Auf der Wikimania 2016 wurde der Prototyp im Rahmen der "edit conflict and cookies corner" von 10 Personen getestet:

Zusammenfassung der Ergebnisse:

Zum Hinweis (Bild 1 in diesem Abschnitt):

• Der Hinweis wurde von 80% nicht bemerkt
• Der Hinweis könnte unerfahrenere Autoren verunsichern und abschrecken: Es ist nicht klar, was zu tun ist. Erfahrene Autoren würden entweder ihren Text kopieren, die Seite neu laden und dann einfügen, oder zunächst in der Versionsgeschichte nachsehen, was der Andere geändert hat.

Zur Ansicht, in der der Bearbeitungskonflikt gelöst wird (Bild 2 in diesem Abschnitt):

• Es wurde nicht klar, was die andere Person geändert hat, was es schwierig macht, damit zu arbeiten
• Die parallele Ansicht von Text-Bearbeitungsfeld und Text-Ansichtsfeld, aus dem kopiert werden kann, wurde als sehr großen Mehrwert gesehen
• Die Aufgeräumtheit des Interfaces wurde von den Meisten positiv hervorgehoben
• Beschriftungen (“mein Text” “sein Text”) würden die Orientierung erleichtern
• Änderungen von beiden Bearbeitern könnten im rechten Feld angezeigt werden - dies könnte aber auch verwirrend sein. Lösungsidee: Möglichkeit, je nach Bedarf zwischen verschiedenen Ansichten (nur meine/beide Änderungen…) zu wechseln

Hackathon-Diskussionsrunde

Auf dem Wikimania Hackathon wurde der Vorschlag im Rahmen der Veranstaltung “Improving the resolution of edit conflicts” mit Entwicklern der WMF sowie ehrenamtlichen Entwicklern diskutiert.

Zusammenfassung:

Hinweis:

• Es müsste zunächst herausgefunden werden, wieviele “falsche” Warnmeldungen ausgelöst werden würden, weil in vielen Fällen kein Bearbeitungskonflikt entsteht, obwohl jemand anders die Seite inzwischen gespeichert hat. Ebenso, ob es wirklich mehr Leute ermutigen würde, die Bearbeitung nicht abzubrechen, als durch die bisherige Lösung.
• Der Hinweis sollte nicht in einer negativen, sondern positiven Form formuliert werden.

Ansicht, in der der Bearbeitungskonflikt gelöst wird:

• Die vorgeschlagene Lösung ist bei Weitem besser, als die bisherige Lösung
• Um mit der sonstigen Praxis übereinzustimmen, muss der neue Text auf der rechten, der alte Text auf der linken Seite sein (also umgekehrt, als im o.g. Vorschlag)
• Es gibt viele Dinge, die man zusätzlich/grundsätzlich tun könnte, um den Bearbeitungskonflikt-Algorythmus software-seitig zu verbessern. Es würden aber dennoch Fälle übrig bleiben, die software-seitig nicht gelöst werden könnten, was eine benutzerfreundlichere Lösungs-Ansicht auch langfristig sinnvoll macht.

Aus den Rückmeldungen bei der Wikimania und weiteren Diskussionen mit dem Team wurde ein neuer Prototyp entwickelt. Der neue Entwurf behält die parallele Ansicht von Texteditor und Änderungen bei, erlaubt es den Nutzern jetzt aber auch, sowohl die eigenen Änderungen als auch die Änderungen der anderen Person besser nachvollziehen zu können. Das Team arbeitet an einem klickbaren Prototyp, der demnächst hier verlinkt und genauer vorgestellt wird. Auf den Hinweis soll verzichtet werden, da zum einen 80% der Testenden den Hinweis nicht bemerkt hatten, zum anderen unklar ist, was der Hinweis auslösen würde (Verunsicherung, Falschmeldungen).

Prototypen-Test

Vorschlag für die neue Oberfläche zur Auflösung von Bearbeitungskonflikten (mit Javascript)

Aktuelle Oberfläche zur Auflösung von Bearbeitungskonflikten (Stand August 2016)

Basierend auf allen bisherigen Erkenntnissen gibt es einen neuen Prototypen, mit dem man sich die vorgeschlagene Änderung angucken kann. Das Team der Softwareentwicklung freut sich über Feedback!

Prototyp ausprobieren

Der Prototyp befindet sich hier. Der Prototyp ist eine Version für Nutzer, die kein Javascript haben. Mit Javascript gäbe es noch zusätzliche Hilfen, die man auf dem Screenshot an der Seite sehen kann.

Szenario:

Im Artikel zum Buchstaben C gibt es im Abschnitt “Herkunft” folgenden Satz:

Das C leitet sich von dem selben Buchstaben ab wie das G.

Zum Testen soll sowohl das C als auch das G in Anführungszeichen gesetzt werden. Dafür müsste neben dem Abschnitt "Herkunft" auf "Quelltext editieren" geklickt werden (Vorwarnung: Das Laden der neuen Seite dauert leider ein bisschen). Wer die Änderung im Prototypen durchführt, erfährt einen Änderungskonflikt.

Da der Prototyp die Änderungen am Ende nicht tatsächlich speichert, kann es sein, dass die angezeigte Konfliktlösung nicht der eigenen entspricht. Hoffentlich hilft der Prototyp trotzdem, ein besseres Gefühl für die geänderte Oberfläche zu vermitteln.

Neue Oberfläche ansehen

Wer sich einfach nur die geänderte Oberfläche angucken möchte, findet hier ein Beispiel.

Als Vergleich zur aktuellen Oberfläche ist ein Screenshot der aktuellen Bearbeitungskonfliktlösungsseite als Thumbnail beigefügt.

Unterschiede der Versionen mit und ohne Javascript

Der Prototyp präsentiert die Variante, die alle Nutzer sehen, die kein Javascript auf ihren Webseiten aktiviert haben. Dies ist die Basisversion für alle Nutzer. Mit Javascript würden zudem weitere Hilfen unterstützt: So könnte man im linken Textfeld wählen, ob man gerade die Version mit den eigenen Änderungen, die Version mit den Änderungen der anderen Person oder die Version, in der beide Änderungen eingeblendet sind, ansehen möchte. Zudem ist der nicht veränderte Text drum herum zunächst eingeklappt, und kann bei Bedarf ausgeklappt werden.

Feedback

Das Team der Softwareentwicklung freut sich über Feedback, entweder auf der Diskussionsseite dieser Seite oder auch sehr gerne im Austausch mit uns (Email). Idealerweise würdet ihr mit uns gemeinsam den Prototyp durchgehen, zum Beispiel via Google Hangouts, WebRTC oder Skype.

Update: Darstellung der Versionsunterschiede leicht geändert

Wir haben die Darstellung der Versionsunterschiede in der linken Spalte leicht geändert. Die neue Version ist näher an dem, wie Versionsunterschiede aktuell dargestellt werden. Die überarbeitete Version findet ihr unter dem obigen Link sowie hier Die vorherige Version kann man weiterhin hier sehen. Feedback, auch zur Änderung, ist weiterhin gerne gesehen!

Ergebnis des Prototypen-Feedbacks und weitere Schritte in der Entwicklung

Vielen Dank an alle, die den Prototypen kommentiert haben! Zeitgleich mit der Umfrage hier wurde auch die internationale Community um Feedback gebeten. Dies sind die Schlüsse, die das Team der Softwareentwicklung von Wikimedia Deutschland aus den beiden Umfragen und Gesprächen offline gezogen hat:

• Die große Mehrheit der Kommentatoren empfand die zweispaltige Editiermöglichkeit als sehr positiv.
• Die Möglichkeit, den eigenen Text zu kopieren, ohne weitere ungewünschte Zeichen (wie Plus und Minus) mitzukopieren, wurde zustimmend aufgenommen.
• Die farbliche Hervorhebung der geänderten Stellen im zu bearbeitenden Textfeld wurde auch positiv bewertet, es kam auch der Wunsch, geänderte Stellen auch innerhalb des Texteditors hervorzuheben.
• Ein Problem wurde vielfach darin gesehen, die geänderten Stellen zu finden, besonders wenn sie sich nicht am Anfang des Textes befinden.
• Eine weitere Herausforderung, die genannt wurde, besteht darin, drei verschiedene scrollbare Bereiche auf einer Seite zu vereinen. Dies könnte Schwierigkeiten bei der Nutzung eines Mausrads ergeben
• Es wurde der Wunsch geäußert, auch bei dieser Ansicht in den Visual Editor-Modus springen zu können

Basierend auf den Rückmeldungen hat sich das Team entschlossen, mit der Realisierung des Wunsches zu beginnen. Die neue Funktionalität wird zunächst als beta-Feature implementiert, damit sie gut testbar ist, bevor sie tatsächlich in Betrieb genommen wird. Die neue Seite zur Lösung des Bearbeitungskonflikts wird dem Prototypen ähnlich sehen. Außerdem wird angestrebt, dass sowohl das Textfeld als auch das Bearbeitungsfeld beim Öffnen der Seite automatisch zum ersten Bearbeitungskonflikt springen, sodass zumindest der erste Bearbeitungskonflikt nicht lange gesucht werden muss. Leider ist es technisch nicht mit angemessenem Zeitaufwand möglich, im Textfeld Stellen farblich zu markieren. Die Herausforderung, drei Bereiche gleichzeitig scrollen zu können, ist noch nicht gelöst, wir hoffen aber, dafür eine akzeptable Lösung zu finden. Da die aktuelle Möglichkeit für das Lösen von Bearbeitungskonflikten auch nicht für den Visual Editor funktioniert, wird im ersten Schritt die Quelltextvariante implementiert. Im zweiten Schritt ist es geplant, zu evaluieren, inwieweit es möglich ist, die Lösung für den Visual Editor anzupassen.

Erste Beta-Funktion

Erste Beta-Funktion

Screenshot der ersten Beta-Funktion, bei aktiviertem JavaScript

Seit Oktober 2016 wird an der technischen Umsetzung des neuen „Bearbeitungskonfliktassistenten“ gearbeitet. Die Funktion wurde im Februar 2017 zunächst als Beta-Funktion zur Verfügung gestellt, um sie ausgiebig testen und weiter verbessern zu können. Die Idee:

• Sobald ein Bearbeitungskonflikt auftritt, wird eine zweispaltige Bedienoberfläche angezeigt.
• In der linken Spalte sind die eigenen sowie die konfliktierenden Textpassagen in unterschiedlichen Farben hervorgehoben.
• Die Ansicht beider Spalten „springt“ zu Beginn automatisch zur ersten eigenen Bearbeitung, um das Auffinden des eigenen Textes einfacher zu machen.
• Textteile können von links in das Bearbeitungsfeld hinüber kopiert werden und der Text kann nach Belieben angepasst werden.
• Mit aktiviertem Javascript kann in der linken Spalte zusätzlich unbearbeiteter Text ausgeblendet oder nur der eigene Text angezeigt werden. Ebenfalls kann ausgewählt werden, ob im Texteditor die aktuell gespeicherte Version oder der eigene Text angezeigt werden soll.
• Mit Klick auf den Speichern-Button wird die Version gespeichert, die im rechten Bearbeitungsfeld zu sehen ist.

Testseite und Feedbackrunde zur Beta-Funktion

Seit dem 14.02.2017 konnte der Zwei-Spalten-Bearbeitungskonflikt hier in der Wikipedia als Beta-Funktion getestet werden. Die Beta-Phase ist ein wichtiger Schritt, um zu ermitteln, ob die neue Benutzeroberfläche als Standard-Funktion aktiviert werden kann oder ob es noch Änderungsbedarf gibt.

Für den Test mit einer Simulation fand vom 12. Oktober bis zum 9. November eine Feedbackrunde statt. Punkte, die mehrfach genannt wurden:

• Die eigenen Änderungen sind schwer zu finden.
• Es ist nicht klar, in welchem Feld die Version editiert wird, die veröffentlicht werden soll.
• Das Zusammenfügen der beiden kollidierenden Versionen sollte leichter sein.
• Die Auswahl der Basisversion ist zu umständlich.

Dazu kamen mehrere einzeln genannte Probleme, viele konkrete Verbesserungsvorschläge und auch positive Stimmen zur Benutzeroberfläche, etwa dass durch die Zweispaltigkeit nun weniger gescrollt werden muss.

Prototyp für einen zeilenbasierten Ansatz

Prototyp des neuen Absatzes

Mit den Rückmeldungen und Verbesserungsvorschlägen aus der Feedbackrunde Ende 2017 wurde ein neuer Ansatz für die Lösung von Bearbeitungskonflikten entwickelt und vom 12.02. bis 12.03.18 in einer Feedbackrunde auf der deutschsprachigen Wikipedia und auf Meta (Englisch) getestet. Während die bisherige Beta-Funktion den zu speichernden Text als Gesamttext in einer Spalte anzeigt, stellt der neue Ansatz Konfliktstellen separat voneinander dar, was die Übersichtlichkeit und Orientierung verbessern soll.

Feedbackrunde zum Prototypen

• Die Kernidee, die anhand des Prototyps getestet werden konnte, trifft insgesamt auf hohe Zustimmung. Sowohl hierzuwiki als auch auf Meta fand eine klare Mehrheit den neuen Ansatz intuitiv, benutzerfreundlich und gut geeignet, um Bearbeitungskonflikte schnell zu lösen. Damit gehen die Rückmeldungen aus dieser Runde in dieselbe Richtung wie die Erkenntnisse aus Nutzertests, in denen Autorinnen und Autoren ganz unterschiedlicher Erfahrungsstufen den neuen Ansatz ausprobiert haben.
• Einige Probleme und Verbesserungsideen wurden aufgezeigt (s. Nächste Schritte).

Nächste Schritte

Ziel der letzten Monate war es, herauszufinden, ob der neue Ansatz grundsätzlich eine Verbesserung darstellt. Dies wurde für uns positiv beantwortet. Um aus dem Prototyp ein richtiges Produkt zu erstellen, wird sich das Projektteam, basierend auf den Ergebnissen von Nutzertests und Feedbackrunden, folgenden Aufgaben widmen:

• Verbesserung der Barrierefreiheit
• Möglichkeit, nicht konfliktierende Absätze zu bearbeiten (graue Absätze)
• Überarbeitung der Hinweisboxen

Weiterhin wird das Team sich mit der Frage beschäftigen, wie angezeigt werden kann, dass ein Absatz bearbeitbar ist, wenn noch keine Auswahl erfolgt ist. Und auch weitere einzeln genannte Aspekte werden in der Entwicklung des Produkts Beachtung finden. Ein großes Dankeschön an alle, die in dieser neuen Feedbackrunde ihre Einschätzung abgegeben haben.

Lösung: Abschnittsbasierte Bearbeitungskonflikt Oberfläche

Früherer Name: Zwei-Spalten Bearbeitungskonflikt Oberfläche

Das Team Technische Wünsche bei Wikimedia Deutschland hat eine neue Oberfläche für das Auflösen von Bearbeitungskonflikten entwickelt. Der Algorithmus zum erkennen ob ein Bearbeitungskonflikt aufgetreten ist, oder ob dieser automatisch zusammengeführt werden kann, wurde dabei nicht verändert. So funktioniert die neue Oberfläche:

Kurz zusammengefasst

Die neue Oberfläche hat zum Ziel, den eigenen Text mit jener Version zusammenzuführen, die gerade online ist. Sie schlüsselt die Unterschiede zwischen den beiden Textversionen visuell wie folgt auf:

• Textpassagen, die sich unterscheiden, werden paarweise nebeneinander angezeigt: Die aktuelle Version der Seite wird gelb und die eigene Version blau dargestellt. Innerhalb der Texte werden die geänderten Stellen farbig hervorgehoben.
• Textpassagen, die in beiden Versionen identisch sind, werden als grauer Balken über die gesamte Breite dargestellt.

Wie man einen Bearbeitungskonflikt löst

1. Für jedes Textpaar die Version auswählen, die man behalten möchte.
2. Den ausgewählten Text bearbeiten. Damit kann man eventuell vorhandene Änderungen der anderen Version mit einpflegen.
3. Änderungen veröffentlichen. Es wird eine neue Version der Seite erstellt, die alle ausgewählten sowie die grauen Texte kombiniert.

• 
  So sieht die neue Oberfläche aus. (Der Screenshot ist vom März 2020, aufgenommen auf einem Testserver. Deshalb gibt es im Screenshot nur die Schaltflächen „Veröffentlichung der Änderungen simulieren“ und „Abbrechen“.)

Schritt für Schritt

 Info: Dieser Abschnitt beschreibt die JavaScript-Version der Oberfläche. Hier ist beschrieben, wie die Version ohne JavaScript funktioniert.

1. Orientierung

Beim ersten Bearbeitungskonflikt mit der neuen Oberfläche erklärt ein Tutorial deren Funktionsweise. Dieses Tutorial kann man auch später durch Anklicken des Hilfesymbols (?) wieder aufrufen.

Die Oberfläche stellt die Unterschiede zwischen den beiden Versionen wie folgt dar:

• Textpassagen, die sich unterscheiden, werden paarweise nebeneinander angezeigt: Die aktuelle Version der Seite wird gelb und die eigene Version blau dargestellt. Innerhalb der Texte werden die geänderten Stellen farbig hervorgehoben.
• Textpassagen, die in beiden Versionen identisch sind, werden als grauer Balken über die gesamte Breite dargestellt.
• Wenn man seine Version (nur die eigene Bearbeitungen) der Artikelseite kopieren möchten, klicken man auf den Link 'Volltext kopieren' neben der blau markierten Überschrift 'Deine Version' im oberen Teil der Oberfläche.

2. Änderungen zusammenführen

Ausgewählte Textbox, mit einem schwarzen Stift, um den Bearbeitungsmodus zu beginnen

Textbox im Bearbeitungsmodus, mit Häkchen und Zurück-Pfeil

• Die Textpassagen auswählen, die übernommen werden sollen, durch Klicken auf die entsprechenden Auswahlknöpfe in der Mitte. Standardmäßig wird keine der beiden Textpassagen ausgewählt.
• Passagen bearbeiten, wenn nötig.
  • Der Bearbeitungsmodus für eine Textstelle öffnet sich, wenn man auf den schwarzen Stift klickt. Wenn der Stift grau ist, bedeutet das, dass die Textpassage zuerst ausgewählt werden muss. Andernfalls wird diese Version bei Klick auf „Änderungen veröffentlichen“ nicht gespeichert.
  • Es können auch Textpassagen bearbeitet werden, die in beiden Versionen identisch sind.
  • Die Hervorhebungen, die die Unterschiede zwischen den Versionen anzeigen, verschwinden, wenn eine Textpassage bearbeitet wird.
  • Teile aus anderen Textpassagen können durch Kopieren und Einfügen integriert werden, entweder mit der Kopier- und Einfügefunktion auf der Tastatur oder per Rechtsklick.
  • Wenn man auf das Häkchen klickt, werden Änderungen in einem Textfeld übernommen und dessen Bearbeitungsmodus verlassen.
  • Mit dem Zurück-Pfeil werden Änderungen innerhalb eines Textfeldes verworfen und dessen Inhalt wird auf den Zustand zurückgesetzt, in dem es zum Zeitpunkt des Bearbeitungskonflikts war. Dadurch wird auch die farbige Hervorhebung wiederhergestellt.

3. Eine neue Seitenversion veröffentlichen

Um eine neue Seitenversion zu erzeugen, klickt man nach Auswahl und Bearbeitung der Textstellen auf „Änderungen veröffentlichen“. Dadurch wird aus allen ausgewählten und aus den grauen Textboxen eine neue Seitenversion erzeugt. Wie bei allen Wikiseiten gibt es die Möglichkeit einer Vorschau über die Schaltfläche „Vorschau zeigen“. Durch Klick auf „Abbrechen“ gelangt man zur aktuellen Seitenversion.

Nicht-JS-Version

Für alle, die kein JavaScript verwenden, ändert sich die Oberfläche im Vergleich zu oben beschrieben wie folgt:

• Alle Textabschnitte werden im Bearbeitungsmodus angezeigt.
• Es gibt keine Schaltflächen (Häkchen, Zurück-Pfeile) innerhalb der Textboxen.
• Identische Textabschnitte sind immer ausgeklappt.

Wie die neue Oberfläche ausgeschaltet werden kann

Bildschirmfoto der Einstellungen, um die Abschnittsbasierte Bearbeitungskonflikt Oberfläche zu deaktivieren.

Wer als angemeldeter Benutzer an der bisherigen Arbeitsweise festhalten möchte, kann die Abschnittsbasierte Bearbeitungskonflikt Oberfläche für sich selbst deaktivieren. Die folgenden Schritte sind dafür auszuführen:

• 'Einstellungen' auswählen (oder vorstehenden Link benutzen).
• Nun unter Bearbeiten das Häkchen bei Abschnittsbasierte Bearbeitungskonflikt Oberfläche entfernen (siehe Bild).

Die Oberfläche lässt sich wieder aktivieren, indem ein Häkchen in dem Kästchen an derselben Stelle gesetzt wird.

Nicht angemeldete Benutzer („IP“) haben keinerlei Möglichkeit, der Software zu entgehen, außer JavaScript komplett für die gesamte Wikipedia-Nutzung zu deaktivieren. Selbst das löst vermutlich nicht alle Probleme.

Bearbeitungskonflikte auf Diskussionsseiten

Für Diskussionsseiten gibt es seit dem 24. Juni 2020 eine spezielle Oberfläche für Bearbeitungskonflikte.

Diese Ansicht wird gezeigt, wenn ich auf einer Diskussionsseite schreibe, während eine andere Person einen Diskussionsbeitrag im selben Abschnitt verfasst und vor mir abspeichert. Für alle anderen Bearbeitungskonflikte auf Diskussionsseiten wird die allgemeine Bearbeitungskonflikt-Oberfläche (siehe oben) angezeigt.

Wie sieht die Oberfläche aus?

Ich schreibe einen Kommentar auf einer Diskussionsseite. Gleichzeitig editiert eine andere Person genau diese Zeile auf der Diskussionsseite. Es kommt zu einem Bearbeitungskonflikt, und mir wird die spezielle Bearbeitungskonflikt-Oberfläche für Diskussionsseiten gezeigt. In dieser speziellen Oberfläche werden nur die den Konflikt auslösenden Kommentare hervorgehoben, sodass ich mich besser auf den Bearbeitungskonflikt selbst konzentrieren kann. Der Rest der Seite ist in grauen Kästen eingeklappt. Der Kommentar der Person, mit der ich den Bearbeitungskonflikt habe, wird in einem gelben Kasten angezeigt, mein eigener Kommentar in einem blauen Kasten. Beide Kommentare werden im Wikitext (nicht im visuellen Editor) angezeigt.

• 
  Beispiel-Screenshot der Oberfläche für Bearbeitungskonflikte auf Diskussionsseiten. Der den Konflikt auslösende Kommentar wird in dem gelben Kasten angezeigt. Der eigene Kommentar wird in dem blauen Kasten angezeigt.

Wie man einen Bearbeitungskonflikt löst

Um einen Bearbeitungskonflikt auf einer Diskussionsseite zu lösen, habe ich folgende Möglichkeiten:

• den eigenen Kommentar bearbeiten. (Hinweis: Man kann den Kommentar der Person, mit der man den Bearbeitungskonflikt hat, nicht bearbeiten.)
• die Einrückung manuell durch Doppelpunkte anpassen, wie es auch normal auf Diskussionsseiten funktioniert.
• die Reihenfolge der Kommentare ändern, indem ich auf die Schaltfläche mit den zwei in entgegengesetzte Richtungen deutenden Pfeile klicke. Diese ist links der Textfelder zwischen den Markierungen “Eigener Kommentar” und “Anderer Kommentar“.

Als letzten Schritt kann ich:

• die von mir vorgenommenen Änderungen einreichen (Änderungen veröffentlichen),

→ Damit wird der Bearbeitungskonflikt gelöst. Der eigene Text und der Text der anderen Person werden der Diskussionsseite hinzugefügt.

• mir eine Vorschau anzeigen lassen, wie die gesamte Diskussionsseite mit meinen Änderungen aussehen würde (Vorschau zeigen), oder
• den gesamten Vorgang abbrechen (Abbrechen).

→ Bitte beachten, dass der eigene Text nicht auf der Seite gespeichert wird, wenn ich auf „Abbrechen“ klicke. Damit kehre ich zur anfänglichen Diskussionsseite zurück.

Nicht-JS-Version

Die zusätzliche Oberfläche für Bearbeitungskonflikte für nicht JavaScript-Nutzende funktioniert zu großen Teilen gleich wie die Oberfläche für Nutzende, die JavaScript eingeschaltet haben. Die den Konflikt auslösenden Diskussionsbeiträge werden hervorgehoben angezeigt. Der eigene Diskussionsbeitrag wird blau umrahmt angezeigt, der den Konflikt auslösenden Beitrag wird gelb umrahmt angezeigt.
Der Unterschied zur JS-Version der Seite ist, dass die Reihenfolge der Diskussionsbeiträge nicht über die zwei Pfeile links der Textfelder geändert werden kann. Um die Reihenfolge in der nicht-JS-Version der Seite zu ändern, muss unterhalb des grauen, eingeklappten Textfeldes ausgewählt werden, ob der eigene Beitrag oberhalb oder unterhalb des den Konflikt auslösenden Beitrags eingefügt werden soll. Die Einrückung der Beiträge kann mithilfe von Doppelpunkten (:) vorgenommen werden.

Mehrere (drei oder mehr) Bearbeitungskonflikte auf Diskussionsseiten lösen

Wenn drei oder mehr Personen dieselbe Zeile einer Gesprächsseite gleichzeitig bearbeiten, kommt es zu mehreren Bearbeitungskonflikten. Diese müssen nacheinander gelöst werden.

Zeitplan

Abschnittsweise Bearbeitungskonflikt Oberfläche

Erste Beta-Funktion

• Mediawiki.org: 6. Februar 2017 erledigtErledigt
• Meta: 13. Februar 2017 erledigtErledigt
• dewiki: 14. Februar 2017 erledigtErledigt
• arwiki: 21. Februar 2017 erledigtErledigt
• hewiki: 23. Februar 2017 erledigtErledigt
• fiwiki: 12. April 2017 erledigtErledigt
• Alle anderen Wikis: 10. Mai 2017 erledigtErledigt

Neue Beta-Funktion

• Aktivierung auf allen Wikis: 6-8. November 2018 erledigtErledigt

Als Standardfunktion auf

• dewiki: 25. März 2020 erledigtErledigt
• arwiki: 25. März 2020 erledigtErledigt
• fawiki: 25. März 2020 erledigtErledigt

Bearbeitungskonflikt Oberfläche für Diskussionsseiten

Als Standardfunktion auf

• dewiki: ab 24. Juni 2020 erledigtErledigt
• arwiki: ab 24. Juni 2020 erledigtErledigt
• fawiki: ab 24. Juni 2020 erledigtErledigt

Keine weiteren Arbeiten an der Funktion

Die vorliegende Funktion wird noch auf weiteren Wikimedia-Wikis bereitgestellt. Ansonsten wird an diesem Projekt nicht weiter gearbeitet, denn der Fokus der Technischen Wünsche wird künftig auf die Arbeit in Themenschwerpunkten gesetzt (mehr Informationen dazu hier).

Es ist uns bewusst, dass die Oberfläche in ihrem jetzigen Zustand leider noch nicht für alle Anwendungsfälle ideal nutzbar ist und dass es noch Verbesserungswünsche gibt. Hier nachzubessern würde allerdings bedeuten, dass wir die Oberfläche nochmal grundsätzlich überarbeiten müssten, was sehr umfangreich wäre. Daher haben wir die Entscheidung getroffen, nicht weiter an dieser Funktion zu arbeiten. Ausgenommen sind nur die Behebung schwerwiegender Fehler (etwa Datenverlust, der durch die Funktion verursacht wird) sowie Fehler, bei denen die Oberfläche sich nicht so verhält wie vorgesehen. Wenn das Team Technische Wünsche in Zukunft das Lösen von Bearbeitungskonflikten weiter verbessern soll, müsste in einer der zukünftigen Umfragen ein entsprechender Themenschwerpunkt gewählt werden.

Links

• Die Aufgabenliste auf Phabricator
• Die (englischsprachige) Hilfeseite und die zentrale Feedbackseite für Fehlermeldungen und Verbesserungsvorschläge zur Beta-Funktion auf Mediawiki.org