Wikipedia:Technik/Baustellen/projectNotice

Unsere Technik zur projektweiten Information aller Benutzer könnte modernisiert werden:

• Dauerhafte, Browser-unabhängige Speicherung des Kenntnisnahme-Klicks.
• Flexiblere Verbreitung auch auf anderen Seiten als der Beo; auch falls sich einmal die Verhältnisse ändern.
• Opt-Out verfeinern für aktive Benutzer, die ohnehin über alle aktuellen Vorgänge informiert sind.
• Schnellere und effizientere JavaScript-Prozedur.

Details

• Namensgebung: Analogie zu siteNotice
• Sollte als Default-Gadget implementiert werden.
  • Wird dieses deaktiviert, bekommt man nie eine projectNotice angezeigt.
  • Damit wird auch das lose JS-Gewirr im MW-NR und die Common.js entlastet.
• Ausgelesen werden kann die Eigenschaft aus mw.user.options.get("userjs-gadget-projectNotice") (ziemlich sofort; using "user.options").
• Der Verbergen-Klick sendet per API ein aktualisiertes userjs-gadget-projectNotice an die API:action=options und macht damit auf allen Browsern für alle Zeiten, mindestens aber die Dauer der Bekanntmachung den „Gelesen“-Klick verfügbar.
  • Das ist auch nicht mehr von routinemäßiger Cookie-Löschung und sicherheitstechnischem Komplett-Reset des Browser-Gedächtnisses abhängig.
• Problem der bisherigen Methodik bleibt bestehen: Nur bei aktiviertem JavaScript wird informiert.

Kompatibilität, Parallelentwicklungen, Ausbau

• Zur bisherigen Implementierung MediaWiki:Common.js/watchlist.js muss fast nichts kompatibel sein.
  • Ledigich die Grundfunktionalität ist weiterhin zu unterstützen:
  • Angemeldeten Benutzern auf der Beo eine Nachricht anzeigen.
    • Ausblenden dieser Nachricht ermöglichen.
    • Nur Administratoren können Nachrichten definieren.
    • Nur mit aktiviertem JavaScript wird etwas angezeigt.
    • Ein konventionelles benutzerdefiniertes Immer-Ausblenden der .watchlist-message wird weiterhin unterstützt; zukünftig ist dazu aber das Opt-Out des ganzen Gadgets zu empfehlen.
• Die Funktionalität wird nicht eingegrenzt auf eine bestimmte Seite.
  • Es könnte künftig mal eine globale Beo geben, und dann soll mit minimalem Konfigurationsaufwand eine Verwendung auf beliebigen anderen Seiten möglich sein.
  • Zu denken wäre an Spezial:Benachrichtigungen als weitere Standardseite. Sie könnte aber nicht mit der identischen MediaWiki:Watchlist-summary zusammenarbeiten; aber MediaWiki:Watchlist-summary könnte eine Seite MediaWiki:projectNotice einbinden und diese enthält den momentanen Block, der aber dann auch auf anderen geeigneten Seiten (Eigene Disk) ebenfalls eingeblendet und einheitlich genutzt werden kann. Notfalls mit Zeitverzögerung per API-Abruf der message, falls keine integrierte Einbindung möglich.
  • Die Implementierung erfolgt internationalisiert und kann von beliebigen Wikis übernommen werden. Diese Anforderung verbessert gleichzeitig die Flexibilität und Anpassungsfähigkeit im eigenen Projekt.
• Der Mechanismus der site-notice ist unabhängig programmiert und gilt weltweit. Er arbeitet zurzeit ebenfalls mit Cookies.
  • Problem: Kann immer nur eine notice gleichzeitig verwalten.
  • Vorteil: Funktioniert auch mit abgeschaltetem JS: sehr wichtige Nachrichten werden allen Benutzern angezeigt; können ohne JS natürlich nicht ausgeblendet werden. (außer per Benutzer-CSS)
  • Berücksichtigt in Implementierungsvorschlag
• Die CentralNotice enthält sowieso überwiegend Spendenaufrufe und kann mit #fundraising, .cn-fundraiser-banner {display:none!important} usw. (gar .centralNotice) komplett unterdrückt werden.
  • In #cn-toggle-box wird verwendet die hideBanner() aus mw.centralNotice.hideBanner()
  • Sollte irgendwann mal was Wichtiges von der WMF kommen, wird höfl. ersucht, diese Information als lokale Nachricht zu reproduzieren.
• Hilfe:Echo kommt ja grad in Schwung.
  • Grundsätzlich käme auch eine Integration derartiger Benachrichtigungen dort in Frage.
  • Zurzeit ist aus den Konzepten und der Implementierung nicht ersichtlich, dass ein derartiger Mechanismus vorgesehen sei:

    Out-of-scope:

    no notifications for

    • your watchlist
    • public announcements

  • Wäre aber relativ trivial realisierbar, indem an die Benachrichtigungsliste jedes Benutzers eine virtuelle dynamische Nachricht angehängt wird. So lange diese Nachricht aktiviert ist, erscheint ihr Abbild dort und kann gelesen werden; wenn die zentrale Nachricht wieder physisch gelöscht wird, ist sie auch nicht mehr vorhanden.
• Die mw:Extension:MassMessage ist seit 19. November hier aktiviert.
  • Sie richtet sich dies an eine konkrete Liste einzeln aufgezählter Benutzer; also alle Stammtischbrüder der Kreuzberger Nächte oder alle Mentoren.
  • Für eine Information aller Benutzer des Projekts, die aktuell aktiv sind, ist dies nicht geeignet.
• Virtuelle Diskussionsseitennachricht
  • Man kann auf den Diskussionsseiten aller aktiven Benutzer, so eine BD eingerichtet ist, eine virtuelle Nachricht anzeigen und darauf auch per virtuelles Echo hinweisen.
  • Mit Flow sind aber langfristig Umbrüche zu erwarten.
  • Tatsächlich wird der Seitengeschichte nichts hinzugefügt; der Text erscheint nur temporär, kann als „Gelesen“ weggeklickt werden; nach Löschen der Aktion bleiben keine Spuren zurück.
• Echo+
  • Neben dem roten oder grauen Zähler von Echo wird auf bestimmten Seiten bei Vorliegen von ungelesenen Projektnachrichten ein Ausrufezeichen auf rotem Grund eingeblendet, und bei dessen Anklicken die Benachrichtigung als Pop-Up angezeigt. Solange die einfach feststellbare Seitenbedingung nicht vorliegt, wird auch kein komplexes JS geladen und keine API gefragt.
  • Effizienzproblem: Bei jedem Seitenaufbau angemeldeter Benutzer muss schnell festgestellt werden, ob überhaupt eine Ankündigung geschaltet ist, und ob die bereits gelesen wurde.

Fehler/Probleme in der bisherigen Implementierung

• Bei mehrfachen Nachrichten wird die ID #dismissButton mehrfach vergeben.
• href mit javascript: ist out.
• Es entsteht auf jeder Beobachtungsliste eine globale Variable dismissWatchlistMessage.

Realisierung als Gadget (Nachfolge watchlist.js)

• Das erste und eigentliche Gadget prüft lediglich, ob der Fall wgCanonicalSpecialPageName gleich Watchlist eingetreten ist, oder ein analog zu programmierender.
  • Ist die Situation gegeben, dass ausblendbare Nachrichten vorliegen könnten, wird per mw.loader.load() das Gadget-projectNotice.js/core.js nachgeladen.
  • Leider ermöglicht die Gadget-Definition zurzeit keine Angabe von Systemnachrichten, die automatisch bereits mitgeliefert würden.
    • Damit wäre es möglich, die Systemnachricht bereits vor Dokument-Laden zu analysieren und die prinzipielle Existenz einer Nachricht durch einfache Suche nach einer Zeichenkette zu ermitteln. Auch die Frage der Ein- und Ausblendung kann dann mit schnellen synchronen Browsern bereits vor Laden und Rendern des Dokuments geklärt werden. Das würde Ruckeln vermeiden.

Zwei Ansätze

Ansatz mit Definition als Wikitext

Die Definition möge stehen in MediaWiki:projectNotice.

• Für alle .children() der #gadget-projectNotice würde im aus der Benutzer-Einstellung zu bildenden Array nach den ID gesucht.
  • Gibt es überhaupt keine Kinder (sind keine potentiellen Nachrichten definiert), dann ist die Angelegenheit erledigt.

Muster

Die Seite MediaWiki:projectNotice enthält beispielsweise den folgenden Quelltext:

<div id="gadget-projectNotice" class="watchlist-message">
<!-- Nächste unbenutzte ID: beo42
     Bedienung: [[Wikipedia:Heferlein/projectNotice]]
     Kommentar bitte drin lassen -->
<div id="gadget-projectNotice_beo41" style="display:none;">
<div style="border: 1px solid #bbb;background-color:#8080FF;color:#000000;padding:0.5em;margin:0.3em 0em 0.3em 0em;font-size:110%;">
Das Präsentations-Element wird vom Verwaltungs-Element getrennt.
* Das äußere div enthält nur die Verwaltung für das Gadget.
* Das innere div enthält die spezifische Dekoration
 und den Nachrichtentext.
</div>
</div><!-- 41 -->
</div><!-- #gadget-projectNotice -->

Die MediaWiki:Watchlist-summary würde wie folgt aussehen:

{{MediaWiki:Specialpage-helplink|id=watchlist-help|link=Hilfe:Beobachtungsliste|alt=Hilfe zur Beobachtungsliste}}
{{MediaWiki:projectNotice}}

Ansatz mit Definition als JavaScript

• Ein extrem effizienter aber auch für manche Admins fieser Trick wäre es, den HTML-Code der Nachricht in das JavaScript-Gadget hineinzuschreiben.
  • Den Admins würde es abverlangen, in den Zeilen des HTML-Codes Gänsefüßchen/Apostroph zu escapen und bei mehrzeiliger Formulierung die String-Literale zu verketten.
  • Dafür wüsste das Gadget direkt,
    • ob Nachrichten vorliegen (sonst ist die lokale Variable nicht definiert oder false)
    • welche ID zu welchem Nachrichten-HTML gehört (weil object-key zum Nachricht-val).
  • Das Gadget liegt 10 Sekunden nach Änderung der Nachrichten für jeden Abruf aktuell vor.
  • Wenn die Art der Seite für Nachrichtendarstellung vorgesehen ist und überhaupt irgendeine Nachricht vorliegt, wird mit der lokalen Variablen des Nachricht-Objekts das Anwendungsobjekt in mw.libs gebildet und es wird anschließend der statische /core.js nachgeladen.
    • Abgleich mit den Benutzereinstellungen user.options. Schon gelesen?
      • Für jedes Element ein jQuery-Objekt aus der Nachricht bilden und mit Verbergen-Button-ausrüsten.
      • Alle jQuery-Objekte in einem Container sammeln.
    • Container am mw.util.$content oder so ähnlich einfügen, nachdem document.ready eingetreten ist.
• Support für Wikisyntax, soweit Wikipedia:JS/MW #.jqueryMsg reicht (lokale Wikilinks und Weblinks sollten funktionieren).

Muster für Definition siehe Implementierungsvorschlag.

Vergleich der Ansätze

• Die Definition über JavaScript beansprucht weniger Aktivität beim Laden der Seite.
  • Wenn keine Nachrichten definiert sind, wird das Startmodul sofort wieder beendet.
  • Das HTML-Dokument muss nicht erst durchsucht werden.
  • Es muss auch nicht auf document.ready gewartet werden; das erhöht die Chancen auf ruckelarme Darstellung. Ruckeln ist aber bei beiden Ansätzen unvermeidlich, weil nur der Server das Dokument schlüsselfertig liefern kann; dazu muss er bei Generierung der HTML-Seite bereits den Wissensstand des momentanen Benutzers analysieren. JavaScript kann sich erst nach document.ready auf das HTML auswirken.
• Die Definition über JavaScript dürfte für manche Admins etwas gewöhnungsbedürftig sein.
  • Durch gute Kopiervorlagen sollte das beherrschbar sein, so dass in einen kopierten Rahmen nur noch aktueller Text und aktuelle Farben eingefügt werden müssen.
  • Kopiervorlagen und Links müssen als Editnotice verfügbar sein.
• JavaScript ermöglicht mehrere Nachrichten gleichzeitig, Wikitext mit SiteNotice nur eine, auch an nicht angemeldete Benutzer, die bisherige Watchlist-Message mehrere, nur für angemeldete Benutzer.

Gedächtnis

• Die Benutzer-Einstellung ist eine Separator-getrennte Liste von ID.
  • Sie kann durch einfache Analyse .split() daraufhin geprüft werden, ob bestimmte ID (als ansonsten beliebige Zeichenketten) dem Server für diesen Benutzer bereits bekannt sind.
  • Ist keine Benutzer-Einstellung vorhanden, wird die Länge des Arrays auf Null gesetzt und die Suchschleife fasst kein Array-Element an.
  • Wird im Array keine ID gefunden, dann wird für bereits in die Seite eingebundene Systemnachrichten bei diesem Kind die style="display:none" entfernt. Damit wird das Kind sichtbar.
  • Gleichzeitig wird ähnlich wie bisher dem Kind ein <button> hinzugefügt.
• Wird auf „Verbergen“ geklickt, dann wird dem Array eine ID hinzugefügt, oder dies erstmalig gebildet.
  • Die 5^(config) letzten Elemente des Arrays werden durch Separatoren mit .join() aneinandergefügt.
  • Dann ist, sofern noch nicht vorhanden, ein Token abzuholen. Mit diesem ist dann die Einstellung zu speichern.
  • Beim nächsten Abruf einer Wiki-Seite ist die Benutzereinstellung mit der Gelesen-Info ziemlich sofort automatisch vorhanden.
• Das „Verbergen“ hat natürlich auch erstmal zur Folge, dass dieses Kind unsichtbar wird.

Umsetzung

preferencesGadgetOptions und fliegelfagel kennen sich bereits mit der Materie aus.

Wer anfängt, konkret und wirksam zu programmieren, lässt bitte eine Nachricht hier.

Der Aufwand ist überschaubar und machbar (alle Schnipsel sind vorhanden; müssten nur zusammenkopiert werden), wenn vorher Einigkeit über die Konzeption besteht.

• Ein Implementierungsvorschlag.

Vorangegangene Diskussionen

• Wikipedia:Fragen zur Wikipedia/Archiv/2013/Woche 46 #Beobachtungslisten-Nachrichten wieder ausblenden
• Wikipedia:Verbesserungsvorschläge #Umgekehrte Beobachtenliste für notifications – Archiv: /Archiv/2013/November

Aktuelle Diskussion

Bitte diesmal auf der Diskussionsseite.