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

Vorschlag B 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! --Birgit Müller (WMDE) (Diskussion) 20:23, 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 zwei 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.

Hier geht es zu Vorschlag A

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 folgender neuer Arbeitsprozess vorgeschlagen wird:

Grundsätzlich gibt es zwei Schritte: Zuerst wählt man aus, welche Textabschnitte man von sich beziehungsweise der konfliktierenden Änderung übernehmen will (Schritt 1).

Als nächsten Schritt kommt man dann auf die Vorschauseite, von der aus man den gesamten Text noch einmal editieren kann, wenn dies gewünscht ist (Schritt 2).

Schritt 1 ist in Bild 2 angedeutet:

Bild 2: In der linken Spalte findet man alle Änderungen von sich (eingebettet in etwas Kontext des Artikels) und in der rechten Spalte sind alle Änderungen, die den Konflikt hervorgerufen haben. Man kann nun auswählen, welche der Änderungen man behalten möchte, und welche nicht. Dabei ist es auch möglich, beide miteinander im Konflikt stehenden Änderungen zu behalten. Außerdem kann man den eigenen Text editieren.

Schritt 2 besteht aus der Vorschauseite, die die gleiche ist, wie die, die man beim Seiten bearbeiten sehen kann:

Schritt 2: Vorschau-Button und Vorschaumodus: Die Vorschau-Seite erhält alle in Schritt 1 ausgewählten Textbausteine

Im Artikelfeld befindet sich nun der Artikel, der alle Textbausteine, die man in Schritt 1 ausgewählt hat, enthält. Nun kann man weitere Änderungen vornehmen, zum Beispiel um den Übergang zwischen den neuen Abschnitten flüssiger zu gestalten. Wenn man nun auf Speichern drückt, ist der Artikel gespeichert.

Anmerkungen zu Vorschlag B

Was ist gut an dem Vorschlag

• Kommentar und Signatur
• Hört sich für mich einfacher und verständlicher an als Variante A. Wie es dann im detail aus sieht beim richtigen bearbeiten, ob es dann wirklich so einfach ist, weiß ich nicht. Ich selber habe mit TortoiseSVN für Konfliktlösungen beim Mergen gute Erfahrung gemacht. Ich sehe die Problem hier ähnlich, und von meinem verständniss ist die Lösung B dichter an der TortoiseSVN Lösung als die Variante A. --GodeNehler (Diskussion) 10:35, 12. Mai 2016 (CEST)

Was könnte besser sein

• Kommentar und Signatur

Was sollte auf keinen Fall gemacht werden

• Kommentar und Signatur

Offene Fragen

• Auch hier: Kann ich "meinen" kompletten Text mit STRG+A einfach übernehmen, ohne sämtliche Änderungen anschauen zu müssen? Meist mache ich ein zweites Tab mit der Versionsgeschichte auf und ziehe die Änderungen händisch nach. --Flominator 12:04, 12. Mai 2016 (CEST)
• Klingt nicht schlecht, die natürlich noch simple Skizze ist mir aber zu vage für ein Urteil. Könnt ihr etwas genauer erläutern, wie ihr euch das mit dem Übernehmen der gewünschten Textabschnitte gedacht habt? Und bekommt die aktuelle Diff-Engine von MediaWiki das übersichtlich dargestellt? -- hgzh 13:37, 12. Mai 2016 (CEST)

Hi hgzh, zur Frage mit der Diff-Engine: Ja, die übersichtliche Darstellung sollte machbar sein. Der komplexere Teil ist die Phase zwischen: Textbausteine sind ausgewählt und man drückt auf Vorschau und die Vorschau wird erstellt - der Moment, in dem also eine Auswahl an einzelnen Textschnipseln an den Server geschickt wird und eine vollständige Vorschau mit den integrierten Textschnipseln an der richtigen Stelle zurückkommen soll - aber auch das sollte lösbar sein. Wie das im Einzelnen aussehen kann mit der Auswahl und Übernahme der Textbausteine, können wir momentan noch nicht sagen. Vorschlag B ist von der Vorgehensweise in der Softwareentwicklung inspiriert, wo "Merge-Konflikte" (sozusagen Bearbeitungskonflikte in der Programmierung) über eine ähnliche Auswahl von einzelnen Teilen gelöst werden. In diesem ersten Stadium gehts vor allem darum, zu klären, ob generell eine Vorgehensweise bei der man a.) einzelne Textbausteine auswählen und deren Reihenfolge bestimmen kann und b.) in der Vorschauansicht den gesamten Text sieht und nochmal nachbessern kann, nützlich erscheint. Abgesehen von der technischen Machbarkeit, klänge so etwas sinnvoll? Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 16:50, 13. Mai 2016 (CEST)

Hallo Birgit, danke für deine Erklärung. So, wie du es jetzt geschildert hast, halte ich das für einen sinnvollen Vorschlag. Ich kann mir das also in etwa wie bei Beyond Compare (nutze ich) vorstellen. Gruß, -- hgzh 19:59, 17. Mai 2016 (CEST)

• Im Prinzip sehe ich das wie mein Vorredner. Beim Implementieren sollte man allerdings Folgendes bedenken (auch wenn das einige hier vermutlich nicht hören wollen): Bis das Verfahren funktioniert, vergeht so viel Zeit, dass bis dahin außer ein paar alteingesessenen Wikipedianern niemand mehr den Quelltexteditor verwendet. Der Fokus sollte also von vornherein auf einer leichten Bedienbarkeit aus dem VE heraus liegen. Wobei sich dieser Vorschlag im Gegensatz zur Variante A tatsächlich auch dafür eignet. --Schnark 10:48, 13. Mai 2016 (CEST)
• Primär finde ich die Idee interessant, weiß aber noch nicht, wie mir die praktische Umsetzung des Features gefiele, da diese nicht perfekt sein wird. Zunäcsht sollte es die Möglichkeit geben, eine derart große Änderung auch zu deatkivieren, zum anderen mache ich mir um die praktische Umsetzbarkeit bei komplexen Diffs sorgen. Ich denke fast, dass eine zufriedenstellende Lösung nach diesem Prinzip nur funktionieren kann, wenn der Diff-Code deutlich verbessert wurde, was WMDE ja leider für nicht umsetzbar hält. (nicht signierter Beitrag von MGChecker (Diskussion | Beiträge) 13. Mai 2016, 20:45:08‎)
• Bearbeitungskonflikte entstehen bei oft bearbeiteten Artikeln. Gibt es nach wie vor keinen Lock-Mechanismus (sondern eben einen BK) dann sehe ich nicht, wie man aus einer Folge von BKs herauskommt, denn während ich in der Maske die Änderungen prüfe und dann auf Speichern klicke, hat bereits ein anderer Autor die Seite geändert und der nächste BK steht im Raum. --Holmium (d) 20:54, 13. 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.