Benutzer Diskussion:Dirk123456/Baustellenbaustelle 001/Baustelle-D/Baustelle-D.9

Hier steht eine Kopie des Antwortbeitrags unter Wikipedia_Diskussion:

• oldid=201420686#Prototyp_3:_Leichteres_Arbeiten_mit_Vorlagen_im_Visual_Editor

Die Beitrags-Kopie steht zwischen zwei horizontalen Linien (Wikitext: vier Minus-Zeichen). Der Wikitext entspricht dem Original, ausgenommen der Signatur, die durch vier Tilden (~) erzeugt wurde. Der letzte Entwurf für den Antwortbeitrag entstammt dieser Benutzer_Diskussion (Vorversion oldid=201420040 - 29. Juni 2020). Zur "Vorderseite": https://de.wikipedia.org/wiki/Benutzer:Dirk123456/Baustellenbaustelle_001/Baustelle-D/Baustelle-D.9

---

Feedback: Hallo

und vielen Dank an das Team Technische Wünsche für die Ausarbeitung mit Vorschlägen zur besseren Nutzbarkeit des VE!

Ich (Dirk123456/Disk) glaube, dass die Zusammenarbeit vom VisualEditor (WP:VE, H:VE) und Vorlagen schon ganz gut klappt, nämlich in den Fällen, wo die Programmierung einer Vorlage (H:VP), die Dokumentation (H:Vorlagendokumentation) und die TemplateData („Vorlage-Daten“, H:TemplateData) – z. B. die Verwendung von sogenannten Datentypen (Hilfe:TemplateData/Anwendung) – gut aufeinander abgestimmt sind.

Auch in den Fällen, wo zwar weder TemplateData noch eine separate Dokumentationsseite vorhanden sind, aber ein Klick auf die Vorlage-Seite reicht, um sich einen Überblick zu verschaffen – z. B. weil nur wenige Parameter zum Einsatz kommen – ist die Anwendung des VE passabel.

Ich vermute, dass in vielen Fällen die Weiterentwicklung des VE für sich genommen wenig hilft, da die Software wohl auf diese Abgestimmtheit der oben genannten Ressourcen angewiesen ist. Im Folgenden gehe ich auf die einzelnen Punkte zum Prototyp 3 ein. Darunter folgt Zusammenfassendes und Allgemeines.

Die Pfeile nach links (←) verweisen zum jeweiligen Abschnitt auf der Projektseite („Vorderseite“).

•  ←  Zu Prototyp 3 (Leichteres Arbeiten mit Vorlagen im Visual Editor) — Es wurden vier Abbildungen zum Prototyp 3 mit insgesamt neun Punkten bereit gestellt.
  1. Prototyp Benutzeroberfläche - Leichteres Arbeiten mit Vorlagen im Visual Editor

     Punkte 1 bis 6 im Bild, Prototypen 3.1 bis 3.6 als Abschnitte auf der Projektseite

  2. Prototyp 3.7 - Automatische Vervollständigung verbessern

     Punkte 7a und 7b im Bild, Prototypen 3.7a und 3.7b als Abschnitte auf der Projektseite

  3. Prototyp 3.8a - Knöpfe zur Verwendung des vorhandenen Medien-Selektor im Visual Editor hinzufügen

     Punkt 8a im Bild, Prototyp 3.8a als Abschnitt auf der Projektseite

  4. Prototyp 3.8b - Bildvorschau

     Punkt 8b im Bild, Prototyp 3.8b als Abschnitt auf der Projektseite

•  ←  Zu Prototyp 3.1 (Besserer Hilfetext) — Es werden hier zwei Aspekte beleuchtet: Doppelter Titel und Doku-Link.

  Doppelter Titel: Dass einige Informationen doppelt angezeigt werden, mag im Einzelfall überflüssig anmuten, ich selbst finde es aber nicht schlimm. Ich fände es schlimmer, wenn irgendwo Info fehlt. Deshalb sollte man diese Redundanz nur verringern, falls sich beide Zeilen aus ein und derselben Ressource speisen.

  Doku-Link: Die Aussage: „Es wird dazu ermuntert die Dokumentation auf der Vorlagenseite zu Hilfe zu ziehen“, wird durch ein fiktives Beispiel – eine „Vorlage:Infobox Person“ gibt es gegenwärtig nicht – unterfüttert:

  • „lnfobox für einen Artikel über eine Person. Zusätzliche Hilfe beim Ausfüllen der Vorlage erhalten Sie auf der Dokumentationsseite.“ („Dokumentationsseite“ ist blau, als Link gedacht).

  Ein solcher Text würde den gegenwärtigen, z. B. für die Infobox Protein, ersetzen:

  • „Infobox für einen Artikel über ein Protein“ (Kurzbeschreibung der konkreten Vorlage) und
  • „Es könnten einige zusätzliche Informationen über die Vorlage „Infobox Protein“ auf ihrer Seite vorhanden sein“ (allgemeine Angaben und konkreter Link).

  Die Verknüpfung vom Text „ihrer Seite“ entspricht in diesem Beispiel Vorlage:Infobox Protein.

  Die eigentliche Dokumentationsseite (Vorlage:Infobox Protein/Doku) wird aus gutem Grund nicht angesprochen;

  1. zum einen ist es nicht nötig, da die Vorlage-Seite des Beispiels (Vorlage:Infobox Protein) die Doku-Unterseite einbettet (Vorlage:Infobox Protein/Doku) und
  2. zum anderen hat nicht jede Vorlage eine Doku-Unterseite.

  Im zweiten Fall steht die Dokumentation zusammen mit dem Vorlage-Programm-Code auf derselben Seite, so dass in der Normal-Ansicht nur die Dokumentation zu sehen ist, was im Quell-Code (Editier-Ansicht) vor allem durch die Anwendung von include-, onlyinclude- und includeonly-Tags gewährleistet wird (soweit ich das überschaue).

  Die Formulierung: "... „Infobox Protein“ auf ihrer Seite ..." ist vielleicht nicht die günstigste, weil man erst mal denken könnte, dass man plötzlich bei moderner Anwendung der Groß- und Kleinschreibung gesietzt wird; man kann aber auf "ihrer Seite" klicken und erkennt, dass das wohl die Seite von „Infobox Protein“ sein wird, nämlich Vorlage:Infobox Protein.

  (-; Ich dachte nach dem ersten Mal Lesen eines solchen Textes tatsächlich, mein Benutzer-Namensraum hätte irgendeine Spezial-Seite ;-)

  Im Englischen habe ich dafür diesen Text gefunden:

  • “The "Template:Literature" template doesn't yet have a description, but there might be some information on the template's page.” (Google-Übersetzung: „Die Vorlage "Vorlage: Literatur" enthält noch keine Beschreibung, möglicherweise befinden sich jedoch einige Informationen auf der Seite der Vorlage.“)

  Der Link für "template's page" ist in diesem Fall Template:Literature, das Pendant zu Vorlage:Literatur.

  Ich bin dafür, dass der sichtbare Text der Verknüpfung und das Ziel der Verknüpfung identisch sind;

  • etwa so: „Zur Anwendung der Vorlage auf der Seite "Vorlage:Literatur"“
  • oder so: Es können zusätzliche Informationen auf dieser Seite vorhanden sein: Vorlage:Literatur.

  Das Wort „Dokumentationsseite“ halte ich für nicht so günstig, gerade wenn dazu „ermutigt“ wird, diese Seite zu „ziehen“. Das kann zu Frust führen, da – wie oben beschrieben – nicht jede Vorlage eine eigene Dokumentationsseite hat.

  Denkbar wäre auch ein Extra-Dialog, ähnlich diesem:

  • Menüpunkt: Hilfe zur Anwendung der Vorlage →
  • Dialog-Fenster mit dem Titel: Hilfe zur Anwendung der Vorlage "FN"

    Hinweis: Nicht alle Vorlagen sind nach den gleichen Prinzipien gestaltet. Daher kann der VisualEditor manchmal nicht alle Informationen zu jeder Vorlage in gleicher Weise darstellen. Möglicherweise findest du einige zusätzliche Angaben auf der jeweiligen Seite der Vorlage.

    Seite der Vorlage: Vorlage:FN

    Seite der Dokumentation: nicht gefunden

    ...

  Da könnten alle möglichen Hinweise über Vorlagen im Allgemeinen und über die konkrete, jeweils bearbeitete Vorlage rein. Aber vielleicht schösse man so mit Kanonen auf Spatzen.

  Fakt ist, dass es sehr viele Varianten gibt, wobei ich nicht behaupte, das in Gänze zu durchschauen: klassische Vorlagen-Programmierung (H:VP) ohne sichtbare Kommentare, VP mit der Dokumentation auf derselben Seite, VP mit der Dokumentation auf einer Unterseite; es ist theoretisch wohl auch möglich, dass ein bisschen Doku auf der Vorlage-Seite und ein bisschen auf einer Unterseite stattfindet. Dann gibt es noch die Vorlage-Seiten, die mit "invoke" ein durch Lua erzeugtes Programm einbinden (z. B. in Vorlage:Literatur). Man findet auch Misch-Formen, z. B. wenn der letztlich wirksame Programm-Code auf der „klassischen Vorlagen-Programmierungs-Sprache“ (H:VP) beruht, aber Lua einen Beitrag leistet (z. B. in Vorlage:Infobox Protein so angegeben).

  Nur Eins ist sicher: wenn, irgendwelche Informationen vorhanden sind, ob nun einige, zusätzliche oder die gleichen, wie die, die man auch im VisualEditor sieht, dann sollte man sie auf der Seite der Vorlage finden.

  Zusammenfassung für 3.1 – Doku-Link: Ich denke, man sollte weder ermutigen noch verunsichern, sondern einfach auf die Seite der Vorlage mit dem qualifizierten Namen verweisen. Der Verknüpfungstext und das Link-Ziel sollten identisch sein (allgemeine Form: Vorlage:Name der Vorlage).

  Die trennende Linie zwischen der Kurzbeschreibung und dem Hinweis mit Link sollte erhalten bleiben.

•  ←  Zu Prototyp 3.2 (Erforderliche Parameter) — „Tests haben gezeigt, dass Sternchen für Benutzer nicht allgemein "erforderlich" bedeuten.“

  Es gibt kaum einzelne Zeichen, die für sich genommen eindeutig sind. Nun ist das Sternchen (*) besonders beliebig, weil es häufig für „beliebig“ steht (z. B. als Joker-Zeichen). Woanders kann es auch ein Multiplikations-Zeichen oder ein Fußnoten-Zeichen sein. Letzteres erklärt wohl auch seine Herkunft. In den Dokumentations-Angaben stand/ steht häufig so etwas, wie: „Mit * bezeichnete Felder müssen angegeben werden“. Solche Hinweise finden sich zwar meist oberhalb eine Parameter-Tabelle, haben aber letztlich eine ähnliche Funktion, wie Tabellen-Fußnoten.

  Der Text „(Erforderlich)“ nimmt mehr Platz ein, als das Symbol * und es gibt ein Tooltip mit dem Text „Erforderliches Feld“. Der Stern fällt mehr auf als Text, steht unmittelbar neben dem Namen und zeigt mit dem Tooltip „Erforderliches Feld“ an, was erforderlich ist.

  Ich halte es für gut so, wie es ist. Wenn jedoch künftig ein Text angewendet wird, sollte das Tooltip erhalten bleiben.

•  ←  Zu Prototyp 3.3 ([[ ]] Knopf entfernen) — Wenn der „doppelte, kantige Klammer-Knopf“ zwischen Normalansicht und Wikitext umschalten könnte, dann hätte er durchaus Berechtigung.

  Das könnte etwa so aussehen:

  1. Normalansicht: ⟨ DNA-Methylierung, Übertragung einer Methylgruppe auf den Pyrimidin-Ring des Cytosins in Position 5 durch eine "DNA (cytosine-5-)-methyltransferase" (EC 2.1.1.37). ⟩ und
  2. Wikitext: ⟨ [[DNA-Methylierung]], Übertragung einer Methylgruppe auf den [[Pyrimidin]]-Ring des [[Cytosin|Cytosins]] in Position 5 durch eine "DNA (cytosine-5-)-methyltransferase" (EC 2.1.1.37). ⟩,

  (Das Beispiel entstammt einer Einbindung der Vorlage:Infobox Protein, Parameter "Reaktionsart", im Artikel DNA-Methyltransferasen, oldid=200099735.)

  Ich denke, so war das auch mal gedacht; zumindest deutet das zugehörige Tooltip („Zurück zu einfachem Wikitext“) das an.

  Gegenwärtig gibt es in den Parameter-Feldern des VE nur Wikitext. Man würde für das Editieren der Parameter-Werte im WYSIWYG-Stil ein Basis-Menü benötigen, ähnlich wie das beim Belegen der Fall ist:

  • ⟨ Belegen ⟩→ ⟨ Einen Beleg einfügen ⟩ →⟨ Basisform ⟩→ ⟨ Einzelnachweis ⟩→ dort Basismenü:
  • Rückgängig machen / Wiederholen / Text gestalten / Einfügen / Sonderzeichen.

  Das würde erst einmal nur mit dem sogenannten Datentyp "content" bzw. "Inhalt" klappen, vorausgesetzt, der in das Feld eingegebene Wikitext wird ohne Extras verwendet (Datentyp Inhalt: H:TemplateData/Anwendung#wikitext).

•  ←  Zu Prototyp 3.4 (Beschreibungen sichtbarer machen) — „Gegenwärtig sind die Beschreibungen ausgeblendet und werden nur angezeigt, wenn das Info "i"-Symbol angeklickt wird.“

  Das reicht doch aus, oder? Gerade wenn Folgendes zutrifft:

  • „Häufig enthalten die Beschreibungen wichtige Informationen, die dabei helfen, Parameter korrekt auszufüllen und zu formatieren.“

  könnte die eine oder andere Liste ziemlich lang werden. Es sollte ja eigentlich immer so sein, dass die Beschreibungen alle Informationen enthalten, die dabei helfen, die Parameter anzuwenden; denn Infos, die bei irgendwas helfen, sind automatisch wichtig und Beschreibungen ohne alle wichtigen Infos wären unvollständig.

  Gegenwärtig hat jedes Feld zwei Zeilen, eine Zeile mit dem Namen des Feldes und Schaltknöpfen, unter anderem mit dem (i)-Symbol, und die andere Zeile mit dem Eingabe-Feld. Das (i)-Symbol wird vom Tooltip „Beschreibung des Feldes“ begleitet und bietet mit Mausklick eben diese Beschreibung eines einzelnen Feldes.

  Wenn man diese (i)-Symbole sozusagen „ausklappt“, hätte das zwar den Vorteil, dass man nicht auf jede Beschreibung einzeln klicken müsste, man würde aber die Eingabe-Felder zwischen den Beschreibungen schlechter finden. Ich fände das unpraktisch, da ich ja irgendwann weiß, welche Felder ich editieren möchte und das sind meist wenige. Für alle Beschreibungen könnte man ja noch den Doku-Link nehmen, also die Verknüpfung zur Seite der Vorlage (siehe Prototyp 3.1).

• Zu den Prototypen 3.5 bis 3.8b — Vorgeschlagene Neuerungen

  Die vorgeschlagenen Neuerungen:

  •  ←  Prototyp 3.5 (Einführung gruppierter Parameter),
  •  ←  Prototyp 3.6 (Dropdown-Menü),
  •  ←  Prototyp 3.7 (Automatische Vervollständigung verbessern),
  •  ←  Prototyp 3.8a (Knöpfe zur ... hinzufügen) und
  •  ←  Prototyp 3.8b (Bildvorschau)

  basieren alle auf einer soliden Anwendung der TemplateData (H:TemplateData). Die Vorschläge schauen sich sehr gut an. Allerdings macht der VE das alles wohl nicht allein, sondern benötigt Ressourcen, die – so wie ich es verstanden habe – noch komplexer werden sollen. Es ist schon jetzt so, dass das Schreiben der Dokumentation durch Einbeziehung der TemplateData nicht besonders einfach ist, unter anderem deshalb, weil dazu eine weitere „Codierungsform“ notwendig ist (H:TemplateData/JSON).

  Hinzu kommt, dass die durch TemplateData unterstützten Datentypen – falls ich das richtig sehe – eher Empfehlungen sind als strikte Festlegungen.

  So erzeugt beispielsweise die Vorlagenprogrammierung (H:VP) von "Infobox Protein" beim Parameter "Kategorie" automatisch doppelte, eckige Klammern, die man nicht mit eingeben muss (und auch nicht eingeben darf), so dass aus dem eingegebenen Wikitext immer ein Link wird. Beim Parameter "Reaktionstyp" derselben Vorlage ist das nicht der Fall. Für beide Parameter ("Kategorie" und "Reaktionsart") wird in der Doku derselbe Datentyp "Inhalt" angegeben (gegenwärtige Versionen, Vorlage-Seite: oldid=201276907 und Doku: oldid=200160972).

  Der Vorschlag unter Prototyp 3.7:

  • „Darüber hinaus würde die Zielseite, nachdem sie ausgewählt wurde, automatisch so formatiert werden, dass sie als Wiki-Link erscheint (siehe 7b).“,

  hätte hier keinen positiven Effekt, da der Link in einem Fall bereits durch den zu Grunde liegenden Programmcode gesetzt wird (für Parameter "Kategorie") und im anderen Fall nicht immer gebraucht wird (bei Parameter "Reaktionsart"). Selbst wenn es den Datentyp "Wikipedia-Link" gäbe, wäre vermutlich eher der Programmablauf der Vorlage dafür zuständig, als der VE.

• Zusammenfassendes und Allgemeines

  Bei einzelnen Punkten kann man vermutlich anfangen, den VE äußerlich zu verbessern; das betrifft zum Beispiel die Titel-Redundanz (Prototyp 3.1). Bei anderen Sachen wird es vielleicht schwieriger. Meine Erfahrung sagt mir, dass Veränderungen auch gern mal „Verschlimmbesserungen“ sein können. Das geht an keine konkrete Adresse, sondern ist eine allgemeine Erfahrung.

  (-; Sobald ich bei irgendeinem Thema versuche, einen zweiten Blick auf die hintergründigen Details zu werfen, nimmt sich meine Begeisterung des öfteren vornehm zurück ;-)

  Ich denke, dass bis auf Weiteres nicht jede Vorlage gleich gut mit dem VE zurecht kommen wird oder anders herum. Das hat verschiedene Gründe, unter anderem den, dass der Zweck der Vorlage einen anderen Fokus hat oder hatte, als von einer graphischen Benutzeroberfläche (GUI) eingebunden zu werden. Die Vorlage:Klade wurde z. B. dazu entwickelt, um Stammbäume zu „konstruieren“. Einige Vorlagen wirken nur im Zusammenhang (z. B. die Fußnoten-Vorlagen FN, FNZ und FNBox) und können die Abstimmung zueinander nicht selbst kontrollieren.

  In beiden Fällen – Stammbaum und Fußnoten – gibt es Alternativen. Den Stammbaum könnte ich mir z. B. mit der Vorlage:Klade auf einer Baustelle „zurecht basteln“ (Vorlage:Baustelle), davon einen Screenshot machen, diesen als PNG-Bild speichern, auf Wikimedia Commons hochladen und dann als Abbildung in einem Wikipedia-Artikel einbinden. Statt der Fußnoten-Vorlagen kann ich zumeist die Belegen-Funktion des VE nutzen.

  Viele Vorlagen sind nützlich und auf Grund ihrer Einfachheit nicht geeignet, um da herum viel Aufwand zu betreiben (Anlegen einer Doku-Unterseite mit Einbeziehung der Template-Data usw.).

  Der arme VE, der sozusagen „auch nur das essen kann, was auf den Tisch kommt,“ sollte das Recht haben, zu erwähnen, dass es mit der jeweiligen Vorlage „Verdauungsprobleme“ geben könnte. Bisher gibt es zur Abgestimmtheit zwischen VE und Vorlage einen einzelnen Satz (Es könnten einige zusätzliche Informationen über die Vorlage „<jeweiliger Name>“ auf ihrer Seite vorhanden sein), der so wirkt, als wolle der VE sich für irgendetwas entschuldigen, ohne genau angegeben zu wollen, wofür.

  Ich fände es gut, wenn der VE eine Vorlage und ihre Ressourcen prüfen könnte, um formale Anforderungen an die Kompatibilität zwischen sich und der Vorlage zu erfassen.

  1. Wenn keine besonders große Kompatibilität vorliegt, dann könnte der VE – wie bisher – die Werte für die Felder bzw. Parameter entgegen nehmen und daraus einfach die entsprechende Vorlage-Einbindung erzeugen. Das wäre dann sozusagen der „robuste Modus“.
  2. Wenn formal eine große Kompatibilität erreicht wird, dann könnte der VE – das ist bloß ein Gedanke – erweiterte Funktionen anbieten. Das wäre dann sozusagen der „smarte Modus“.

  Ich habe diese beiden Vorgehensweisen des VE bei der Vorlage-Bearbeitung hier mal den „robusten“ und den „smarten Modus“ genannt – das ist nur, um Arbeitsbegriffe zu haben. Auf alle Fälle sollten die bisherigen Grundfunktionen nicht verloren gehen:

  1. Anklicken der Seite der jeweiligen Vorlage und
  2. Ausfüllen der Parameter mit den erwarteten Werten als Text.

  Es wäre fatal, wenn man nur deshalb zum Quelltext-Editor (WP:wikEd) wechseln würde, weil eine Seite nicht in jedem Fall erreichbar ist oder ein automatisch erzeugter Link an der falschen Stelle stört. Ich denke, man sollte gegebenenfalls vom „smarten Modus“ in den „robusten Modus“ zurück schalten können.

  Ich weiß nicht, wie die formalen Anforderungen an hohe Kompatibilität zwischen VE und Vorlage im Detail aussehen müssten. Auf der Seite WP:... Häufigst genannte Probleme hatte das Team Technische Wünsche schon einiges zusammen getragen, was die Arbeit mit Vorlagen insgesamt erschwert. Darunter ist vermutlich auch einiges, das definieren könnte, was einer solchen Kompatibilität im Wege steht.

  Ich glaube, dass es halbwegs objektiv sein kann, wenn Software die Kompatibilität von Software-Komponenten prüft, wenngleich mir klar ist, dass es Diskussionen darum geben könnte, was der VE und was die Vorlage können muss.

  Der bessere Komfort beim Ausfüllen von Vorlage-Einbindungen für Artikel-Schreibende darf auch nicht zu sehr zu Lasten des Komforts für die Programmierenden und Dokumentierenden gehen.

  Als man die Dokumentation noch einfach als Wikitext unter den Vorlage-Code schrieb, hatte dass ja auch Vorteile; beides – die Programmierung und die Dokumentation für die Anwendenden – wurden meist synchron erledigt. Jetzt gibt es die Dokumentations-Unterseiten mit JSON für die TemplateData und Wikitext für weitere Informationen. Selbst bei der einen oder anderen Infobox, die eine Vorlage-Dokumentations-Unterseite mit JSON-Code für die TemplateData besitzt, sind dort die Paramerter-Beschreibungen freigelassen worden (etwa in der Form: ... "params": { ... "description": "", ...), um sie in einer „normalen“ Wikitext-Tabelle abzulegen

  Je komplexer das gesamte System wird, desto mehr besteht die Gefahr, dass die unterschiedlichen Gruppen von Beitragenden und Leidtragenden aneinander vorbei reden oder – um noch eine Spezialität aus „Wiki-World“ zu nennen – mithilfe unendlicher Diskussionswürste aneinander vorbei schreiben.

Bildliche Darstellungen sind bei der Kommunikation in „Wiki-World“ selten, weil sie eben auch eher umständlich zu erzeugen sind. Sie helfen aber; gerade, wenn es um eine Idee geht, die noch vorgestellt werden muss. Ich freue mich über das Engagement des Teams Technische Wünsche. Lasst Euch bitte nicht entmutigen!

MfG --Dirk123456 (Diskussion) 19:50, 29. Jun. 2020 (CEST)

---