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

Hier wird die erste Idee in zwei Varianten vorgestellt. Zur zweiten Idee gehts hierlang: Vorschlag B.

Vorschlag A zur möglichen Umsetzung des Wunsches: Bessere Lösung von Bearbeitungskonflikten

Das Team bei WMDE möchte mit der Umsetzung des Wunsches „Bessere Lösung von Bearbeitungskonflikten“ beginnen. Aus den bisherigen Kommentaren während der Umfrage wurden zwei erste – grobe – Ideen skizziert. Feedback dazu ist wichtig, um genauer sehen zu können, in welche Richtung es gehen kann und was auf keinen Fall gemacht werden sollte. Vorschlag A beinhaltet kleinere Änderungen in zwei Varianten und die bisherige Benutzeroberfläche bleibt weitestgehend erhalten. Vorschlag B würde die bisherige Benutzeroberfläche deutlich verändern. Das Team freut sich über zahlreiche Rückmeldungen. Vielen Dank für die Teilnahme! --Birgit Müller (WMDE) (Diskussion) 20:22, 11. Mai 2016 (CEST)

Der Wunsch in der Umfrage: Bessere Lösung von Bearbeitungskonflikten (39 Stimmen, Platz 1)

Konkretisierung: 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.

Die bisherige Idee

Bild 1: Die aktuelle Situation

Bild 1 zeigt die aktuelle Situation während eines Bearbeitungskonflikts. Bislang sieht man im Konflikt-Bearbeitungsmodus oben ein Textfeld mit der bisher gespeicherten Version, darunter eine Ansicht, die die zwei Versionen vergleicht und darunter das Textfeld mit der eigenen Version. Dadurch wird viel Text doppelt angezeigt, und es ist aufwändig, die eigenen Textabschnitte im unteren Textfeld zu finden und nach oben zu kopieren. Das wollen wir ändern, indem wir das untere Textfeld weg nehmen und stattdessen die Vergleichsansicht verbessern: Es soll einfacher werden, die eigenen neuen Abschnitte aus der Vergleichsansicht zu kopieren, zum Beispiel, indem ein Klick auf die Buchstaben gleich den ganzen Abschnitt markiert. Außerdem sollen die Minus- oder Pluszeichen am Rand nicht mit markiert werden. Damit man immer noch die Möglichkeit hat, den Artikelkontext zu sehen, soll es in der neuen Version möglich sein, in der Standardansicht ausgelassene Artikelbestandteile einzublenden.

Bild 2 zeigt den eben beschriebenen Vorschlag (Variante A1):

Bild 2: Variante A1

Links an der Seite sieht man nun Symbole, die es einem erlauben, weiteren (von Keinem geänderten) Artikelinhalt anzeigen zu lassen. Wenn man den Text einklappt, klappt er sich automatisch sowohl bei der eigenen Spalte als auch bei der rechten Spalte ein. Die Arbeitsschritte wären nun folgende: Man kopiert aus der linken Spalte der Vergleichsansicht alles heraus, was man von seiner Version behalten möchte, und fügt es in dem darüber liegenden Textfeld ein. Variante A1 verringert zwar den angezeigten, doppelten Text, aber man könnte immer noch argumentieren, dass die rechte Spalte eigentlich fast das gleiche anzeigt, wie das obere Textfeld. Deswegen gibt es noch Variante A2.

Bild 3 zeigt Variante A2:

Bild 3: Variante A2

Anstelle oberhalb der Vergleichsansicht das Textfeld zu haben, ersetzt das Textfeld die rechte Spalte der Vergleichsansicht. Die während des Editierens von anderen getätigten Änderungen werden nun auch in der linken Spalte dargestellt, aber wie auch vorher, durch eine andersfarbige Unterlegung als solche gekennzeichnet. Da die rechte Spalte jetzt ein Textfeld ist, wird der Text der beiden Spalten nicht mehr parallel verlaufen. Wie auch in Variante A1, kann man in Variante A2 den eigenen Text leichter kopieren und ausgelassenene Artikelabschnitte einblenden, um den Kontext besser zu verstehen.

Die Arbeitsschritte wären nun folgende: Man kopiert aus der linken Spalte die eigenen Abschnitte, die man behalten möchte und fügt sie in den Text in der rechten Spalte ein.

Anmerkungen zu Vorschlag A

Was ist gut an dem Vorschlag

• Ohne mich in den Vorschlag hinein gedacht zu haben: "Außerdem sollen die Minus- oder Pluszeichen am Rand nicht mit markiert werden." Wenn wir das generell für jeden Versionsvergleich machen würden, wäre das super, egal, wie die Diskussion ausgeht! --Flominator 12:00, 12. Mai 2016 (CEST)

  Genau. Das ist das wichtigste. Ich ärgere mich jedesmal wieder, dass ich den von mir geschriebenen Text nicht einfach als Block kopieren kann. Ich glaube mit dem Zeilenumbrüchen gibt es in dem Zusammenhang aktuell auch Probleme. Generator (Diskussion) 12:15, 12. Mai 2016 (CEST)

  In jedem Fall Zustimmung, was das angeht; die Markierung von +/- ist ein reines Ärgernis. --94.219.30.87 14:53, 12. Mai 2016 (CEST)

• Zustimmung zu meinen beiden Vorrednern. Das wäre auch unabhängig vom Bearbeitungskonflikt eine schöne Erleichterung. -- hgzh 13:34, 12. Mai 2016 (CEST)
• + --MGChecker – (📞| 📝| ) 18:35, 13. Mai 2016 (CEST)
• Auch von mir starke Zustimmung zu dem Punkt – das wäre auch bei gewöhnlichen Versionsvergleichen eine große Erleichertung. Gegenargumente fallen mir keine ein. Yellowcard (D.) 11:39, 14. Mai 2016 (CEST)
• +1 zu dem Ignorieren der +/-Zeichen beim kopieren. // Martin K. (Diskussion) 19:41, 17. Jun. 2016 (CEST)

Was könnte besser sein

• Hört sich für mich immer noch zu kompliziert an, oder ich habe die Verbesserungen nicht ganz verstanden. Ich bevorzuge Variante B. --GodeNehler (Diskussion) 10:37, 12. Mai 2016 (CEST)
• Dass beim Kopieren von Versionsunterschieden die Plus- und Minuszeichen mitkopiert werden, ist ja nur ein Grund, warum das Lösen von Bearbeitungskonflikten aus der Diff-Ansicht heraus schwierig ist. Ebenso problematisch ist, dass sich die Absätze mit den beiden Versionen abwechseln. In Variante A1 könnte man dem Browser eventuell noch mit einigen Mühen ein spaltenweises Kopieren beibringen, in Variante A2 ginge das nicht mehr. Im Endeffekt läuft es aber darauf hinaus, dass man jeden Abschnitt einzeln kopieren muss. Dann kann man aber auch einfach darauf achten, das Plus- oder Minuszeichen nicht mitzukopieren. Damit ergäbe sich kein nennenswerter Vorteil gegenüber der jetzigen Situation. --Schnark 10:43, 13. Mai 2016 (CEST)

  @Schnark: Wenn ich mir die Demo zu dieser Antwort so anschaue, sollte das spaltenweise Auswählen gar nicht so ein Drama sein. Könnte man das vielleicht sogar als Benutzerskript realisieren? Was meint denn PerfektesChaos dazu? --Flominator 11:08, 13. Mai 2016 (CEST)

  Die Number-Spalte in der Demo funktioniert so wie sie soll, bei der Letter-Spalte wird aber – egal wie viel ich markiere – nur die erste Zeile plus vier Leerzeichen kopiert (aktueller Firefox). user-select: none führt auch sonst gerne zu zu vielen Leerzeichen/Zeilenumbrüchen, die hier natürlich noch störender wären als sonst. Zudem müssen natürlich auch Benutzer ohne JS (oder einfach nur mit alten Browsern) in der Lage sein, Bearbeitungskonflikte zu beheben. --Schnark 11:24, 13. Mai 2016 (CEST)

  @Schnark, Generator, MGChecker, Hgzh, Yellowcard: Gerade mal geschaut. Wenn ich im Firefox 43.0.3. STRG gedrückt halte, kann ich tatsächlich die ganze Spalte aus dem Diff ohne Plus markieren und kopieren. Leider gehen dort tatsächlich die Absätze zwischen den Zeilen/Kästen verschütt. Vielleicht könnte man da ja jeweils noch einen br hineinskripten? --Flominator 13:26, 25. Mai 2016 (CEST) Nachtrag: Habe es mal exemplarisch implementiert reingehackt und scheint erst mal zu funktionieren. Allerdings braucht mal newline und keinen br.

• Abgesehen von den nervigen Minuszeichen sehe ich hier auch keine wirkliche Verbesserung gegenüber dem Status Quo, weil immer noch alles manuell von unten nach oben kopiert werden muss.
  Meines Erachtens ist das nevigste beim Mergen von Bearbeitungskonflikten, dass finden der jeweils richtigen Stellen innerhalb des Quelltextes. Es würde daher am meisten Arbeit und Nerven sparen, wenn man die jeweiligen Abschnitte einfach mit einem Klick auf einen Pfeil nach rechts (ähnlich wie man das von diversen IDEs gewöhnt ist) in die rechte Spalte und an die richtige Stelle des Quelltextes kopieren könnte. Und so ein Verhalten sollte sich doch eigentlich allein mit JavaScript implementieren lassen, ohne (wie in Version B) irgendwelche serverseitigen Speichervorgänge dazwischen schalten zu müssen?! // Martin K. (Diskussion) 19:53, 17. Jun. 2016 (CEST)

Was sollte auf keinen Fall gemacht werden

• Ich stelle es mir jetzt spontan schwierig vor, mit einem halben Diff alle überschneidenden Änderungen zu erfassen. Daher erstmal eher ablehnend zu Variante A2. -- hgzh 13:34, 12. Mai 2016 (CEST)

Hallo hgzh, was wäre da konkret schwieriger? Meinst du in Bezug auf Übersichtlichkeit? Vielen Dank, --Birgit Müller (WMDE) (Diskussion) 12:24, 13. Mai 2016 (CEST)

Hallo Birgit, ja, mir geht es da um die Übersichtlichkeit. Wenn ich rechts nur noch ein Textfenster habe, das logischerweise nicht 1:1 wie der Diff ausgerichtet sein kann, habe ich gerade bei größeren Überschneidungen Bedenken dazu, dann noch alle geänderten Stellen erfassen zu können. Gruß, -- hgzh 20:02, 17. Mai 2016 (CEST)

Okay, danke! --Birgit Müller (WMDE) (Diskussion) 12:33, 18. Mai 2016 (CEST)

• Ich stell es mir ziemlich nervig vor, wenn bei jedem Click gleich der gesamte Absatz markiert wird. Das ist zum einen ein ziemlich ungewohntes Verhalten und zum anderen will man manchmal ja wirklich nur Teile kopieren. // Martin K. (Diskussion) 19:44, 17. Jun. 2016 (CEST)

Offene Fragen

• Bisher klicke ich meist in "meinen Text", drücke STRG+A und füge ihn komplett oben ein, bevor ich die Änderungen des vorherigen Bearbeiters nachziehe. Würde das mit diesem Vorschlag noch immer gehen? --Flominator 12:02, 12. Mai 2016 (CEST) PS: Mir reicht das Feature so, wie es momentan implementiert ist. Meinetwegen ist keine Änderung nötig.
  • Das entspricht genau meiner Vorgehensweise. Wenn man in einen Bearbeitungskonflikt außerhalb von Diskussionsseiten reinrennt, ist eben wahrscheinlich die Situation am häufigsten, dass man selbst jede Menge geändert hat, während der konfllikterzeugende Benutzer nur eine kleine Änderung vorgenommen hat. (Von daher wäre es fast am hilfreichsten, die Felder Dein Text und Aktueller Text mit allen Funktionen komplett zu tauschen… --MGChecker – (📞| 📝| ) 18:40, 13. Mai 2016 (CEST)
    • Wenn der andere nur wenig geändert hat, kopiere ich den gesamten von mir bearbeiteten Abschnitt in ein neues Fenster und pflege seine Änderung ein. Wenn meine Änderungen eher kompakt sind, mache ich den zwischenzeitlich geänderten Abschnitt neu auf und kopiere meine Änderung dazu. --188.107.206.220 20:01, 13. Mai 2016 (CEST)

• Ehrlich gesagt kann ich mir keine der geschilderten Varianten bildhaft vorstellen, die Erklärungen verwirren mich eher. Kann man nicht einfach den hinzugefügten Text in der Vorschau anzeigen, auf diesen hinzugefügten Text irgendwo mittels Markierung hinweisen und dann den Nutzer fragen, ob er seinen Beitrag ohne zusätzliche Änderung eins darunter abspeichern oder noch einmal überarbeiten möchte? So in etwas mache ich das derzeit händisch. --94.219.30.87 15:06, 12. Mai 2016 (CEST)

Hallo, das ist ein sehr interessanter Ansatz, danke für den Vorschlag! Um dein aktuelles Vorgehen bisher noch besser zu verstehen, könntest du dir vorstellen, mit Jan (unserem Experten für Benutzerfreundlichkeit und Design) in Kontakt zu treten? Lea Voget (WMDE) (Diskussion) 12:50, 13. Mai 2016 (CEST)

@Lea Voget (WMDE): Hallo Lea, ich versuche demnächst mal, Jan deswegen zu kontaktieren. --188.107.206.220 18:36, 13. Mai 2016 (CEST)

Super, danke dir! Lea Voget (WMDE) (Diskussion) 10:24, 20. Mai 2016 (CEST)

@Lea Voget (WMDE): Ich hatte Jan noch am selben Tag (13.05.2016 um 18:48) eine Email geschrieben, habe aber keine Antwort erhalten. --88.69.255.95 15:20, 22. Mai 2016 (CEST)

Die Mail wurde von meinem Mailprogramm leider falsch gefiltert. Ich habe jetzt geantwortet – tut mir leid, dass du warten musstest. --Jan Dittrich (WMDE) (Diskussion) 15:55, 24. Mai 2016 (CEST)

• Geht mir genauso. Ich kenne das Problem aus der Softwareentwicklung, wenn man z.B. mehrere Branches (in Mercurial oder git) zusammenmergen muss. Das Tool meiner Wahl ist da kdiff3. Das macht einen sogenannten 3-Wege-Merge (also man sieht oben 3 Versionen: Die eigene, die fremde und die gemeinsame Vorgängerversion, so dass man klar sehen kann, wo wer was geändert hat) und kann damit viele scheinbare Bearbeitungskonflikte automatisch(!) lösen. Da Automatismen natürlich bisweilen falsch entscheiden, zeigt das Tool einem diese automatisch gelösten Konflikte (incl. dem automatisch gewählten Lösungsvorschlag) weiterhin an, und bietet einem die Möglichkeit, diese zu akzeptieren oder zu ändern. Ebenso kann man per Button durch alle noch ungelösten Konflikte navigieren und die oft mit 1 Mausklick, oder einer manuellen Bearbeitung der Stelle lösen. Alle Lösungsansätze, die mit nur 2 Ansichten (plus der neuen) arbeiten, finde ich deutlich unübersichtlicher. --RokerHRO (Diskussion) 16:56, 12. Mai 2016 (CEST)

@RokerHRO: Vorschlag B ist vom Vorgehen in der Software-Entwicklung bei Merge-Konflikten inspiriert, käme das für dich eher hin, oder was würde da anders/zusätzlich Sinn machen? (Kommentar gerne dort) - vielen Dank, --Birgit Müller (WMDE) (Diskussion) 12:10, 13. Mai 2016 (CEST)

Nein, Vorschlag B ist ja nur ein 2-Wege-Merge. Bei Bearbeitungskonflikten braucht man aber kein 3-Wege-Merge und die Möglichkeit, manuell die Merge-Version zu erstellen, da der Merge eben kein "algorithmisch errechenbarer Stand" ist.

Darum mein Verweis auf das Programm kdiff3, das leider keinen WP-Artikel hat und ich hab auch leider grad keinen geeigneten Screenshot parat. --RokerHRO (Diskussion) 14:54, 29. Mai 2016 (CEST)

Alles klar, danke für die Erläuterung! --Birgit Müller (WMDE) (Diskussion) 10:54, 3. Jun. 2016 (CEST)

• @Birgit Müller (WMDE): Das auf den Screenshots sieht mir mehr nach einem funktionierenden Protoyp aus, als nach einem Mockup. Könnt ihr das nicht irgendwo mal hochladen, damit man es sich anschauen/erleben kann? Gruß, --Flominator 17:02, 12. Mai 2016 (CEST)

@Flominator: ist leider kein funktionierender Prototyp - das ist mit Krita gemacht (digitales Malprogramm & einfache Bildbearbeitung), d.h. da ist nichts "klickbar" bzw. erlebbar. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 18:52, 12. Mai 2016 (CEST)

Lösung sucht Problem? Erfahrungsgemäß werden „Verbesserungen“ in EDV-Problemen nur von den Entwicklern als solche gesehen looool. Meine Vorgangsweise in BKs: ein Klick - öffnen eines neuen Fensters/Reiters (im Internet-Explorer). Im (alten) Fenster mit dem BK meinen Text (der gelöscht werden zu droht) markieren und mit Strg+C kopieren und mit Strg+V im neuen Fenster einfügen (geht auch mit der Maus). Etwas komplizierter wird es bei mehreren Absätzen (des löschbedrohten Textes). Da muss man den Vorgang (mehrmals) wiederholen. Im Idealfall dauert das ganze wenige Sekunden, bis der löschbedrohte Text im neuen Fenster rüberkopiert wurde. Für mich ist die derzeitige Situation ausreichend (es benötigt keine Änderungen). lG --Hannes 24 (Diskussion) 18:52, 14. Mai 2016 (CEST)

Automatische Anzeige im Artikel

1. Die "Lösung" des Problems wäre doch einfacher, wenn bei jedem Edit-Klick automatisch auf der WP Seite angezeit wird, dass jemand diesen Artikel / Abschnitt editiert, damit sind EK's schon mal auf ein Minimum reduziert.
2. und/oder ggf. automatisch für weitere Edits gesperrt wird (das 2. sicher keine perfekte Option). Dazu könnte man die Möglichkeiten Kurzedit (<10 min) und "große Bearbeitung" (<2h) anlegen (wegen 2. Option) nachdem wieder (ohne Speicherung) freigegeben wird.

MfG -- commander-pirx (disk beiträge) 13:35, 16. Mai 2016 (CEST)

Zu 1.: Das würde das Problem IMHO nicht lösen, weil Nutzer erfahrungsgemäß auch dann editieren, wenn sie wissen, daß andere in dem selben Abschnitt arbeiten.

Zu 2.: Bei Artikel(abschnitts)sperren durch normale Nutzer wäre die Mißbrauchsgefahr zu hoch.

--88.68.82.108 19:21, 16. Mai 2016 (CEST)

zu 1. Das will ich ja automatisch (sw-technisch) sperren lassen (sorry, mich wohl unklar ausgedrückt)

zu 2. auch hier soll das nicht der Nutzer machen, sonder automatisch durch die SW passieren. MfG -- commander-pirx (disk beiträge) 20:02, 16. Mai 2016 (CEST)

Ob das händisch oder automatisch gesperrt wird, macht keinen Unterschied für mich. --88.68.82.108 20:06, 16. Mai 2016 (CEST)

Tonprotokoll oder wie klingt es, wenn man einen Bearbeitungskonflikt auflöst?

Um genau zu verstehen, was wo hakt, wie jeweils Schritt für Schritt mit einem Bearbeitungskonflikt umgegangen wird (oder nicht), sind Tonprotokolle sehr hilfreich. Tonprotokoll, d.h., sich selbst dabei aufzunehmen, wenn man in einen Bearbeitungskonflikt gerät und Schritt für Schritt zu beschreiben, was man wie macht. Dies am Besten unterstützt durch einen Screenshot der Situation, die beschrieben wird. Hier ein Beispiel, in dieser Variante mit Video vom Bildschirm (Englisch). Wer Lust hat, das Team mit einer Aufnahme zu unterstützen, kann sich gerne direkt bei Jan melden, der im Team der Software-Entwicklung für Aufgaben rund um Design, Benutzerfreundlichkeit & Benutzeroberfläche zuständig ist. Vielen Dank!

Zwischenstand und wie es weiter geht

Vielen Dank an alle, die hier kommentiert haben oder außerhalb des Wikis ihren Umgang mit Bearbeitungskonflikten beschrieben, Feedback gegeben und Vorschläge gemacht haben.

Als ersten Zwischenstand werden hier die Ergebnisse der bisherigen Überlegungen zusammengefasst. Auf Grundlage der ersten Runde ist ein neuer Vorschlag entstanden, der ebenfalls vorgestellt wird.