Diese Seite dient der Dokumentation von Entwicklungsverlauf, Recherche und Diskussionen rund um den Wunsch „Bessere Lösung von Bearbeitungskonflikten“. Anmerkungen und Fragen gerne auf der Diskussionsseite!
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)
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.
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:
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.
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.
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).
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.
Kommentare zum Prototypen
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!
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.
Screenshot der Beta-Funktion „Zwei-Spalten-Bearbeitungskonflikt“ bei aktiviertem JavaScript
Seit Oktober 2016 wird an der technischen Umsetzung des neuen "Bearbeitungskonfliktassistenten" gearbeitet. Die Funktion wird derzeit als Beta-Funktion zur Verfügung gestellt, um sie ausgiebig testen und weiter verbessern zu können.
Sobald ein Bearbeitungskonflikt auftritt, wird eine zweispaltige Bedienoberfläche angezeigt: Der neue Bearbeitungskonfliktassistent. 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. Mit aktiviertem Javascript kann zusätzlich unbearbeiteter Text ausgeblendet oder nur der eigene Text angezeigt werden.
Um die neue Ansicht für Bearbeitungskonflikte zu aktivieren, müssen Nutzer angemeldet sein und die Funktion „Zwei Spalten Bearbeitungskonflikt“ in den eigenen Einstellungen aktivieren.
Wann immer bei einer Bearbeitung ein Bearbeitungskonflikt auftritt, erscheint nun die zweispaltige Ansicht.
In der linken Spalte werden die Änderungen angezeigt, die den Bearbeitungskonflikt verursachen und in der rechten Spalte ein Bearbeitungsfeld mit der derzeitig gespeicherten Version.
In der linken Spalte werden sowohl die eigene als auch die Bearbeitung des anderen Nutzers angezeigt. Beide Änderungen sind farblich hervorgehoben.
Wenn Javascript aktiviert ist, gibt es über der Ansicht die Möglichkeit, die Teile des Quelltextes, die sich nicht verändert haben, zu verstecken. Ebenfalls kann ausgewählt werden, ob im Texteditor die aktuell gespeicherte Version oder der eigene Text angezeigt werden soll. Es ist sinnvoll, im editierbaren Feld die Textversion anzeigen zu lassen, in der die meisten Änderungen gemacht wurden.
Weitere gewünschte Textteile können in das Bearbeitungsfeld hinüber kopiert werden und der Text kann nach Belieben angepasst werden.
Mit Klick auf den "Speichern"-Button wird die Version im rechten Bearbeitungsfeld gespeichert.
Feedbackrunde: Testen der neuen Funktion mit Simulation von Bearbeitungskonflikten (12. Oktober bis 9. November)[Bearbeiten | Quelltext bearbeiten]
Seit dem 14.02.2017 kann 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. Weil Bearbeitungskonflikte aber selten vorkommen, gibt es bislang erst wenige Rückmeldungen. Um ein einfacheres Ausprobieren der neuen Benutzeroberfläche zu ermöglichen und so mehr Feedback zu erhalten, wurde eine Testseite aufgesetzt, mit der man Bearbeitungskonflikte unter echten Bedingungen und mit echten Wikiseiten gefahrlos simulieren kann, ohne dass diese Änderungen tatsächlich abgespeichert werden.
Für den Test mit dieser Simulation gab es vom 12. Oktober bis zum 9. November eine Feedbackrunde. 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.
Anhand dieser Rückmeldungen arbeitet das Team nun an einem Prototyp für einen anderen Ansatz. Wann dieser getestet werden kann, wird hier bekannt gegeben.
