Wikipedia:Technik/Archiv/Baustellen/Erweiterte Beobachtungsliste komprimieren

Wunsch für ein neues Gadget.

Funktion

Der Informationsgehalt der erweiterten Beobachtungsliste soll in Kurzform darstellt werden; also nur ein Eintrag für jede Seite.

Ausgangslage

Auf der Beo gibt es standardmäßig zwei Darstellungsvarianten:

1. Nur den aktuellsten Vorgang zu jeder Seite anzeigen
2. Alle Einzelvorgänge zu jeder Seite anzeigen: Einstellung „Erweiterte Beobachtungsliste zur Anzeige aller Änderungen“

Wunsch

Kombination aus beidem:

• Es wird nur ein Eintrag dargestellt; dieser aber auffällig markiert, wenn es weitere (möglicherweise noch nicht gelesene) Veränderungen gibt.

Umsetzung

Relativ trivial.

• Nur bei Erweiterte Beobachtungsliste möglich und sinnvoll.
  • mw.user.options.get("extendwatchlist")
• Auf der HTML-Seite die #mw-content-text durchgehen, ein Objekt mit allen Seitennamen erstellen.
• Als Wert jedes Objekt-Elements Schalter setzen: Wiederholt auftretend, bereits besucht, Kombination aus beidem.
• Anschließend erneut durch alle Einträge gehen.
  • Je nach Wert des Schalter-Sortiments Markierung hinzufügen, Schalter setzen für „Markierung vorgenommen“, Element ausblenden wenn schon oben und „Markierung vorgenommen“.
• Benutzerdefinierbare Markierungen für:
  • „Es gibt weitere Vorgänge“.
  • „Es gibt weitere Vorgänge, die ich noch nicht gelesen habe“.
  • Keine Farb-Unterlegung wegen Kollision mit WP:CSS #Beobachtungsliste, eher Symbol oder Text anhängen.

Vorgeschichte

• MediaWiki Diskussion:Common.js #Funktion erstellt: History-Einträge zusammenfassen
• Wikipedia:Technik/Archiv/2012 #Beobachtungsliste: mehrfach geänderte Seiten markieren

Behelfslösung

Mit Benutzer:PerfektesChaos/js/resultListSort lassen sich die Ergebnisse der Beo sortieren.

• Das ist zwar nicht ganz der gewünschte Effekt, aber es lassen sich erstmal alle Einträge zu einer Seite zusammenhängend auflisten.
• Das Gadget hat eine API. Mit *.fresh() lässt es sich auslösen. Danach kann man die (über alle Tage) vereinheitlichte Liste durchgehen, erkennt jeden neuen Seitennamen und kann die Eigenschaften analysieren wie gewünscht und die gefundenen Listeneinträge zur Seite durch einen selbst geeignet aufgebauten Item ersetzen.
• Mit resultListSort müsste man sich etwas abstimmen; ggf. eine API-Funktion nachliefern, mit der die Portlet-Links entfernt werden und die weitere Funktion deaktiviert wird.
• Die Funktionalität von resultListSort erlaubt es, alle Beiträge zu einer Seite zusammenzustellen, oder nach Benutzern (XY hat 4 edits; wen’s interessiert).

---

Ich finde das Script toll, beispielsweise für Spezial:Linkliste oder Spezial:Weblinksuche! IMHO sollte das Script „bekannt gemacht“ werden. Ev. hätte es auch Gadget-Potential.

Für den ursprünglichen Einsatzbereich ist es für mich weniger geeignet. Da ich einige stark frequentierte Seiten beobachte, ist die nicht um Mehrfacheinträge erleichterte erweiterte Beobachtungsliste sehr lang. Mittels eines URL-Parameters von der normalen auf die erweitere Beobachtungsliste wechseln geht wohl nicht, oder? --Leyo 23:39, 27. Nov. 2012 (CET)

• Schön, wenn es dir gefällt. Du kannst gern Reklame machen.
• Gadget-Potential: Was ich für den internationalen Markt entwerfe, schreibe ich auf mw:.
• Soweit ich das überblicke, wird der Wechsel von erweiterter zur Standard-Benutzerliste über die Benutzer-Einstellungen vorgenommen. Der Server guckt also vor Auslieferung der Beo-Version in die Benutzer-Einstellungen; da muss er eh schauen, welche Seitennummern auf der individuellen Beo stehen.
• Es ist technisch möglich, immer die erweiterte Beo auszuliefern, aber für Seiten eines bestimmten Namens alle Einträge bis auf den jüngsten oder die jüngsten drei auszublenden oder auch nicht; oder nur die ersten und letzten drei des Anzeige-Zeitraums sichtbar zu halten. Das kann auf Basis der ursprünglichen langen nach Namen sortierten Beo erfolgen und lässt sich beliebig ein- und ausschalten, oder die ersten vier und letzten beiden oder was. Hier fehlt es mir an einem Use Case; ist nicht mein Arbeitsstil. Ich würde ja auch wissen wollen, was und wieviel und von wem sich auf der turbulenten Seite getan hatte; dass sie sich überhaupt laufend ändert, ist mir ja dann klar.

LG --PerfektesChaos 23:55, 27. Nov. 2012 (CET)

Ich halte zwei Varianten für praktisch:

• Wenn eine Seite im eingestellten Zeitraum mehrfach editiert wurde, wird neben dem Eintrag der letzten Änderung ein Icon (beispielsweise ein Pluszeichen) eingeblendet. Die Einträge aller andern Änderungen werden ausgeblendet. Die Versionsgeschichte kann ich mir mittels Popups-Gadget anschauen.
• Unterschied zu oben: Mittels Klick auf das Icon werden die Einträge der andern Änderungen ausgeklappt. Ich stelle mir das ähnlich wie da vor.

--Leyo 00:08, 28. Nov. 2012 (CET)

Grundsätzlich ist sowas technisch möglich.

• Es kann jemand sowas aufbauend auf meinem vorangegangenen resultListSort-Ergebnis umsetzen. Voraussetzung ist, dass man bereits nach Seitenname sortiert hätte. Bei Sortierung nach Benutzern mag man ebenfalls so eindampfen, dass pro Benutzername nur ein Eintrag sichtbar bliebe; das ist vielleicht was für RC und IP, aber nicht mein Aufmerksamkeitsgebiet.
• Man kann einmalig durch die sortierte Beo durchgehen und jedem Eintrag zusätzliche Klassen zuweisen:
  • Jeder Eintrag zu einem Seiten- oder Benutzernamen außer dem ersten erhält zusätzlich eine Präfix-„Plus“-Klasse.
  • Jeder Eintrag von grad eben könnte eine Klasse Präfix-„Plus“-„Name“ erhalten; oder man verwaltet das besser nicht über DOM-Klassen, sondern dynamisch in JS.
• Mit einem zentralen Klick kann man dann alle zusätzlichen Einträge aller Namen ein- und ausblenden. Das entspräche on the fly dem Umschalten zwischen erweiterter und einfacher Beo.
• Mühsamer wird es, zu jedem Seiten- bzw. Benutzernamen dabei auch durchzuzählen und vor jeden ersten Eintrag einen Link zu setzen: „+17“ oder „X“ (einklappen). Damit könnte man ggf. die Klasse Präfix-„Plus“-„Name“ später ein- und ausblenden.
  • Es ist wahrscheinlich sinnvoller, für die einzelnen Namen nicht mit DOM-Klassen zu arbeiten, sondern alle Einträge einzeln sichtbar oder unsichtbar zu schalten, deren Seiten- oder Benutzername zu dem angeklickten Klapp-Link passt. Auf Knopfdruck lassen sich dann auch als Startposition alle einklappen oder alle ausklappen.

Meine eigene Auftragswarteschlange verendet Nikolaus 2013. Aber dies hier ist ja eine Baustelle.

Beste Grüsse --PerfektesChaos 10:13, 28. Nov. 2012 (CET)

Kombi-Gadget?

Was mir gerade in den Sinn gekommen ist: Wie wäre es, resultListSort und Logs Filter zu kombinieren (nach Klick auf Reiter gemeinsames Interface fürs Filtern und Sortieren) und so als Gadget anzubieten? Den Aufwand dafür kann ich nicht abschätzen. --Leyo 21:38, 2. Jan. 2013 (CET)

Frohes Neues!

Nach erstem Überfliegen des Quellcodes sehe ich nicht, dass man die beiden Skripte nicht gleichzeitig benutzen können könnte. Das müsstest du berichten können.

Die Konzepte sind allerdings widersprüchlich. Ich lasse alle Listenpunkte komplett und sortiere (bislang keine Logbücher, sondern zutreffende Seiten). Wer etwas sucht, scrollt zum gewünschten Kriterium. Ein Formular, in das man erst etwas eintippen müsste, mag ich nicht. Insbesondere keine regulären Ausdrücke für Normalbenutzer.

Gibt es denn irgendwas wie eine Doku-Seite zu dem Teil; irgendeine Konzeption? Gar eine Bedienungsanleitung?

VG --PerfektesChaos 22:45, 2. Jan. 2013 (CET)

Dir ebenfalls alles Gute fürs 2013! commons:MediaWiki talk:Gadget-rightsfilter.js ist wohl noch das beste an „Dokumentation“…

Die beiden Scripts können gleichzeitig benutzt werden. Ich fände eine Kombination der beiden Konzepte gerade reizvoll. Es geht dabei primär um eine gemeinsame Eingabemaske/Auswahlmöglichkeit. Ergänzend könnte eine Kombination der Funktionalitäten auch praktisch sein: Zuerst filtern und den Rest dann sortieren. Aber wie gesagt, es war nur eine spontane Idee. Ich wäre nicht enttäuscht, wenn sie nicht umgesetzt wird… --Leyo 23:36, 2. Jan. 2013 (CET)

Ja, die hatte ich gelesen und mir daraus einen Überblick verschafft. Installieren möchte ich das Teil nicht; da ich kein Admin bin, lese ich auch keine Logbücher.

Solange die beiden sich nicht ins Gehege kommen, ist ja alles gut. Man kann auch vorher sortieren und danach filtern. Ich habe allerdings aufgrund des unterschiedlichen Formats der Spezialseiten bereits 8 verschiedene Eintragungs-Formate, und in denen noch die Benutzer mit regulären Ausdrücken Felder zu definieren und dann zu invertieren und trallala – das wird zu konfus. So habe ich meine 1–4 Links für die Kriterien, und den Rest kann man sich über Scrollen erschließen. Special:Log hatte ich noch nie analysiert. Wäre aber kein Problem, die Ergebnisse nach Datum, Ausführender, Ziel, Aktivität, Grund genauso zu sortieren wie die Trefferseiten.

Grüsse --PerfektesChaos 23:57, 2. Jan. 2013 (CET)

Ich nutze das Gadget vor allem für die Beobachtungsliste und Beitragslisten. Ich stelle mir vor, dass dies bei andern ähnlich sein dürfte. Der Name ist insofern etwas irreführend.

Korrektur zu oben: „Zuerst filtern, dann sortieren“ funktioniert bereits jetzt (wo dein Script aktiv ist). --Leyo 00:17, 3. Jan. 2013 (CET)

• ? Wessen Name ist insofern etwas irreführend, rightsfilter oder resultListSort?
• Ich sehe kein Problem, irgendwann
  • Special:Log zu sortieren nach (langt hoffentlich)
    • Aktivität + Details
    • Aktivität + Zeitpunkt
    • Ausführender Benutzer + Aktivität
    • Ausführender Benutzer + Zeitpunkt
  • Ansonsten ist es ziemlich kompliziert, weil es -zig Arten und Formate von Aktionen gibt bis hin zu Artikelrückmeldungen, Benutzeranmeldungen und sonstwas.
• Eine Kombination in einem Gadget halte ich nicht für zielführend. Ich biete eine kontextsensitive Auswahl an geeigneten Sortier-Links; man kann mit einem Mausklick hin- und herschwappen, scrollen und schauen, wann es passt. Das Filter-Teil bietet ein Formular, bei dem man vorher schon wissen muss, was man eintippt. Benutzer mögen zwischen den beiden wählen, oder beide benutzen, oder das eine, das ihnen gefällt, behalten. Da sie sich offenbar gegenseitig nicht stören, ist das egal. Die Kombination in einem Skript würde bedeuten, dass jeder Anwender auch noch extra in der common.js konfigurieren muss, ob das Formular angezeigt werden soll, oder ob es ausgeblendet werden soll weil es stört. So reicht ggf. das Häkchen auf der Einstellungen-Seite.

Schönen Sonntag --PerfektesChaos 11:29, 6. Jan. 2013 (CET)

• Ich hatte mich dabei auf Logs Filter bezogen.
• Den Hauptsinn des Kombigadget sah ich in den dadurch bestimmt bald breiteren Einsatz deines nützlichen Scripts.

--Leyo 21:40, 6. Jan. 2013 (CET)

Neues Tool und Abschluss der Angelegenheit

Benutzer:PerfektesChaos/js/watchlistTools erfüllt zusammen mit dem unter pref#RC versteckten Feature alle Anforderungen. --PerfektesChaos 20:53, 5. Feb. 2013 (CET)

Vielen Dank! Ich hab's in der en-WP getestet und es funktioniert wie gewünscht.

Dennoch ein paar kleine Anregungen:

1. Die Option Group changes by page in recent changes and watchlist (requires JavaScript) im Tab Recent changes wirkt sich auch für die Beobachtungsliste aus. Dies ist zwar eigentlich sinnvoll, aber etwas verwirrend.
2. Nachdem man obige Option angewählt hat, ist das Entfernen des Hakens in Group by pages wirkungslos.
3. Könnte bei Group by pages ev. auf das Bestätigen mit „Go“ bzw. „Anwenden“ verzichten?
4. Ich fände es schöner, wenn für Group by pages nicht eine ganze Zeile verwendet würde. In der en-WP nutze ich den Vector-Skin, wo mich die (vertikale) Platzverschwendung eh stört.
5. Ich schaue mir häufig mittels Popups die Versionsgeschichte (teilweise zeitlich viel weiter zurück als für die Beobachtungsliste eingestellt) an, um so beispielsweise direkt auf den zuletzt von mir bearbeiteten Abschnitt zu springen. Da nun die History-Links nicht mehr untereinander sind, ist dies etwas weniger praktisch.

--Leyo 23:54, 5. Feb. 2013 (CET)

1. Das ist nicht von mir, und bis letzte Woche kannte ich den noch nicht mal: Benutzer Diskussion:Umherirrender #enhanced Beo/RC – ich bin kein RCler.
2. Nach dem Entfernen des Hakens müsstest du die Beo in irgendeiner Weise neu aufrufen. Der Haken ändert nur im Inneren die Links und versteckten Formularwerte.
3. Wie vor; dieses Go / Anwenden ist erstmal nicht von mir. Es ist die ganz normale Beo. Ich könnte über eine Benutzeroption nachdenken, die bei der Veränderung von jeder dieser Optionen ohne Go sofort startet. Aber eigentlich sollte das ganze Gadget sich selbst überflüssig machen, indem das grouping von der MW-Software angeboten wird. Deshalb auch auf der enWP und nicht auf MW, wo ich die langfristigeren globalen Tools in Stellung bringe.
4. Habe zurzeit keine glücklichere Möglichkeit für das Layout in jeder Lebenslage, ohne dass es konfus wird.
5. Verstehe ich nicht. Ich hätte aber wohl ohnehin nichts damit zu tun.

Gute Nacht --PerfektesChaos 00:15, 6. Feb. 2013 (CET)

• Auf Bestätigen mit „Go“ bzw. „Anwenden“ verzichten – Es gibt in der aktuellen Version ein Direktlink, das an Stelle der Checkbox die Aktion sofort auslöst.
• Es gibt eine individuelle Option lean, die die gesamte Optionsbox komprimiert.
• Cache-Löschung bedenken.
• Hier ist die Sache erledigt; weiter auf der Gadget-Disku.

Gute Nacht. --PerfektesChaos 00:04, 11. Feb. 2013 (CET)

Der Direktlink (on/off) ist sehr praktisch.

Aktuell werden bei mir in der Watchlist einige Mehrfachedits in Artikeln zu mehreren (Tages-)Gruppen zusammengefasst. Beispiele: en:Glyphosate oder en:Switzerland. Ist das so gewollt oder nicht anders möglich?

Artikel, wo ich den letzten Edit gemacht habe, erscheinen auch in der Beobachtungsliste.

Das Filter-Gadget funktioniert nicht mehr.

Zu 5.) Die Anordnung der verschiedenen Elemente wird ja durch dein Script bestimmt. Und dieses bewirkt, dass die Links auf die History nicht mehr „schön“ untereinander liegen, was für mich eine Komforteinbusse bedeutet. --Leyo 02:28, 11. Feb. 2013 (CET)

Gute Nacht! --Leyo 02:28, 11. Feb. 2013 (CET)

Noch was: Vielleicht könntest du die Unterschiede zu Nightfly85s historyCombine grob angeben. Dass die erweiterte Beobachtungsliste benötigt wird, ist ja beiden gemeinsam (und entspricht in diesem Punkt nicht meiner ursprünglichen Idee). --Leyo 10:36, 11. Feb. 2013 (CET)

(nach einem merkwürdigen unentdeckten BK; es gab aber zwischendurch auch einen unentdeckten 500er ServerError bei Wikimedia) Nochmals:

• Die Funktion „nach Seiten gruppieren“ ist eine allgemeine weltweite Server-Funktion.
  • Sie ist seit 2011 verfügbar; ich kenne sie erst seit Ende Januar 2013.
  • Ich habe keinerlei Einfluss auf die Gestaltung oder Anordnung der Einträge.
  • Um sie ein- und auszuschalten, war es bisher erforderlich, auf die Einstellungen der Letzten Änderungen zu gehen, dort zu ändern und diese zu speichern. Alternativ kann man in der URL mit dem enhanced-Parameter spielen.
• Mein Gadget macht nichts anderes, als auf der Benutzeroberfläche Möglichkeiten bereitzustellen, um dieses Feature gleichzeitig mit weiteren Optionen spontan ein- und auszuschalten. Es wirkt hier lediglich oben innerhalb der Optionsbox.
  • Durch die eine Anordnung, die für bestimmte Übersichten vorteilhaft ist, entstehen für andere Aktivitäten Nachteile und sind schwerer umsetzbar. In jedem Szenario gibt es eine bestimmte Kombination von Optionen, um eine bestimmte Fragestellung individuell strukturiert zu beantworten.
  • Wenn du eine bestimmte Analyse in dem einen Optionssatz nicht dargestellt bekommst, kannst du flink einen anderen zusammenklicken.
  • Für besonders häufige Standard-Auswertungen empfiehlt es sich, zum Schluss nicht die Formular-Beendigung [Anwenden], sondern ein Link anzuklicken; dann erhält man eine komplette URL und kann sie als Bookmark speichern.
• Dass das Filter-Gadget nicht funktioniert, wundert mich nicht; resultListSort kennt die Gruppierung zur Stunde auch noch nicht. Letzterer wird im Lauf der Woche das Format erkennen und sortieren lernen.

Schönen Tag --PerfektesChaos 10:41, 11. Feb. 2013 (CET)

• Mit Nightfly85s historyCombine habe ich nichts zu tun; anscheinend sortiert er selbst um. Ich nutze die weltweite Server-Funktion.
• Die erweiterte Beobachtungsliste wird zwingend auf Seiten-Ebene benötigt; andernfalls gibt es zu jeder Seite immer nur genau einen Eintrag mit genau einer Bearbeitung, und es ist nicht bekannt, ob und wo es wann mehrere Bearbeitung gegeben haben könnte.
  • Die Alternative wäre, von Grund auf neu über die API erst eine mw:API:Watchlist mit wlallrev abzurufen, und dann auf einer selbst geschaffenen Spezialseite die von dir gewünschten Informationen von Grund auf neu darzustellen.
  • Einen URL-Parameter (extend?) dafür sehe ich erstmal nicht, sonst könnte ich den mit einflechten.

Soweit der Nachtrag zu 10:36; Grüsse --PerfektesChaos 10:56, 11. Feb. 2013 (CET)

(BK) Da hatte ich wohl tatsächlich eine ziemlich lange Leitung… Dass die Darstellung durch die Option Seitenbezogene Gruppierung in den „Letzten Änderungen“ und auf der Beobachtungsliste erzeugt wird, war mir nicht klar. Ungünstig dabei war, dass diese in de-ch weniger klar beschriftet ist, nämlich Erweiterte Darstellung der «Letzten Änderungen». --Leyo 11:01, 11. Feb. 2013 (CET)

---

Diese Baustelle ist geschlossen und wird demnächst archiviert. --PerfektesChaos 00:04, 11. Feb. 2013 (CET)