Wikipedia Diskussion:Technik/Baustellen/Warnung wenn Zusammenfassung fehlt

Fragen, Hinweise und Verwunderung

• Was ist (Z+Q)?
• Links zu Wikipedia:Technik/Skin/Werkstatt#Farbige Hervorhebung, wenn die Zusammenfassung fehlt und möglicherweise weiteren Diskussionen fehlen. Dort wurden bereits sehr viele Argumente gesammelt.
• Die Frage, welche Nutzeraktion die Warnung auslösen soll, wird hier aktuell gar nicht angerissen. Ich hatte mich in obiger Diskussion schon dazu geäußert und bin auch weiterhin davon überzeugt, dass das Speichern (Submit) diese Aktion sein muss. Weder das Eingeben von Zeichen noch das Verlassen des Textfeldes (per Tabulatortaste oder anders) bedeutet automatisch, dass der Benutzer etwas „vergessen“ hat und „gewarnt“ werden muss. Ich könnte mir allenfalls vorstellen, onChange-Events auf die Checkboxen zu legen, das heißt auf alle Formularelemente, die unterhalb der Zusammenfassungszeile liegen.
• Die server- und clientseitigen Nachteile heben sich weitestgehend auf, indem man das einfach kombiniert.
• Warum sollte ein „Eingriff“ in den Speichern-Button „riskant“ sein? Es ist absoluter Standard, entweder per onClick auf dem Submit-Button oder per onSubmit auf dem Formular zu entscheiden, ob der Submit zugelassen werden soll (return true) oder nicht (return false). Das Speichern darf natürlich niemals blockiert werden, aber so lange zumindest das gewährleistet ist, halte ich es für komplett irrelevant, wenn irgendwelche obskuren älteren Browser das Speichern ohne Warnung erlauben. Den Vorschlag mit dem zweiten unsichtbaren Button halte ich aus eben diesem Kompatibilitäts-Grund für einen indiskutablen Hack. Damit handelt man sich zwangsläufig Ärger ein (etwa, wenn der echte Button nicht wieder sichtbar werden will, was bei einem simplen return true nicht passieren kann, da das keinerlei DOM-Umbau oder Neurendern erfordert).
• Viele weitere Hinweise sind sehr nützlich, etwa mit dem Tastenkürzel oder vorbelegter summary. Ich werde meinen Lösungsvorschlag daraufhin abklopfen.

--TMg 13:25, 29. Jul. 2012 (CEST)

• Z+Q: Siehe WP:Z&Q.
• Link zu Wikipedia:Technik/Skin/Werkstatt#Farbige Hervorhebung, wenn die Zusammenfassung fehlt steht unter Wikipedia:Technik/Baustellen/Warnung wenn Zusammenfassung fehlt#Diskussion ab 2011, demnächst archiviert. Hier geht nichts verloren.
• Die Frage der Folge-Aktion ist auch nicht geklärt. Aus der überquellenden Flut an jahrelanger Disku versuche ich die wesentlichen Punkte herauszuarbeiten und übersichtlich zusammenzustellen; so weit war ich beim Setup dieser Seite noch nicht gekommen, hier die Lösungsansätze in puncto Aktion gegeneinander aufzulisten. Als Überschrift habe ich gewählt „Elemente auf dem Weg zur JS-Lösung“; dem lässt sich entnehmen, dass ich das Ziel bislang nicht erreicht sehe.
• Das Risiko beim „Eingriff“ in den Speichern-Button besteht darin, dass nicht-standardkonform arbeitende Browser ungeschickte Eingriffe in die Event-Queue nicht oder nicht immer richtig verarbeiten könnten und Benutzer mit derartigen Browsern nie wieder eine Seite abspeichern können, weil ihr Speichern-Button nicht mehr geht und der stundenlange Edit futsch ist.

HGZH PerfektesChaos 14:27, 29. Jul. 2012 (CEST)

Würde dieses Argument nicht jede denkbare JavaScript-Lösung zunichte machen? Ich wüsste ehrlich gesagt auch keinen Fall, in dem es nicht wie beschrieben wenigstens möglich wäre, es so zu programmieren, dass es im Fall einer Inkompatibilität wenigstens nichts bewirkt. Hast du ein Beispiel für so einen Fehler? --TMg 15:52, 29. Jul. 2012 (CEST)

Der Begriff „Risiko“ bedeutet nur, dass man hier äußerst vorsichtig und sorgfältig vorgehen muss; er bedeutet nicht, dass man überhaupt nichts tun kann. Man muss sich beim Entwurf der Gefahr des Datenverlustes bewusst sein und durch entsprechende Mechanismen und ausgiebiges Testen diesen soweit möglich ausschließen. Dann kann man das auch so machen. Beispielsweise kann man einen separaten Speicher-Button mit eigener Zuweisung parallel in das DOM einfügen; erst nachdem sich das Skript vergewissert hat, dass der zusätzliche Button im DOM auch angekommen ist, dürfte der Standard-Button unsichtbar geschaltet werden. Auch jeder medizinische Eingriff ist ein Risiko; aber man kann am offenen Herzen operieren, wenn das Risiko in sinnvollem Verhältnis zum erwartbaren Vorteil steht.

Im Übrigen bin ich zurzeit lediglich dabei, die Dauerbaustellen aus der aktuellen Werkstatt-Diskussionsseite herauszuziehen, und nicht bei der Lösung mehrjährig ungeklärter Probleme.

Schönen Sonntag --PerfektesChaos 16:15, 29. Jul. 2012 (CEST)

Der einzige „Lösungsvorschlag“, den du aktuell präsentierst, ist der mit der DOM-Manipulation, und genau diesen Vorschlag halte ich für unsinnig verkompliziert. Du wirst niemals sicher stellen können, dass der Button korrekt positioniert und gerendert wurde und gedrückt werden kann, außer du wartest auf einen tatsächlichen Klick des Benutzers. Du sprichst von Risiko und hantierst gleichzeitig mit einem Hack, wie er risikoreicher kaum sein könnte? Und behauptest auch noch, das wäre „wesentlich sicherer“? Sicherer als was? Warum nicht einfach ein return false und eine CSS-Klasse, wie es hunderttausendfach im Web erprobt ist? --TMg 03:39, 30. Jul. 2012 (CEST)

• Ich bin im Moment nicht dazu da, Lösungsvorschläge zu präsentieren.
• Im Übrigen ist es unrichtig, ich hätte hier lediglich „einen einzigen Lösungsvorschlag präsentiert“; tatsächlich habe ich drei Skriptvarianten verlinkt.
• Ich ziehe aber nur aus einer seit 2009 laufenden und bislang nicht zu einem allseits befriedigenden Ergebnis gekommenenen und auf einem Dutzend verschiedener Seiten geführten Diskussionen die Rahmenbedingungen, Grundvoraussetzungen, Aspekte, Problemstellungen heraus und stelle sie zusammen.
• Eines ist jetzt schon klar: Es wird nicht die eine einzige Lösung geben, sondern mehrere Systeme parallel mit teils benutzerkonfigurierbaren Detailgestaltungsmöglichkeiten.
• Ziel der momentan neu erstellten Seiten ist es lediglich (wie bereits oben erwähnt), zum einjährigen Jubiläum der Werkstatt die Knacknüsse aus der Diskussion aktueller und kurzfristig lösbarer Anfragen herauszuziehen und die Anfragen aus 2011 weitmöglichst abzuschließen. Zu den Dauerbrennern gehört auch dieses Thema hier.

--PerfektesChaos 12:59, 30. Jul. 2012 (CEST)

Ich stelle meine Frage anders: Woher ist das „gezogen“, was aktuell im Abschnitt „Speichern-Button“ steht und womit ich wie oben erläutert Probleme habe? --TMg 00:29, 6. Aug. 2012 (CEST)

• Es gab auch in den nicht aufbereiteten Diskus der Vorjahre Einwände gegen Manipulation des Speichern-Buttons; zu Beginn der Werkstatt-Disku 2011 schrieb der Umherirrende: „Es soll aber niemals das Speichern verhindert werden, wie es beispielsweise die Lösung der polnischen Wikipedia macht.“
• Ein Eingriff in die Event-Queue ist (wie jede Skript-Aktion) nun mal mit Risiken verbunden. Hier sind die Folgen aber besonders schwerwiegend:
  • Wenn der Speichern-Button nicht mehr richtig funktioniert, können Benutzer nicht einmal auf FzW die Frage stellen, was sie tun sollen (Einfache Erste Hilfe: Im Browser JS deaktivieren).
  • Bei nur gelegentlich und unvorhersehbar auftretenden Schwierigkeiten geht der Edit verloren (gut, man könnte geistesgegenwärtig in ein notepad speichern, aber bis man wieder arbeitsfähig ist, gibt es vielleicht schon eine neue Version, die damit überschrieben würde).
  • Gewünscht wird, dass die Methodik verpflichtend für alle IP (die keine Möglichkeit zum opt-out haben) und Default für alle angemeldeten Benutzer werden soll. Da ist in der großen Zahl Betroffener die Chance auf einen Glückstreffer besonders gut; anders bei auf eigene Initiative erfolgtem opt-in.
• Die Event-Queue ist Teil des DOM, nicht von HTML. Ein HTML-konformer Browser kann DOM-Events abweichend handhaben.
• Wer Umfunktionierung des Speichern-Buttons vornimmt, muss einen von zwei Nachweisen führen:
  • Die Funktionalität wurde an allen von WMF-Projekten unterstützten Browserversionen intensiv getestet.
  • Die Programmierung enthält Sicherheitsprüfungen, die den Eingriff erst vornehmen, wenn seine sichere Ausführung gewährleistet ist, oder bieten entsprechende Fallback-Mechanismen; wenn die Reaktivierung scheitern würde, darf auch nicht deaktiviert werden.

--PerfektesChaos 10:24, 6. Aug. 2012 (CEST)

Vorteile der Serverseitigen Implementierung

Ich sehe auch Vorteile:

• Funktion ist schon implementiert und muss einfach nur angeschaltet werden (außerdem liegt ein MB zu genau dieser Funktion vor!)
• Automatisierter Vandalismus wird minimiert, da durch das neu Laden der Seite eine Zeit entsteht, die sich mehreren 1000 Edits zu schmerzhaften Wartezeiten für Vandalen addiert, so dass diese keine Lust mehr haben (man vergleiche z.B. die 3 Sek. Wartezeit zum Download bei Sourceforge oder Captcha-Varianten usw.
• Normale Benutzer klicken erst Tabs weg, wenn sie eine Bestätigung bekommen haben, dass ihre Transaktion erfolgreich war (man vergleiche z.B. Online-Banking oder Amazon-Kauf usw.) der "Nachteil"-Punkt ist daher eher "an der Nase herbeigezogen"
• Durch den Neulade-Mehraufwand überlegt der Nutzer, ob sein Edit wirklich diesen Aufwand wert ist. Schüler-Vandalismus à la "Thomas ist schwul" usw. werden daher stark unterdrückt, da der Vandale keine Lust hat mehr Zeit und Hirnschmalz in die Funktionsweise der Zusammenfassungszeile zu stecken. Die validen Edits sind daher von Erhöter Qualität

Keine Ahnung, wer diese Seite pflegt, oder darf ich diese Punkte selbst einfügen?--svebert (Diskussion) 11:42, 6. Aug. 2012 (CEST)

Diese Seite hier leitet sich von Skin/Werkstatt ab und beschäftigt sich deshalb mit der Entwicklung einer client-basierten, also JS-Lösung.

Die Frage formaler Gültigkeit von MB und daraus für irgendwen erwachsender Verpflichtungen steht hier absolut nicht zur Debatte.

Hier geht es um programmierungstechnische Fragen und vor allem um die Herausarbeitung von Anforderungen sowie Spezifikationen für ein Gadget.

Bleib mal besser auf dieser Disku-Seite.

--PerfektesChaos 13:14, 6. Aug. 2012 (CEST)

Danke für die Klarstellung. Bin irgendwie hier gelandet und fand, dass wenn Nachteile aufgelistet werden, wohl auch Vorteile aufgelistet werden sollten. Sonst macht so eine Auflistung wenig Sinn.

Da die Technik wohl auch angewendet werden soll wenn sie fertig ist, ist es aber trotzdem wichtig den Blick über den Tellerrand nicht zu verlieren und dazu gehört auch, dass man halt das Rad nicht unbedingt neu erfinden muss, wenn es schon existiert (ja, ich sehe, dass die Java-Lösung mehr Einstellungsmöglichkeiten aufweist und unbürokratischer umzusetzen ist)--svebert (Diskussion) 14:14, 6. Aug. 2012 (CEST)

Der Zweck dieser Seite ist es nicht, eine Entscheidung darüber zu treffen, ob client-basiert oder server-basiert. Es ist daher hier auch nicht Aufgabe, ausgiebig und neutral irgendetwas gegenüberzustellen.

Ausgangspunkt ist hier, dass die server-basierten Wege nicht allgemein akzeptierbar zu sein scheinen; zumindest sind sie seit 2009 nie dauerhaft für alle aktiviert worden. Dann stellt sich die Frage, wie eine alternative client-basierte Lösung aussehen müsste. Dazu liefern die Diskussionen der vergangenen drei Jahre aber wenig bis null konkrete und handfeste Rahmenbedingungen, wie genau denn das Verhalten und die Darstellung der einzelnen GUI-Elemente aussehen solle und auf die Abfolge welcher Benutzeraktionen hin sich welche Aktivitäten innerhalb von wie vielen Zehntelsekunden entwickeln sollen. Ohne eine intuitiv verständliche, sichere und prompte Benutzerführung wird das aber wohl nichts werden.

--PerfektesChaos 20:34, 6. Aug. 2012 (CEST)

Null-Edit

Welche IP macht gezielt Null-Edits???

Angemeldete Benutzer könnten das serverseitige Helferlein ausstellen.

Daher sehe ich nicht die Notwendigkeit, dass bei der technischen Umsetzung Null-Edits berücksichtigt werden müssten. Ich würde fast dafür plädieren, dass Null-Edits von IPs halt auch sinnvoll zusammengefasst werden, da man sonst oft als Sichter wertvolle Zeit investieren um dann nach 5 Sek erst zu verstehen, dass es sich bei diesem "komischen" Edit um einen Null-Edit handelt!--svebert (Diskussion) 11:46, 6. Aug. 2012 (CEST)

Technischer Hinweis: Echte Null-Edits tauchen nicht in der Versionsgeschichte auf. --Steef ³⁸⁹ 12:49, 6. Aug. 2012 (CEST)

@Svebert:

Das zu entwickelnde Gadget richtet sich sowohl an angemeldete wie an nicht-angemeldete Benutzer.

Angemeldete Benutzer (gerade Admins oder Wartungs-Techies) haben sehr wohl die Notwendigkeit, Null-Edits auszuführen.

Ich habe die Befürchtung, dass du gar nicht so genau weißt, was ein Null-Edit eigentlich ist. @Steef: Danke schön.

--PerfektesChaos 13:17, 6. Aug. 2012 (CEST)

? Laut WP:Glossar werden Nulledits in der Versionsgeschichte angezeigt, zumindest Purge-Äquivalente Null-Edits. Den Null-Edit zweiter Art verstehe ich nicht so ganz... Liegt WP-Glossar falsch???

Ich bin aufjedenfall schon über Null-Edits gestolpert und habe mich gefragt, was hier los ist... Eine Zusammenfassung mit dem Stichwort "Nulledit" hätte mir einige Verwunderung erspart--svebert (Diskussion) 14:20, 6. Aug. 2012 (CEST)

Wenn unsere Server-Software nicht gerade rumspinnt, wie das vor einigen Wochen vorübergehend der Fall war, dann tauchen Null-Edits nicht in der VG auf.

Der hier in Rede stehende (echte) Null-Edit ist in Hilfe:Glossar #Nulledit als Fall #2 korrekt dargestellt. Was als Fall #1 beschrieben wird, ist gerade die Umgehung eines Null-Edits durch ein irgendwo angehängtes Leerzeichen, das in der dargestellten Seite nicht sichtbar wird.

Nur beim echten Null-Edit hätte ein zu entwickelndes Skript keinen Bearbeitungskommentar zu fordern, wobei die Zeichenketten des Ausgangszustands des Wikitextes und der momentane Inhalt des Bearbeitungsfeldes miteinander zu vergleichen sind. Wird dazwischen ein Unterschied festgestellt, und sei es ein Leerzeichen, handelt es sich nicht um einen Null-Edit und ein Bearbeitungskommentar wäre erforderlich.

--PerfektesChaos 20:34, 6. Aug. 2012 (CEST)