„Bessere Lösung von Bearbeitungskonflikten“ ist ein Wunsch aus der Umfrage Technische Wünsche 2015. Zur Umsetzung dieses Wunsches wurde die Funktion „Zwei-Spalten-Bearbeitungskonflikt“ entwickelt. Sie ist zzt. in der Beta-Phase, wird zahlreich genutzt und stellt für viele bereits eine Verbesserung zur vorherigen Situation dar. Dennoch ist das Team Technische Wünsche noch nicht ganz zufrieden. Darum wurde im Herbst 2017 eine Feedbackrunde durchgeführt, deren Ergebnisse zusammen mit weiteren Untersuchungen in die Entwicklung eines neuen Ansatzes eingeflossen sind.
der neue Ansatz (Prototyp)
In dieser Runde ging es darum, herauszufinden, ob der neue Ansatz sich gut eignet, um Bearbeitungskonflikte zu lösen. Vom 12.02. bis 12.03.2018 waren alle eingeladen, den neuen Ansatz zu testen. Danke an alle, die durch ihre Rückmeldung geholfen haben, die Funktion mitzuentwickeln!
So sah der Prototyp aus. Er ist in dieser Form nicht mehr zugänglich, weil sein Server nun für die Umbauten an der Funktion „Zwei-Spalten-Bearbeitungskonflikt“ genutzt wird.
Im neuen Prototyp sind einige Beispielseiten hinterlegt, mit denen sich Bearbeitungskonflikte simulieren lassen, ohne dass irgendwelche Änderungen abgespeichert werden. Man kann also nichts kaputt machen und muss sich auch nicht anmelden.
Hinweise
Im Prototyp wird die Version, mit der man in einen Bearbeitungskonflikt gerät, durch automatische, zufällige Textänderungen erzeugt.
Im Test geht es darum, ob der neue Ansatz das Problem grundsätzlich gut löst, und noch nicht um Details. Darum sind im Prototyp noch nicht alle Funktionalitäten enthalten.
Für mich war es schwierig. Ich hatte zuerst versucht, im Wikipedia-Livebetrieb einen Bearbeitungskonflikt zu bekommen (eingeloggt mit PC, ausgeloggt mit Notebook). Dies war mir aber nicht gelungen. Beim Test im Simulator habe ich eine Zeit gebraucht zu verstehen, dass nur die vorgeschlagenen Lemmata simuliert werden können und kein selbstausgesuchter Artikel. Beim Auswahl der Textvorlage (3/3) verstehe ich nicht, warum ich eine Bearbeitungsgrundlage wählen muss. Die Bearbeitungsgrundlage ist doch immer die Ausgangsversion vor den Bearbeitungen. In diese Ausgangsversion wurde von mir und jemand anderem eine Änderung eingefügt. Die kann ich doch nicht aussuchen, man bearbeitet doch so gut wie immer die letzte Version des Artikels. Das verstehe ich nicht. Was aber in der neuen Version viel besser ist als in der alten Version der Bearbeitungskonfliktanzeige ist die Gegenüberstellung der Versionen nach Absätzen gegliedert. Häufig wird ein kaum formatierter Artikel veröffentlicht, zu dem man sofort sieht, was ihm noch fehlt. Wenn man da alle Transkriptionen umbiegt, ein Foto einfügt und den Artikel aktualisert, kommt es häufig zum Bearbeitungskonflikt, da vielen erfahrenen Benutern Formatierungsfehler aufgefallen sind. Es kann gut sein, dass man sich mit der neuen Gegenüberstellung Arbeit spart. Noch einmal zur Simulation: Ich hatte meine Änderungen übernommen, als ich dann aber auf Simulation ausführen geklickt habe, waren sie wieder weg und der Artikel war wie zuvor. Ich entschuldige mich für mein Nichtverständnis, aber ich bin nun mal nicht sehr bewandert, was Technik angeht. --Gereon K. (Diskussion) 18:41, 12. Feb. 2018 (CET)[Beantworten]
@Gereon K.: Vielen Dank, dass du wieder mitgemacht hast! Für dein „Nichtverständnis“ musst du dich überhaupt nicht entschuldigen. Die Funktion soll für alle gut funktionieren, egal wie viel Technikverständnis man hat. Zu den von dir genannten Punkten:
Das erste von dir beschriebene Problem hängt damit zusammen, dass das hier erst mal ein grober Prototyp ist. Er läuft auf einem Testwiki und darum gibt es nur ein Set von Beispielartikeln. Das war bei der letzten Feedbackrunde anders, weil wir da direkt in der Wikipedia testen konnten.
Zu deiner Frage, warum eine Bearbeitungsgrundlage ausgewählt werden muss: Vorab: Das Popup 3/3 war falsch platziert. Das war wahrscheinlich irreführend und ist dank deines Hinweises nun behoben. Und zum Eigentlichen: In dieser Oberfläche entscheidest du dich nur zwischen den beiden konfliktierenden Versionen. Die Ausgangsversion vor den Bearbeitungen taucht hier nicht mehr auf. Dafür bräuchte man drei Spalten, was unserer Einschätzung nach die Oberfläche sehr unübersichtlich machen würde.
Außerdem danke für den Hinweis, dass die Änderungen beim Speichern verschwinden. Es scheint, dass du die Änderungen in den Textfeldern nicht mit dem Häkchen bestätigt hast. Das sollte später in der echten Implementierung nicht passieren können. Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 08:59, 14. Feb. 2018 (CET)[Beantworten]
Intuitiv. Bei kurzen Absätzen optimale Lösung des Konfliktes, Bei langen oder unstrukturierten Artikeln wird es komplexer, aber nach meiner Erwartung besser als früher möglich sein, Konflikte aufzulösen. --Holmium(d)18:51, 12. Feb. 2018 (CET)[Beantworten]
Mhm, einfach und funktionabel. Bei größeren Abschnitten ohne Unterteilungsmöglichkeit, wird es schwierig, wenn in beiden Seiten Fehler sind - ich konnte die des Anderen dann nicht mehr berbeiten... --commander-pirx (diskbeiträge)20:35, 12. Feb. 2018 (CET)[Beantworten]
@Commander-pirx: Danke für dein Feedback! Du solltest die Texte eigentlich bearbeiten können. So ist es gedacht: Du wählst pro Absatz eine Version aus, indem du bei „Bitte eine Version wählen“ auf einen der beiden Kreise klickst. Es erscheint dann im entsprechenden Textfeld ein kleiner Stift. Wenn du darauf klickst, kannst du den Text bearbeiten und z. B. auch Texte aus der anderen Version mittels Kopieren & Einfügen dort einsetzen. Hast du das probiert? Falls das nicht funktioniert, an welcher Stelle hakt es genau? Für den Fall, dass hier ein technisches Problem vorliegt, wäre es nützlich zu wissen, welches Betriebssystem und welchen Browser du verwendest. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 08:59, 14. Feb. 2018 (CET)[Beantworten]
Intuitiv und gut verständlich. Für mich war es etwas nervig, sich erst durch die ganzen Erläuterungen klicken zu müssen, aber da ein Bearbeitungskonflikt ehr selten vorkommt, ist es vom Prinzip her gar nicht so schlecht.--Debenben (Diskussion) 22:57, 12. Feb. 2018 (CET)[Beantworten]
Ich fände es besser, wenn man aus der Live-Wikipedia eine alte Version auswählen könnte bei der simuliert wird, dass man zu dieser Zeit auf Bearbeiten geklickt hätte, und eine (neuere) Version, die als eigene Änderung simuliert wird. Also dass ich beispielsweise mit Auswahl von 173254387 und 173825557 einen echten BK nachstellen kann. --nenntmichruhigip (Diskussion) 23:15, 12. Feb. 2018 (CET)[Beantworten]
@Nenntmichruhigip: Danke für dein umfassendes Feedback! Zu deinem Wunsch habe ich noch eine Verständnisfrage: Welchen Vorteil hätte es für dich, aus der Live-Wikipedia eine alte Version auswählen zu können, um Bearbeitungskonflikte zu simulieren? Fehlt dir eine wichtige Art von Artikeln/Szenario, um besser testen zu können? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 08:59, 14. Feb. 2018 (CET)[Beantworten]
Damit könnte ich mich besser in die Situation hineinversetzen und tatsächlich aufgetretene Bearbeitungskonflikte nachstellen. Aus letzterem Grund fände ich es auch gut, wenn es eine solche Funktion auch nach dem Betatest geben würde, damit man bei aufgetretenen Problemen besser nachvollziehen kann was passiert ist. Die mir im Prototyp fehlende Art sind große, verwirrende Bearbeitungskonflikte, die je nach Fachgebiet des Artikels unterschiedlich sind und daher eher nicht durch eine bestimmte Artikelauswahl abdeckbar sind. --nenntmichruhigip (Diskussion) 10:41, 14. Feb. 2018 (CET)[Beantworten]
@Nenntmichruhigip: Danke für die Erklärung. Der Prototyp läuft auf einem Testwiki, in dem nicht alle Seiten der Wikipedia verfügbar sind, darum geht das leider nicht. Trotzdem noch mal zum Verständnis, weil ich die Idee interessant finde: Ich nehme Version A eines Artikels als Basis und Version B als Text, mit dem sich ein Bearbeitungskonflikt ereignet hat. Wenn ich die beiden vergleiche, sehe ich doch aber nicht den damaligen Bearbeitungskonflikt, oder? Denn Version B enthält ja schon die Lösung des Konflikts. Oder hab ich etwas falsch verstanden? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 11:59, 15. Feb. 2018 (CET)[Beantworten]
Stimmt nicht (ganz), ich habe beispielsweise den Satz "Die Kaze hat fünf Beine" (Version A) und merke, dass das "Katze" heißen muss und habe einen BK gehabt mit jemandem, der aus "fünf" "vier" gemacht hat. Dann ist doch die nächste Version "Die Kaze hat vier Beine" (Version B), die gibt's doch noch, damit kann ich doch simulieren, dass ich aus "Die Kaze hat vier Beine" (Version B) und "Die Katze hat fünf Beine" (wahrscheinlich nicht abgespeichert) jetzt "Die Katze hat vier Beine"(Version C) machen muss. Wie das dann funktioniert, weiss ich nicht, weil ich einen Zufalls-BK einige Zeilen weiter unten hatte. Ich stelle mir mein Beispiel am Ende doch etwas kniffliger vor als das, was ich hatte. --MannMaus (Diskussion) 19:06, 21. Feb. 2018 (CET)[Beantworten]
@MannMaus: Meinst du, quasi per Reverse Engineering aus B und C wieder Version A zu rekonstruieren und dann mit A und B den Konflikt zu simulieren? Ob das ginge, übersteigt gerade meine Urteilskraft. In dieser Runde hier soll es erstmal nur darum gehen, ob der im Prototyp dargestellte Ansatz grundsätzlich gut funktioniert. Wie fandst du ihn denn insgesamt? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:41, 22. Feb. 2018 (CET)[Beantworten]
Jetzt wo du’s sagst weiss ich auch wieder, wie ich es ursprünglich meinte: Zuerst ein Dialog, wo eine Version A und eine spätere Version B ausgewählt werden. Danach öffnet sich eine Bearbeitungsseite mit Version A. Dort muss die eigene Bearbeitung manuell gemacht werden. Beim Klick auf "Konflikt simulieren" wird der BK so simuliert, dass Version B die inzwischen aktuelle Version ist. In meinem Eingangsbeitrag hätte ich als Version B also eine Version früher auswählen müssen. --nenntmichruhigip (Diskussion) 11:59, 22. Feb. 2018 (CET)[Beantworten]
Insgesamt 1a bei den einfachen Fällen, wenn ich eine Sache oben und der andere eine Sache unten geändert hat. Bei Korrekturen im selben (Ab)satz ist es noch kompliziert, aber schlimmer als jetzt, dass ich manchmal abbrechen muss und erst einmal die neue Änderung lesen muss, ist es auch nicht, da wäre es dann keine Veränderung, nur bunter. (Und das meine ich nicht negativ!) Fazit also: Auf jeden Fall besser und nicht schlechter als der Ist-Zustand. Bei einem Test wusste ich nicht mehr, ob das jetzt meine Änderung war, aber das wird in der Realität wohl kaum vorkommen. Das heißt, mir fehlt dann halt noch der Vergleich mit dem Original, aber das wird dann auch zu unübersichtlich. Und,ja, ich meinte mit A und B einen Konflikt zu simulieren, wie es nenntmichruhigip vorgeschlagen hat. Gezielt üben (testen) könnte man ja schon, wenn man wüsste, was gleich für eine Änderung kommt. Und ihr glaubt nicht, was gerade passiert ist! BK--MannMaus (Diskussion) 12:11, 22. Feb. 2018 (CET) P.S.: Und das war einer von den komplizierten, die damit immer noch kompliziert wären, die man auch schlecht simulieren kann. --MannMaus (Diskussion) 12:14, 22. Feb. 2018 (CET)[Beantworten]
P.P.S.: Ich hätte vorhin noch fast eine Frage im Sinne von Generator (etwas weiter unten) gestellt, aber dann gesehen, dass sie schon gestellt und beantwortet wurde. Ich glaube, wir (der Prototyp hier und ich) gewöhnen uns aneinander. Ich betrachte diese Testphase hier auch als Übung für mich, falls das noch nicht aufgefallen ist. Und ich kann den anderen auch nur raten, das zu üben. --MannMaus (Diskussion) 15:41, 22. Feb. 2018 (CET)[Beantworten]
Ich fand die vielen Erklärungsboxen ziemlich nervig und hab sie (natürlich) auch nicht gelesen sondern einfach so schnell als möglich weggeklickt. Und versteht ich das richtig, dass man einfach nur seine eigene Version oder die des anderen wählen kann aber keine automatisierte Möglichkeit hat beide Versionen zusammenzuführen? Wenn beide User eine Wort hinzufügen sollte das doch möglich sein. btw. wurden auch mehrere Bearbeitungskonflikte erzeugt wo ich nicht erkennen konnte was der Andere eigentlich geändert hat (Auf meiner Seite war ein zusätzliches Wort und auf der anderen Seite keine Änderung markiert). Generator (Diskussion) 11:17, 13. Feb. 2018 (CET)[Beantworten]
@Generator: Wenn du in einem Text in Absatz 1 etwas änderst und ich in Absatz 2, dann fügt die Software beide Versionen automatisch zusammen – wenn wir nicht außerdem beide etwas im selben Absatz geändert haben. Wenn das der Fall ist, entsteht ein Bearbeitungskonflikt. Das heißt, die Software kann das nicht lösen, denn sie weiß nicht, wie sie die Änderungen zusammenfügen soll (z. B. welches Wort an welche Stelle kommt), und natürlich weiß sie auch nicht, ob der Absatz noch Sinn ergibt. Das muss also ein Mensch beurteilen. Manuell kann man beide Versionen zusammenfügen, indem man auf den Stift innerhalb des Abschnitts klickt. Dann kann man einen Text verändern und z. B. auch Elemente aus dem anderen Text mittels Kopieren & Einfügen rüberkopieren. Sobald ein Bearbeitungskonflikt auftritt, ist es in der Wikipedia generell so gelöst, dass alle Änderungen angezeigt werden und nicht nur die im selben Absatz. Wenn du noch Fragen hast, gerne. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 12:48, 15. Feb. 2018 (CET)[Beantworten]
Ausgezeichnet, es war in Sekunden zu verstehen. Mit einer aelteren Version des Bearbeitungskonflikts habe ich bereits einmal Text verloren. Dies wird mit dieser Version kaum noch passieren koennen. Klasse! Minihaa (Diskussion) 19:32, 13. Feb. 2018 (CET)[Beantworten]
Ist wirklich nützlich. Ich glaube, man kann damit in der Praxis sehr schnell Bearbeitungskonflikte lösen. Für das erste Popup hätte ich noch den Vorschlag, die Spalten in umgekehrter Reihenfolge zu benennen, da wir ja zumindest in Deutschland von links nach rechts lesen. Aktuell heißt es: Die zwei Spalten zeigen den Bearbeitungskonflikt zwischen der anderen Person (in blau auf der rechten Seite) und dir (in gelb auf der linken Seite) an. Ich schlage vor: ...zwischen dir (in gelb ...) und der anderen Person (in blau ...). --FNDE15:06, 18. Feb. 2018 (CET)[Beantworten]
Erklärungsboxen vielleicht wirklich dezent überflüssig, das einzige was für einen kurzen Moment verwirrend war (ohne die Boxen zu lesen), war dass die Bearbeitung erst nach Auswahl einer Box möglich ist. --Shendoah (Diskussion) 22:51, 24. Feb. 2018 (CET)[Beantworten]
Optisch aufgepeppte, selbstreferenzielle Software-Spielerei mit 100.000 zwischendrin eingebauten, unnötigen und nervenden Fragen. Die Bewältigung von Bearbeitungskonflikten wird durch diesen teuren Spaß nicht vereinfacht, sondern umgekehrt erheblich verkompliziert und erschwert. Vorschlag zur Güte: WMF soll den Programmierer-Kumpels einfach die Kohle rüberwachsen lassen, aber wenigstens BITTE !! das Zeug NICHT !! implementieren. --Richard Zietz15:11, 10. Mär. 2018 (CET)[Beantworten]
Gerne. Einzeloptimierungen abgesehen waren technische Neuerungen für mich noch nie eine Hilfe; im Gegenteil: eher eine Verschlechterung bzw. ein Part, der das Editieren nur verkompliziert. So editiere ich bis heute ausschließlich im Quelltext-Editor. Zu dem neuen Bearbeitungskonflikte-Feature: Mir ist es schlichtweg nicht gelungen, die probehalber erzeugten Änderungen abzuspeichern. Für mich sieht das ähnlich aus wie der Irrgarten rund um die Sichtungs-Funktionen, die ich mittlerweile wo möglich meide. Drittens finde ich die bisher implementierte Form, Bearbeitungskonflikte aufzulösen, bereits ausreichend. P. s: Die vertikale Fensteraufteilung (anstatt der bisher gängigen horizontalen) finde ich zwar ganz gut. Dieser einzelne Aspekt geht jedoch in dem unerquicklichen Drumherum unter. --Richard Zietz15:21, 12. Mär. 2018 (CET)[Beantworten]
Danke für die Erklärung, Richard Zietz. Zum Problem mit dem Abspeichern habe ich noch eine Rückfrage: Es kam schon von einer anderen Stelle das Feedback, dass Änderungen nicht gespeichert werden konnten – in dem Fall war es so, dass im Textfeld etwas geändert, aber nicht mit dem Häkchen bestätigt wurde. War das bei dir möglicherweise auch so? Oder lag das Problem an anderer Stelle? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 10:35, 13. Mär. 2018 (CET)[Beantworten]
Hallo Johanna Strodt (WMDE), ich denke nicht, dass der Sinn einer Software darin besteht, die von den Entwicklern implementierten Hürden in Form von Häkchen und Abfragen ähnlich wie bei einer Schnitzeljagd erfolgreich zu überwinden. Ich glaube, ihr stellt euch den Prozess, der „gelöst“ werden soll, viel zu kompliziert vor. --Richard Zietz11:45, 13. Mär. 2018 (CET)[Beantworten]
Viel besser also die vorherige Version, die war wirklich unglaublich grauenhaft (vlt. lag es auch daran, dass ich schon ewig das Userscript von Bawolff gewohnt war). -- User: Perhelion13:12, 12. Mär. 2018 (CET)[Beantworten]
Wie wurde vorgegangen? Was ist passiert? Entsprach das den Erwartungen?Gab es frustrierende Momente? Was ist positiv aufgefallen?
Ich habe ganze Zeilen gelöscht, neue Zeilen hinzugefügt und auch bestehende Inhalte geändert. Positiv überrascht (weil das vor der Auswahl nicht offensichtlich war) war ich von dem Umstand, dass ich im von mir gewählten Absatz sogar noch nachbearbeiten konnte. Tkarcher (Diskussion) 17:17, 12. Feb. 2018 (CET)[Beantworten]
Durch die Abschnittsunterteilung und Auswahl sicher gute Lösungsmöglichkeiten; Problem, wenn in einem Abschnitt in beiden Seiten Fehler sind, der Abschnitt des Anderen weniger Fehler ht und ich diesen auswählen würde, aber dann nicht mehr korrigieren kann.... --commander-pirx (diskbeiträge)20:37, 12. Feb. 2018 (CET)[Beantworten]
@Johanna Strodt (WMDE):: Nein, ich meine den Text der als Zusammenfassung vorgeschlagen wird (Oder gibt es den nur beim Rückgängigmachen?). Im Prototyp ist das entsprechende Feld "Zusammenfassung" zumindest immer leer. Ich könnte mir vorstellen, dass da so etwas wie "Bearbeitungskonflikt aufgelöst, 90% von User XY verwendet" praktisch wäre. Generator (Diskussion) 11:12, 14. Feb. 2018 (CET)[Beantworten]
Der Bearbeitungskonflikt konnte gelöst werden, der Text entsprach aber nicht den tatsächlichen Änderungen. Ich bin etwas irritiert darüber, dass bei niemandem sonst diese Fehler auftauchten.. Ich habe die Simulationen mehrmals wiederholt, andere Änderungen vorgenommen und mit drei verschiedenen Browsern (Opera, Mozilla, Chrome) wiederholt (in 2 davon ohne Wiki-Anmeldung). Die Fehler tauchten dabei in allen drei Browsern auf.
Ich habe manuell Einfügungen, Änderungen, Löschungen und Verschiebungen im Artikel, sowie Änderungen während der Bearbeitung des Bearbeitungskonflikts vorgenommen. Löschungen und Bearbeitungen von bereits vorhandenen Absätzen und Überschriften, sowie die Bearbeitung im Bearbeitungskonflikt haben fehlerfrei funktioniert. Nicht funktioniert haben dagegen das Einfügen:
neuer Absätze in bereits vorhandenen Unterkapitel
neuer Unterkapitel
neuer Aufzählungen,
Insgesamt waren die Einfügungen zwar kompakt so, wie eingegeben und auch die Reihenfolge innerhalb einer neuen Einfügungen war korrekt, allerdings tauchten die Einfügungen in der Vorschausimulation dann an anderen Stellen auf, teilweise nur ein Absatz weiter unten, teilweise sonstwo im Artikel. Bei Wiederholung der Simulation im selben Browser und den anderen Browsern war es willkürlich jedes Mal eine neue Stelle.
Außerdem hat das Abändern von Aufzählungen nicht funktioniert. Ich habe beispielsweise den dritten Punkt einer Aufzählung entfernt und an der ersten Stelle einen neuen Punkt hinzugefügt (begonnen in der Zeile vor der Aufzählung, Enter und dann manuelles Eingeben von * und Text). Diese Aufzählung landete dann an dritter Position (???) die gelöschte Aufzählung war jedoch tatsächlich weg.
Etwas unvorteilhaft finde ich die Bearbeitungsfunktion beim Bearbeiten des Bearbeitungskonflikt. Sobald man den Stift anwählt, wird die farbliche Markierung entfernt und es ändert sich die Schriftart (auf die Schriftart die für Quelltext verwendet wird). Dadurch verliert man die betreffende/n Textestelle/n aus den Augen. Bei nur einer Textstelle mag das ja noch funktionieren, aber sobald es mehrere pro Absatz werden, werden alle in einem Textfeld angezeigt und sobald man den Stift anklickt, ist diese Markierung weg und dann kann man anfangen zu suchen. Auch Nachkontrollen, ob man alle Fehler ausgebügelt hat, sind so eher schwer möglich.
Als Lösung kann ich mir folgende Möglichkeiten vorstellen:
entweder sollten die farblichen Markierungen auch bei Bearbeitung beibehalten werden (was vermutlich technisch nicht umsetzbar ist?), oder
die Textfelder die den Konflikt auslösen, sollten bereits in Quelltext angezeigt werden, oder
die Markierungen bleiben auch nach Bearbeitung erhalten (← wäre mein Favorit. Falls technisch nicht umsetzbar, sollte zumindest die Markierung in der kollidierenden Version erhalten bleiben)
Auf einer Skala von 1 (sehr nützlich) bis 6 (überhaupt nicht nützlich)?
Recht nützlich (2?): Ich gerate eher selten in Bearbeitungskonflikte. Und wenn, kam ich auch mit der bisherigen Funktion ganz gut klar. Aber für diejenigen, die das Problem häufiger haben, ist das sicher eine schöne Verbesserung. Tkarcher (Diskussion) 17:17, 12. Feb. 2018 (CET)[Beantworten]
2: Sehr einfach zu bedienen, der Editor passt besser in das allg. Erscheinungsbild des MediaWikis und wirkt nicht so erschlagend, wie der aktuelle Betatest. Kritikpunkt: Die Farben gelb und blau sind in meinem Kopf als "hinzugefügt/entfernt" eingebrannt, und wirken deshalb etwas verwirred. -- Jonaes/Diskussion17:39, 12. Feb. 2018 (CET)[Beantworten]
2: Was noch nützlich wäre, ist eine Vorschaufunktion mit der man ggf. erkennt wenn etwas garnicht rendert, aber vom Prinzip her ist der Prototyp auch so schon nützlich genug.--Debenben (Diskussion) 23:05, 12. Feb. 2018 (CET)[Beantworten]
Gesamtfazit: Die Version aus der vorherigen Feedbackrunde fand ich besser. Vielleicht sogar die alte BK-Oberfläche. Auf der Skala so etwa 4 bis 5. Btw hatte ich die Skala zuerst andersrum erwartet. --nenntmichruhigip (Diskussion) 23:15, 12. Feb. 2018 (CET)[Beantworten]
Nachtrag: Du hattest unter „Weitere Anmerkungen zum neuen Ansatz“ ja auch einige einzelne Punkte genannt. Einige davon haben damit zu tun, dass im Prototyp nur die grundsätzlichen Funktionen enthalten sind. Damit soll herausgefunden werden, ob der neue Ansatz im Wesentlichen intuitiv ist, ohne dass schon viel Energie in die Entwicklung gesteckt wird. Wenn sich herausstellt, dass dieser Ansatz intuitiv ist, würde die Funktion noch ausgebaut. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 09:37, 14. Feb. 2018 (CET)[Beantworten]
Nein, das ist lediglich mein Eindruck. Kann durchaus sein, dass sich das mit Implementierung weiterer Funktionen (insbesondere einer Komplettauswahl) ändern würde. Ich vermute, dass ich diesen Eindruck habe, dass es unübersichtlicher wirkt, dass alles auf einer großen Seite statt in kompakten Kästen ist, obwohl es damit ojektiv eher übersichtlicher wird. (Auch hier wäre wieder eine Versionsauswahl gut, damit man die Scrollwege zwischen bisheriger Betaversion und neuem Prototyp vergleichen kann) --nenntmichruhigip (Diskussion) 10:42, 14. Feb. 2018 (CET)[Beantworten]
Im Betafeature ist bei dem getesteten Teildiff der Ausschnitt der vorherigen/nächsten Quelltextzeile in jeweils zwei Zeilen statt nur jeweils einer dargestellt (was btw zu einem Bug beim Ausfaden führt) und die Abstände sind mit ca. 2 em bis 3 em mEn deutlich übertrieben, aber trotzdem ist das getestete Teildiff "nur" gleichlang wie im Prototypen. Die Scrollwege sind etwa gleich, wobei das im Betafeature ungewollt aussieht. Dadurch, dass man nicht in beiden Feldern getrennt scrollen muss sind sie eher jetzt schon kürzer.
Können die Abstände der Zeilendivs reduziert werden? Für mich sieht das auch mit margin:0 in Ordnung (und sogar besser lesbar) aus, aber ich würde mich nicht mit Designaufgaben beauftragen :-)
Die Schriftgröße ist identisch wie in normalem Artikeltext (14 px), aber größer als in Versionsunterschieden (12,316 px), wodurch die Zeilenhöhe 2,7 px höher ist. MEn sollte bei der BK-Oberfläche die Schrift gleich groß wie bei Versionsunterschieden sein, was aber auch bedeuten kann, dass sie bei letzteren größer werden sollte. Die Schriftgröße beim Betafeature liegt mit 13 px dazwischen.
Könnte zum Platzsparen .mw-twocolconflict-goat-label ("Bitte eine Version wählen") nur einmal ganz oben stehen? Die Anpassung an den gewählten Zustand ist mEn unnötig, da das schon durch den Zustand der Radiobuttons eindeutig ersichtlich ist. Und wenn ich die "andere" Version wähle und ändere wird daraus ja in gewisser Weise "meine" Version.
Und dann noch ein paar kleinere Bugs, die mir nebenher aufgefallen sind:
In den Stammdaten steht bei der eigenen Version "gespeichert am". Die BK-Oberfläche ist etwas früh um als gespeichert zu gelten :-)
Bei einem langen Wort ohne Stelle zum Zeilenumbruch (z. B. URL mit Pluszeichen) wird das Textfeld breiter und die Zeile verlässt rechts den Darstellungsbereich (horizontales Scrollen).
Bei einer einzelnen neu hinzugefügten Zeile ist das Textfeld zwei Zeilen hoch.
Die Hinzufügung (und vermutlich auch Löschung) von Leerzeichen und Leerzeilen wird nicht erkennbar bis verfälschend (einzelne Leerzeile ersieht aus wie ein Leerzeichen) dargestellt.
Allgemein: Wäre es sinnvoller, die Zuordnung neu/alt zu vertauschen? Dann wäre es genauso wie im aus der Änderung resultierenden Versionsunterschied und in einer Diff-Vorschau. Das könnte auch erklären, warum ich mit dem momentanen Beta-Feature Probleme damit habe, die Version richtig zuzuordnen.
Nach dem Feedback von User:FNDE: Auf Diskussionsseiten könnte diese Lösung sehr deutlich vorteilhaft sein. Dafür müssten allerdings neue Quelltextzeilen aus beiden Versionen hintereinander gesetzt werden können. Jedenfalls korrigiere ich deshalb meine obige Einschätzung und sehe nun in dieser neuen Lösung mehr Potenzial als in der alten :-) --nenntmichruhigip (Diskussion) 11:39, 19. Feb. 2018 (CET)[Beantworten]
3: Im Vergleich zur älteren Version eher nervig, da Tippfehler in Anderen Abschnitten schwer zu beheben sind. Das einzige, was man am alten Design noch verbessern könnte, ist das ausgeblendete Textteile auf der Linken Seite auch wirklich Weg sind( Sonst entstehen so lustige c&p-Fehler wie bei mir vor einiger zeit auf Wikipedia:Fragen von Neulingen. Die einfachste lösung dazu währen zwei untereinanderliegende Textfelder - das eine Mit dem Ausgeblendeten Inhalt, das andere ohne - deren Sichtbarkeit von Der Checkbox abhängt. Victor SchmidtWas auf dem Herzen?18:36, 13. Feb. 2018 (CET)[Beantworten]
1, sehr nützlich. Habe BKs meistens nur auf den Seiten wo Wahlen stattfinden, dort kann man nun sehr elegant und schnell den BK lösen. Danke für eure Arbeit. --FNDE15:10, 18. Feb. 2018 (CET)[Beantworten]
Note 2: Leider kann man den Text in der Konfliktansicht nicht mehr grundlegend verändern, aber sonst eigenlich ganz gut. Man kann ja auch die veränderten Teile nochmal bearbeiten, hat einige Vorteile zur vorherigen Version, aber die daraus entstehenden Nachteile sind nicht ausgleichbar. -- Honischboy (Diskussion) 17:01, 21. Feb. 2018 (CET)[Beantworten]
Note 5: Mit den aktuellen Problemen (siehe unter Konnte der Bearbeitungskonflikt gelöst werden?) unübersichtlich und unstrukturiert. Die alte Version erscheint mir besser. --Shendoah (Diskussion) 00:16, 25. Feb. 2018 (CET)[Beantworten]
S. oben, nach Auswahl der Abschnitte und dem Zusammenführen, hätte ich gern noch die die Mglkt. finaler Berbeitg. in der Zsfsg. sollte automatisch eine Info über BK und Beteiligte stehen. (Roll back Möglichkeit?) --commander-pirx (diskbeiträge)20:41, 12. Feb. 2018 (CET)[Beantworten]
In der Anleitung wird „Absatz“ mit der Bedeutung „Quelltextzeile“ verwendet. Diese Abweichung von der üblichen Wortwahl halte ich für Verwirrend, da Absätze auch aus mehreren Quelltextzeilen bestehen können und Quelltextzeilen etwas anders als Absätze erzeugen können. --nenntmichruhigip (Diskussion) 23:15, 12. Feb. 2018 (CET)[Beantworten]
Bei einer manuellen Änderung enthält der Tooltip für das Bestätigungshäckchen „und Bearbeitungsseite verlassen“. Das klingt so, als würde man damit die Seite verlassen und lässt unklar, was mit den anderen Quelltextzeilen geschehen würde --nenntmichruhigip (Diskussion) 23:15, 12. Feb. 2018 (CET)[Beantworten]
Die normale Reihenfolge der Blöcke wäre 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, wobei ungerade Zahlen die ungeänderten Zwischenblöcke sind. Mir wurde das als 1, 2, 3, 4, 6, 5, 8, 7, 9, 10, 11 dargestellt. Ob es auf das gespeicherte Ergebnis Auswirkungen gehabt hätte habe ich nicht nachgeschaut. (Da wäre jetzt auch die vorgeschlagene Versionsauswahl hilfreich, dann könnte ich einfach die simulierten Versionsnummern nennen :-) ) --nenntmichruhigip (Diskussion) 10:44, 14. Feb. 2018 (CET)[Beantworten]
Das war das Pferd. Konnte es eben reproduzieren: die "Taxon6"-Zeilen der Infobox löschen, bei Taxon4_Rang und Taxon5_Rang einen Buchstaben anhängen, in der Einleitung einen neuen Absatz ergänzen und einen Listenpunkt in der ersten Aufzählugnsliste ergänzen. Screenshot ist mir gerade zu aufwändig :-) --nenntmichruhigip (Diskussion) 08:53, 15. Feb. 2018 (CET)[Beantworten]
@Nenntmichruhigip: Danke für die Zusatzinfos. Ich hab das mal durchgespielt, s. Screenshot. Meintest du es so? So wie ich das sehe, sind die Abschnitte innerhalb des Artikels immer noch in der richtigen Reihenfolge, aber durch das Entfernen und Hinzufügen haben sich andere Nummern ergeben. Außerdem gab es vorher nur zehn Absätze und jetzt gibt es elf. Oder? Vielleicht kannst du noch erläutern, was der Hintergrund deiner Anmerkung war. Also inwiefern du bei der Arbeit in der Wikipedia auf die Nummern der Absätze achtest. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 15:10, 15. Feb. 2018 (CET)[Beantworten]
Wie in deinem Screenshot, ja: Grasende Fjordpferde steht eigentlich erst hinter der Liste, im Screenshot aber schon davor. Ist ja schon irgendwie wichtig, dass z. B. meine Antwort auf deinen Beitrag nicht plötzlich vor deinem Beitrag steht :-) --nenntmichruhigip (Diskussion) 08:39, 16. Feb. 2018 (CET)[Beantworten]
Es ist jetzt nicht mehr einfach möglich, eine Version erstmal komplett zu übernehmen (beispielsweise bei einem Tippfehler vs. einer größeren Änderung, oder wenn die eigene größere Änderung die konfliktierender Änderung in anderer Weise enthält). --nenntmichruhigip (Diskussion) 23:15, 12. Feb. 2018 (CET)[Beantworten]
Mich hat etwas "irritiert", dass die geänderte "neue" Version in der linken Spalte angezeigt wird, während die "alte" Version rechts angezeigt wird. Bisher war das ja immer umgekehrt, also - rechts neu - links alt. --Kasa Fue (Diskussion) 23:25, 12. Feb. 2018 (CET)[Beantworten]
Weil es scheinbar den ein oder anderen gibt, der die alte Version so gut findet würde ich gerne widersprechen. Wenn ich einen Bearbeitungskonflikt habe, dann klicke ich normalerweise auf zurück, öffne die neue Version des Artikels in einem neuen Tab und klicke auf Bearbeiten, kopiere dann meinen Text in den Editor und nutze Änderungen anzeigen um alle nicht gewollten Änderungen ggf. per copy-paste zu entfernen.
Weil ich gerade die Betafunktion aktiviert hatte wollte ich es genau ein mal anders machen und habe aus Versehen (wie genau konnte ich leider nicht rekonstruieren, aber es wird irgendwie so gewesen sein, dass ich schnell auf irgendwelche Sachen geklickt habe weil ich der Meinung war dass man nichts falsch machen könnte) diverse Änderungen von ca. einer halben Stunde Arbeit nicht gespeichert und damit verloren. Das hat mich zwar sehr geärgert, aber ich habe mir gedacht: Du weißt weder was genau du gemacht hast, noch was sich verbessern lässt und bist mit der Methode neuer Tab eh besser zufrieden gewesen. Mit dem neuen Prototypen ist das anders: Der spart Arbeit, weil die Änderungen meistens in unterschiedlichen Abschnitten sind, sodass ich ihn sehr gerne verwenden würde.
Umfangreiche neue Änderungen würde ich bei einem Bearbeitungskonflikt nie vornehmen wollen, insbesondere nicht an Abschnitten, die niemand verändert hat, und wenn doch dann würde ich es immer anschließend mit einer separaten Änderung machen.--Debenben (Diskussion) 01:39, 14. Feb. 2018 (CET)[Beantworten]
Ich fand die Bedienung recht intuitiv. Ich wüsste nur gern, wie der andere Autor auf die Zusammenführung der Versionen reagiert, wenn ich immer nur meine Version auswähle. Welche Nachricht erhält der zweite Autor und könnte er sich zurückgesetzt fühlen? Geolinamente et malleo✎21:11, 12. Mär. 2018 (CET)[Beantworten]
Hallo Geolina, dazu habe ich eine Rückfrage: Glaubst du, dass sich der andere Autor mit dieser Benutzeroberfläche eher zurückgesetzt fühlt als mit den bisherigen Lösungen? Wenn ja, was glaubst du, woran das liegt? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:05, 13. Mär. 2018 (CET)[Beantworten]
BKs sind ja immer blöd. Ich habe bisher die Benutzeroberfläche nicht verwendet, aus Furcht den Edit des anderen Autor dabei zu löschen und damit einen Konflikt zu produzieren. Ich habe keine Erfahrungen, wie der zweite Autor auf meine Überarbeitung seines Edits reagieren würde. Ein bisschen Skepsis bleibt, dass er sich zurückgesetzt fühlen könnte. Geolinamente et malleo✎10:28, 13. Mär. 2018 (CET)[Beantworten]
Wurde die neue Lösung auch im Hinblick auf Barrierefreiheit (mit älteren Browsern, ohne Skripte etc.) getestet? Gäbe es bei Bedarf eine Fallback-Option auf die alte Lösung, auswählbar in den Benutzer-Einstellungen? Für mich persönlich weniger wichtig, für einige andere aber sicher schon. Tkarcher (Diskussion) 17:17, 12. Feb. 2018 (CET)[Beantworten]
@Tkarcher: Danke für deine Frage. Es wurde getestet, ob die Idee (leicht abgewandelt) auch ohne JavaScript funktioniert. Das macht sie. Was Browser angeht, so soll die finale Lösung natürlich mit allen Browsern funktionieren, die Wikipedia generell unterstützt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 11:45, 15. Feb. 2018 (CET)[Beantworten]
Barrierefreiheit: Farblich könnte das verbessert werden (hab selbst eine Farbsehschwäche) aber obwohl ich nicht blau/gelb probleme hab, konnte ich den linken anklickbaren Kreis(in pastellgelb #FFE18C) erst nach 2.hinkucken sehen (vom Hintergrund unterscheiden). Alle mit Farbsehschwäche, da gibt es viele, und alle haben unterschiedliche Probleme, aber alle haben Probleme mit Pastelltönen (oder überhaupt bei Farbtönen in denen die 3 RGB-Werte fast gleich, für mich dann einfach unterschiedlich helles Grau) sind. Macht doch einfach die Farben kräftiger! Und wenn es als Entscheidung unterschiedlich sein soll rot/blau (Die Bundeswehr hatte bei der Musterung damals eine Ishihara-Farbtafel mehr als der Augenarzt, um Simulanten zu erwischen, die war rot/blau). Rotblaufarbsehschwäche gibts wohl nicht, rot/grün ist es meistens, gelbblau soll es seltener geben, aber warum nicht auch darauf Rücksicht nehmen?
Noch was auf welche Farben wird umgeschaltet wenn man mit der Maus drauf geht? ich seh das nicht (ist für mich ein bläuliches Grau bei beiden) kann es aber mit meinem Farbenblindenhund (Programm das mir per Lupe die RGB-Werte eines Pixels anzeigt, & dann weiß ich meist was das für eine Farbe sein soll) nicht messen, da wenn ich mit dessen Lupe auf den Kreis geh der natürlich nicht gehighlitet wird, und ich nur obige Werte angezeigt bekomme.
@Finte: Danke für das ausführliche Feedback! Wir nehmen das gerne auf. Danke auch für das Angebot, dass wir uns bei Fragen an dich wenden können. Zur Frage, auf welche Farben umgeschaltet wird, wenn man mit der Maus drauf geht, gibt es ein ähnliches Anliegen auf Phabricator, der Plattform für Fehlermeldungen und Co. Falls du Lust hast, kannst du dort gerne (auf Englisch) mitdiskutieren. Das muss aber nicht, dein Feedback ist auch so angekommen. Mich würde noch interessieren: Hat dir die Funktion ansonsten denn gefallen? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:25, 14. Feb. 2018 (CET)[Beantworten]
Zum hellen Gelb: Ich finde es auch zu dezent, und ich habe keine Farbsehschwäche. Sieht für mich in unausgewähltem Zustand so aus als wäre der blaue Kreis selektiert.
Beim Hovern wird auf beiden Seiten der Rand blau, hast du also richtig gesehen. Tipp zum Farbmessen bei sowas: Screenshot machen und davon messen ;-)
Und ich hänge mal noch ein Farbproblem hier an: Die Ausblendung der nicht gewählten Version sieht seltsam aus: Sie ist zu schwach, um wirklich als Ausblendung wahrgenommen zu werden, aber kräftig genug, um irritierend zu sein. Eine stärkere Ausblendung würde aber die Lesbarkeit zu sehr beeinträchtigen. --nenntmichruhigip (Diskussion) 23:15, 12. Feb. 2018 (CET)[Beantworten]
Dem Feedback schließe ich mich an. Vllt wäre es ja ein Ansatz, beide Radioboxen mit einem kontrastreichen Farbton (schwarz?) zu umranden. --FNDE15:02, 18. Feb. 2018 (CET)[Beantworten]
Auch als jemand, der keine Farbsehschwäche hat, muss ich sagen, dass hellblau und hellgelb nicht die beste Wahl für die Unterscheidung sind. Kräftige Farben (z.B. dunkelblau und ein leuchtendes rot) wären aus meiner Sicht sinnvoller. --Mogelzahn (Diskussion) 17:35, 19. Feb. 2018 (CET)[Beantworten]
Die grundsätzlichen Farben (hellgelb und hellblau) sind schon seit einigen Jahren in Versionsvergleichen eingeführt und müssen auch als Texthintergrund nutzbar sein. --nenntmichruhigip (Diskussion) 10:32, 20. Feb. 2018 (CET)[Beantworten]
@Nenntmichruhigip:Warum? Nur weil es alt ist, muß es nicht gut sein! Gilt denn: "Das haben wir immer so gemacht, und das verbessern wir nicht"? Ok das kann natürlich mit viel Arbeit in anderen Vorlagen behaftet sein, aber eine Verbesserung für ca. >5% der der Leser (wenn man davon ausgeht das 50% der Leser Frauen sind , die nur in zu vernachlässigbarem Prozentsatz von Farbenblindheit betroffen sind) sollte es doch wert sein da Arbeit zu investieren. --Finte (Diskussion) 23:12, 25. Feb. 2018 (CET)[Beantworten]
die obigen Beiträge, auch von Farbsichtigen (wobei nicht klar ist ob einige nicht doch eine Farbfehlsichtigkeit haben, aber es nur nicht wissen, denn 10% aller Männer haben eine (!), wenn auch sehr unterschiedlich ausgeprägt) bestätigen meinen Beitrag oben: Man sollte kräftige(re) Farben verwenden. Was spricht dagegen? Pastelltöne machen nur Probleme. --Finte (Diskussion) 22:52, 25. Feb. 2018 (CET)[Beantworten]
commander-pirx (disk beiträge) 20:35, 12. Feb. 2018 (CET)
