PokéWiki:Allgemeine Diskussionsseite

Aus PokéWiki
Version vom 15. Juli 2020, 12:45 Uhr von DeXter (Diskussion | Beiträge) (→‎Abstimmung: Enthaltung bei O, da ich mich nicht spoilern will (hab jetzt ja die Bände :smirk:) Viell. trag ich da meine Stimme noch im Nachhinein ein)
Zur Navigation springen Zur Suche springen

Vorlage:TOC right

Gestaltung der Stellenanzeigen/Ausschreibungen

vorrausgegangene Abstimmung

Hallo!
Vor Kurzem ergab die Abstimmung über die Einführung von Stellenanzeigen bzw. Ausschreibungen auf unserer Hauptseite, dass tatsächlich ein Bedarf für solche da zu sein scheint. Deshalb soll es in dieser Diskussionsrunde darum gehen, wie eine solche Box denn ganz konkret gestaltet und ausgeführt werden soll.
Die zu klärenden Fragen sind:

  1. Wie sieht das Layout der Box aus?
  2. Welche Hauptseiten-Position hat die Box?
  3. Wer darf die Vorlage, die zur Box gehört, bearbeiten?
  4. Was darf/muss alles in die Box?

Als Diskussionsbasis möchte ich hier nochmals meine beiden Beispiele einer möglichen Gestaltung anführen: Link zu den Beispielen
Die Antworten meiner Beispiele auf die oberen Fragen sind:

  1. Entwurf 1: Vertikal schmal; horizontal die Seitenbreite ausnutzend // Randfärbung hellrot, im Überschriftenteil mit Gradient // Überschrift: "Gesucht!" am linken Rand; am rechten Rand Links zu Missionsbrett und globaler To-do-Liste // Im Textfeld kursive, gereihte Kurzausschreibungen mit Projektlinks; ganz rechts Großlinse (als visuell-ansprechendes Element)
    Entwurf 2: Vertikal höher; horizontal einer gegenüberliegenden Box angepasst // Randfärbung blau, im Überschriftenteil mit Gradient // Überschrift "Ausschreibungen:" // Im Textfeld rote Überschrift "Gesucht!"; aufgelistete Kurzausschreibungen mit Projektlinks; unten abgesetzt Links zu Missionsbrett und globaler To-do-Liste; rechts ORAS-Ruinenmaniac-Artwork (als visuell-ansprechendes Element)
  2. Entwurf 1: unter "Willkommen im PokéWiki!" oder über "Aktuelles"
    Entwurf 2:Kein Plan drop.gif
  3. Die Vorlage soll ab dem VB-Rang bearbeitbar sein.
  4. Kurzbeschreibungen in Stichpunktform von gesuchten Positionen oder Funktionen. Es soll auch Mitgliederengpässen oder offene Aufgaben in den jew. Projekten aufmerksam gemacht werden, die von Neumitgliedern relativ leicht ausgefüllt/erfüllt werden können.


Nicht nur schriftliche Vorschläge und Einwände, sondern vor allem auch bildlich anschaubare Entwürfe (Testseiten-/Screenshot-Links) sind sehr erwünscht!
-MfG, Kenaz-Hagalaz Disku 18:10, 26. Mär. 2019 (CET)

Ich habe Entwurf 1 von Kenaz ein wenig abgewandelt und hier mal in einer "Testumgebung" dargestellt. Da ich noch unschlüssig bei der Farbe des unteren Teils und dem Standort bin, habe ich ein paar toggler eingebaut, dann könnt ihr, wenn ihr wollt euch das anschauen und beurteilen^^. Meine Antworten auf die Fragen:
  1. Wie Kenaz' erster Entwurf. Meine Änderungen: der untere Teil ist eine Tabelle um bessere Trenner zu ermöglichen und die Großlinse ist im oberen Teil.
  2. Wie bei Kenaz. Die Stellenanzeigen sollten meiner Meinung nach gut sichtbar sein und neben der dominanten Farbe, halte ich es für wichtig, dass man, am PC die Anzeigen ohne runter zu scrollen sehen kann.
  3. Erneut wie Kenaz^^. Auf der Hauptseite und auffällig --> mindestens ab VB.
  4. Wie Kenaz. Zusätzlich bin ich zur Zeit am überlegen wie man so etwas wie {{Tt}} auch "Smartphone-Nutzer-freundlich" umsetzen kann, um bei Bedarf zu den einzelnen Stichpunkten eine Erklärung abgeben zu können, da die angebenen Punkte sich hauptsächlich (klärt mich auf sollte ich die Haupt-Zielgruppe falsch verstanden haben) an neue Nutzer (und an zukünftige Nutzer) richten und einen relativ einfachen Schwierigkeitsgrad haben sollen. Außerdem könnte man damit ermöglichen auch mal ein bisschen anspruchsvollere Aufgaben mit ausreichender Erklärung zu stellen. --DeXter 21:54, 27. Mär. 2019 (CET)
  1. Mir gefällt da jetzt spontan die generelle Richtung von Entwurf 2 besser; finde allerdings dass da zu viel Farbe hervorsticht, hätte mir da einen wesentlich kleineren Rahmen, wenn überhaupt, vorgestellt (das ihr hier schon viel zu früh Farbe in die Diskussion werft, sei mal dahingestellt - so wird sich jetzt nämlich die Hälfte gegen dieses Orange und nicht gegen das Design aussprechen). Oh und um himmels willen, kein tt auf der Hauptseite - ist schon schlimm genug das wir das noch in Artikeln nutzen. Zeitgemäss ist das einfach nicht mehr.
  2. Spontaner Vorschlag - und müsste definitiv noch von Killuu und Isso genehmigt werden: über das schon gewusst und dafür das Zeichenlimit von AdW/PdW erhöhen, damit da kein Leerraum entsteht. Haben wir Kapazität dafür aus dem XdW-Bereich? Ich meine mich nämlich erinnern können das früher sich immer darüber beklagt wurde dass die Zeichenlimite da zu kurz sei.
  3. Es is sinnlos es PLs zu verbieten und SB und alles drunter traue ich dieses Recht nicht zu - ist immerhin die Hauptseite. Folglich Entweder VB+ oder PL+ - was genau hängt vor allem von der Umsetzung von Punkt 4 ab.
  4. ..doppelt sich entweder mit der To Do oder mit dem Missionsbrett, so wie die Diskussion läuft eher mit der To Do. Da deren Darstellung allerdings meine Idee war, sie nicht so wirklich funktioniert hat und ich nicht weiss, wie man sie verbessert, halte ich mich hier glaub besser raus. --Datei:Sugimori 672.pngMecanno-manMäh 18:35, 29. Apr. 2019 (CEST)
Zu dem Thema kann ich eigentlich nicht viel sagen, da ich erstens kein Fan dieser "Stellenausschreibungen" bin (soll jetzt keine weitere Debatte anstoßen, ich akzeptiere die Entscheidung) und zweitens ein furchtbares Gefühl für Design habe. Nur eine Bitte meinerseits: benutzt wenn möglich keine zu grellen roten und ins rote gehende Farben. Das beißt sich furchtbar mit dem Blau, das wir hier hauptsächlich verwenden. Fällt zwar sofort auf, lenkt aber auch vom Rest ab und ist zumindest für mich fast schon unangenehm anzusehen :x -- Datei:Pokémonsprite 359 Pinball2.png Korvel1 Diskussion 10:10, 4. Mai 2019 (CEST)
Ich habe das Design meiner Vorschläge ein wenig geändert (auch etwas mehr nach dem Stil der anderen Boxen auf der Hauptseite). Hoffe, dass das Aussehen euch eher zusagt^^. --DeXter 18:54, 4. Mai 2019 (CEST)
Ich finde Entwurf zwei eigentlich schicker. So schmale Boxen gefallen mir meistens nicht so. Zu Mecs Einwurf: Ja, wir haben teilweise XdWs die gerne eine höhere Zeichenzahl hätten, manchmal krebst man da aber auch am unteren Ende rum. Wenn man aber die XdW-Box vielleicht etwas quetscht, wird sie auch länger? Wobei man dann schauen müsste, ob das noch schön proportioniert ausschaut. Lg --Und dann im Mondschein... Killuu 22:23, 5. Mai 2019 (CET)
Danke für eure Rückmeldungen!
Ja, die tt-Vorlage sollte in dieser Box wirklich komplett vermieden werden. Allein schon, weil sie auf Mobilgerät-Browsern oft nicht richtig dargestellt wird, was dann meist die Zerstörung des Layouts zur Folge hat. Eventuelle weitere Nachteile der tt-Vorlage unterstützen diesen Punkt nur noch.
Ich denke auch, dass man die Farben der Box nicht zu grell gestalten sollte. Ich finde den Vorschlag, von der Signalfarbe Rot abzusehen, sehr interessant und bin zu dem Schluss gekommen, dass ein blauer oder grüner Farbton, wohl am besten passen würde. Z. B. die gleiche Farbe, wie die, der übrigen Boxen nur ggf. etwas dunkler oder eben ein Greenchu-Grün.
Als XdW-Autor habe ich auch immer wieder mit der Zeichenbegrenzung zu kämpfen. Als jemand, der gerne ein weites Spektrum an Formulierungsmöglichkeiten haben möchte, würde ich eine Aufstockung des Zeichenlimits begrüßen. Ich sehe aber auch, dass viele mit dem Mindestzeichensatz ringen. Das Problem der Proportionsästhetik entsteht durch eine allzu große Vergrößerung der XdW-Box leider auch. Ich hoffe, unsere Projektleiterin Isso kann uns ihre Einschätzung der Lage und der potenziellen Möglichkeiten geben.
Ich bin auch von der „Längsfassung“ (wie DeXters oder mein Entwurf 1) eher abgekommen, da ich ein Problem bei dieser sehe, wenn es zu viele oder zu wenige Gesuche geben sollte. Besser wäre es wohl, eine schmalere Box (wie mein Entwurf 2) zu haben, die sich nach Bedarf füllt oder erweitert. Ich würde sehr gerne auch eine solche Variante mal „in Aktion“ sehen. Da du dich, DeXter, für diese Sache sehr engagierst und deine Syntax-Fähigkeiten deutlich besser sind als meine, möchte ich dich bitten, mal deine Version dieser Variante zu erstellen. Bin gespannt, wie die wohl aussähe. :)
-MfG, Kenaz-Hagalaz Disku 16:32, 24. Jun. 2019 (CEST)
Kann ich gerne machen Kenaz^^. Sollte dann die nächsten Tage fertig werden, je nach dem wie schnell ich mit meinem Ergebnis zufrieden bin (nach Möglichkeit werd ich auch versuchen das irgendwie ins Haupseiten-Layout reinzubringen, bin da aber eher am zweifeln ob ich das in angemessener Zeit schaffe). Vorhin hatte ich mir auch noch eine Frage überlegt, die ich aber wieder vergessen habe drop.gif Sollte sie mir wieder einfallen, kommt nochmal was von mir. --DeXter 19:28, 24. Jun. 2019 (CEST)
Tada! Zwar nicht ganz fertig, aber das Einzige, was mich noch stört ist das "Gesucht!" und dafür hab ich bisher noch keine zufriedenstellende Lösung gefunden. Hoffentlich fällt euch was ein (muss auch nicht gleich in CSS sein; wenn nötig kann ich versuchen einen Vorschlag möglichst gut umzusetzen). Mit der restlichen Box bin ich sehr zufrieden (viell. könnte man auch noch den freien Platz unterm Bild entfernen, dafür müsste nur die Höhe des divs, in dem die Liste ist, geändert werden; dann wäre die Box auch kürzer). Ich hab mich am Design der restlichen Hauptseiten-Boxen orientiert und denke, dass das Bild auf jeden Fall ausreicht um auf die Box aufmerksam zu machen. --DeXter 18:58, 26. Jun. 2019 (CEST)
Passt anscheinend doch nicht. Das Entfernen der Scrollbar über scrollbar-width: none funktioniert in Firefox und dem Samsung Internet Browser für Handys (wie auch immer der genau heißt), aber nicht in Edge und dem Internet Explorer. Bei anderen Browsern weiß ich es nicht. Ich versuche in den nächsten Tagen das zu lösen. --DeXter 16:49, 27. Jun. 2019 (CEST)
@Kenaz (und alle, die hier mitwirken wollen^^), jetzt ist die Box (fast) fertig. Wie bereits gesagt stört mich noch das "Gesucht!"; ansonsten siehe meine vorletzte Nachricht. Hier nochmal der Link. Und noch etwas hintendran: Mec kritisierte grad auf Discord, dass man durch die unsichtbare Scrollbar nicht mehr sehen könne, dass die Liste hoch- und runtergescrollt werden kann und, dass somit der "08/15-Nutzer" nicht merken wird, dass die Liste diese Funktion hat. Meiner Meinung nach ist das kein Problem, da, auf meinem Handy und meinem PC, wenn die Liste lang genug ist, der unterste, sichtbare Listeneintrag (wenn die Box ganz hochgescrollt ist) vom Rand der Box angeschnitten wird und man sich somit erschließen kann, dass die Liste länger ist als das, was man sehen kann. Was sind eure Meinungen? --DeXter 19:08, 8. Jul. 2019 (CEST)
Durch das fehlen der Scrollbar interpretier zumindest ich das eher als n Designfehler als n Indikator zum Scrollen; irgend einen Indikator das man da Scrollen kann brauchts definitiv. --Datei:Sugimori 672.pngMecanno-manMäh 23:41, 8. Jul. 2019 (CEST)

Als erstes: Herzlichen Glückwunsch zum Geburtstag nachträglich liebe Diskussion emot-highfive.gif

Spaß beiseite, diese Diskussion benötigt nicht nur etwas, sondern ordentlich Schwung, damit hier in absehbarer Zeit mal Fortschritt zustande kommt (mein Ziel ist es die Stellenanzeigen bis zum ersten oder zweiten Teil des Erweiterungspasses fertig zu kriegen).

Als erstes möchte ich etwas zum Inhalt der Anzeigen sagen, das ist auch der Punkt neben dem Design, an dem das gesamte Konzept steht und fällt. Bisher waren u. a. Sachen wie „Aktive Mitglieder im Manga-Projekt gesucht“ geplant. Diese Stellenanzeigen halte ich für nicht zielführend. Meiner Meinung nach sollten in die Stellenanzeigen-Box zeitlich nicht allzu aufwendige und nicht allzu komplexe Aufgaben rein, die für Neulinge geeignet sind und auch u. a. speziell für diesen Zweck (den Zweck der Nutzer-Anwerbung) "aufgehoben" und/oder gestellt werden. Hin und wieder hieß es, dass die To-do-Liste und das Missionsbrett den Zweck der Anzeigen bereits erfüllen. Aber die To-do-Liste ist für Neulinge mMn ungeeignet wegen der schieren Masse an Aufgaben, deren Bearbeitung zusätzlich nicht (für Neulinge) genau genug erklärt wird. Das Missionsbrett eignet sich da schon eher. Allerdings sind beide Seiten meines Wissens nach nicht auf der Hauptseite verlinkt bzw. sonst wo leicht zu finden (abgesehen von der Sidebar, aber dort gehen die beiden Seiten mMn unter den vielen Links unter). Also wären nebenbei angemerkt die Links in der Stellenanzeigen-Box zur To-do-Liste und zum Missionsbrett auf jeden Fall vorteilhaft.

Dann der andere wichtige Punkt: Das Design. Wie viele andere Leute in dieser Diskussion, bin ich für eine Box designt wie diese hier. Wichtig ist dabei meiner Meinung nach, dass die Box im gleichen Design wie die anderen auf der Hauptseite ist (das habe ich damals beim Erstellen des Entwurfes auch versucht). Zum Design zähle ich ein weiteres heikles Thema dazu: Die Position der Stellenanzeigen-Box. Denn dafür muss an den anderen Elementen der Hauptseite rumgewerkelt werden und das wird vermutlich auch einer der schwierigsten Punkte sein. In der bisherigen Diskussion gab es Überlegungen die XdW-Box dafür zu verformen. Dazu muss ich mir aber noch Gedanken machen.

Um den verbleibenden Punkt von Kenaz' Einstiegsnachricht zu dieser Diskussion auch noch zu behandeln: Bearbeitungsrechte der Box für VB und höher.

Da diese Diskussion seit über einem halben Jahr still liegt, habe ich in diesem Diskussionsbeitrag nochmal alle wichtigen Punkte angesprochen um einen Überblick zu kriegen. Als Schlusssatz, in der Hoffnung die Motivation von dem ein oder anderen hier zu wecken: Der User-Mangel wird schlimmer und unser Team wird kleiner. Das wird sich nicht ändern, indem wir nichts tun. Der Kontakt mit Neulingen und Besuchern hat gezeigt, dass es oft daran scheitert, dass die Leute nicht wissen was sie machen sollen oder wie sie es machen sollen (um die To-do-Liste aufzugreifen) (teils herrscht auch einfach der Irrglaube das Wiki sei bereits vollständig bzw. es gäbe nichts zu tun). Meine Hoffnung ist es mit den Stellenanzeigen neue User zu gewinnen, sodass wir wieder mehr vielversprechende Neuzugänge kriegen. Beim Thema User-Mangel werden die Stellenanzeigen allein sicher nicht ausreichen, aber sie werden einen Teil dazu beitragen.--DeXter 00:42, 27. Mär. 2020 (CET)

Ich habe hier mal den Mittelteil der Hauptseite nachgebaut (Ober- und Unter-Teil sind einfach die Vorlagen) und die Stellenanzeigen-Box an einer möglichen Stelle eingebunden. Das bisher benutzte Bild habe ich entfernt, um Platz zu sparen. Meiner Meinung nach sollte man, wenn dann ein recht schmales oder kleines Bild benutzen, damit kein wertvoller Platz verbraucht wird. Den entstandenen habe ich gefüllt, indem ich die XdW-Box verlängert habe. Als erstes zu diesem Lösungsansatz: Eine Folge dieser Möglichkeit ist die Erhöhung der XdW-Längen (ich glaube auf ca. maximal 1850 Zeichen; keine Ahnung wie viel als Minimum) für manche wird das evtl. ein Vorteil sein, manch anderer (auch ich) wird es dadurch allerdings hin und wieder schwer(er) haben. Deshalb hatte ich die Idee je nach Bedarf ein zweites Bild einzubinden (dies würde aber keines Falls den zusätzlich nötigen Text ersetzen können, nur verringern). Isso, wie ist deine Einstellung als derzeitige XdW-Projektleiterin dazu, allgemein als Lösung an der XdW-Box rumzuschrauben? Ansonsten hatte ich noch den Einfall, dass der entstehende, freihe Platz durch eine weitere Box gefüllt werden könnte. Allerdings habe ich keine Ahnung was für eine das sein sollte (und dafür müsste höchst wahrscheinlich eine komplett neue, separate Diskussion gestartet werden). --DeXter 02:14, 1. Apr. 2020 (CEST)
Als Alternative könnte man sonst auch die Anzahl der Wds-Sätze reduzieren, sodass XdW-Artikel nicht künstlich durch ein weiteres Bild gestreckt werden müssten. Die Stellenanzeigen-Box könnte man zudem scrollbar machen, um dort auch etwas mehr als drei knappe Anzeigen unterzubekommen. ~ Taisuke Diskussion 09:18, 1. Apr. 2020 (CEST)
Mit Hilfe von Tais Idee hab ich eine zweite Version auf meiner Testseite erstellt. Dieses Mal ist die XdW-Box völlig unverändert. Dafür wurde der Wds-Teil verkürzt. Durch die Scrollbar kann man aber immer noch alle Wds-Sätze sehen (hierbei entsteht bloß das Problem, dass die "verdeckten" Sätze weitaus weniger Aufmerksamkeit kriegen würden). Eine Scrollbar habe ich ebenfalls bei der Stellenanzeigen-Box hinzugefügt und bin auch dafür, das wegen der ermöglichten Platzersparnis ins finale Design mitaufzunehmen (diese Möglichkeit hatte ich, glaube ich, bisher verdrängt, weil das vor vielen Monaten nicht mit dem Bild harmonieren konnte. Dadurch ist auch erst die Sache mit der ausgeblendeten Scrollbar entstanden). Da das hier noch nicht in der Diskussion steht, werfe ich eine Idee von Mec noch in den Raum, die er vor langer Zeit hatte: Die Stellenanzeigen, ähnlich wie die Wds-Sätze zufällig aus einem Text-Pool anzeigen. Aber wie gesagt, ich präferiere die Scrollbar-Lösung. --DeXter 13:13, 1. Apr. 2020 (CEST)
Ich finde, beide Versionen haben ihre Vor- und Nachteile. Die Verwendung von Scrollbars führt dazu, dass wir den Seite komprimiert halten können, ohne dabei auf Inhalt verzichten müssen oder diesen anderswo künstlich aufblähen müssen. Bei der News nutzen wir dies ja bereits und da können problemlos einige Einträge drin stehen, bevor das überfüllt wirkt, wobei die Seite dabei nicht unnötig in die Länge gezogen wird. Im Gegensatz zu dem Wds und den Stellenausschreibungen haben wir hier einen entscheidenden Faktor aber verfügbar: Aktualität. Bei den News stellt es kein Problem dar, wenn man ältere Sachen "schwerer" erreichbar macht, indem man etwa eine Scrollbar nutzt, da diese sowieso nicht so häufig gesucht werden. Bei den Stellenausschreibungen wird Aktualität aber eher eine geringere Rolle spielen, die meisten Sachen werden immer wichtig sein, wenn sie da drin stehen. Einige Einträge zu verstecken wird da also nur dazu führen, dass sie übersehen werden. Ähnliches gilt für die Wds, wenn diese teils versteckt sind, werden die weiter unten aufgeführten seltener gelesen und damit geht der "Spaßfaktor" daran verloren.
Der Verzicht auf Scrollbars auf der anderen Seite führt dazu, dass logischerweise andere Inhalte drum herum länger werden müssen, um den frei gewordenen Raum aufzufüllen. Das mag in diesem Beispiel gut geklappt haben, aber es wird einige Fälle geben, wo die XdW-Artikel das nicht leisten können. Ich bin mir also nicht sicher, ob das hier der zielführende Weg ist. Logischerweise wäre es auch möglich, ein anderes Design für die Box zu wählen, man könnte etwa eine breitere Box über die ganze Seitenbreite wählen, so ließen sich mehr Punkte unterbringen und man hätte das Platzproblem an dieser Stelle nicht. Das stellt uns aber natürlich vor ein anderes Problem: Wohin damit? Über oder unter den XdW/Wds/Zitat-Abschnitt? Da drüber würde dazu führen, dass die Seite möglicherweise aus dem Gleichgewicht gerät, da wir bereits drei Boxen darüber haben, eine weitere könnte das ganze visuell länger erscheinen lassen, als es tatsächlich ist und so beinahe abschreckend wirken. Verfrachten wir die Anzeigen hingegen unter diesen Abschnitt, werden ihn höchstens die paar Leute sehen, die ohnehin den XdW/WdS/Zitate-Abschnitt bis zum Ende lesen und dann feststellen, dass da noch was drunter ist, für die EP-Sachen werden die wenigsten ans Ende der HS scrollen. Mit anderen Worten: Man riskiert, dass niemand die Ausschreibungen sieht und das wäre so ziemlich das Gegenteil von dem, was wir erreichne wollten. Man könnte natürlich darüber nachdenken, die News nach da unten zu verschieben, aber ich kann mir gut vorstellen, dass die Leute diese gerne sehen und daher vermissen würden. Alternativ wäre es vielleicht auch möglich, eine der bereits bestehenden Boxen zu erweitern. Das könnte vielleicht etwas platzsparender sein und uns erlauben, die Ausschreibungen weit oben zu platzieren, ohne dass sie störend wirken. Aber da wird man vermutlich einfach testen müssen, was passt.
Abschließend noch kurz: Am Handy scheinen die Boxen nicht ganz zu passen, ich weiß aber ehrlich gesagt nicht, wie genau das zustande kommt, ich lass das einfach mal mit Bild da, vielleicht kannst du da ja noch mal drauf schauen, DeXter. -- RobbiRobb 19:19, 1. Apr. 2020 (CEST)
Ich finde das zweite Design deutlich angenehmer und vor allem praktikabler, bei meinen XdWs gibt es einfach keine Möglichkeit noch andere Bilder reinzubasteln. Ich würde jedoch versuchen auf die Scrollbars zu verzichten. Man könnte ja zum Beispiel auch weniger Wds-Sätze einbinden und auch in der Stellenanzeige die angezeigten Punkte durch Zufall einbinden lassen. Was mir jetzt noch als Idee kam, sorry, falls das schon irgendwo stand, wäre die News zu verschmälern und die Stellenanzeigen da noch neben zu packen. Vielleicht nicht in der gleichen Breite wie Wds- und Zitatekästchen, sonst sieht das so komisch aus. Aber diese Newsbox besteht eh aus unglaublich viel Whitespace. Oder das Stellenanzeigenkästchen dann links und die News rechts. Ich denke, wir sollten auf jeden Fall bis zum Chattreffen die Optionen optimieren bzw. da noch bequatschen und dann mal ganz dringend eine Abstimmung starten ;). Btw. ich finde den zugefügten Text in Beispiel 1 beim PdW echt awesome :D. Lg --Vorsicht, heiß! Killuu 19:36, 28. Apr. 2020 (CET)
Ich habe, nach Killus wunderbarer Idee, mal eine paar Varianten hier auf meiner Testseite hinzugefügt. Da gefällt mir Version 3 schon ganz gut (bei Version 2 sieht die Stellenanzeigen-Box mMn irgendwie an den Rand gequetscht aus). Ob mit Scrollbar, zufällig angezeigten Stellenanzeigen oder anderem Schnickschnack, kann man noch entscheiden. Das hat denke ich auf jeden Fall Potenzial. Jetzt möchte ich noch etwas zum anderen kritischen Thema sagen - den Stellenanzeigen selbst. Wie Robbi auf Discord im VC schon meinte, dürfen keine wichtigen Sachen warten, bloß, damit sie als Anzeigen genutzt werden können. Deswegen könnten sich da die allseits bekannten müsste-man-mal-machen-Aufgaben wunderbar eignen. Wäre dann natürlich wieder Thema, ob man da genügend anfänger-freundliche auftreiben kann. Außerdem dachte ich mir, dass manche Aufgaben angeworben werden können, während sie jemand bearbeitet (z. B. weil die Sache dringend erledigt werden muss). Dann wird die Sache bearbeitet und Neulinge können zusätzlich etwas dazu beitragen und, wenn der Punkt erledigt ist, kommt die Stellenanzeige wieder raus. Mal als Denkanstoß bis zum Chattreffen. --DeXter 22:11, 28. Apr. 2020 (CEST)
Unabhängig der Mühe die sich Dexter gemacht hat... ich finde die Idee mit "Halbierung" und alle 3 Versionen schrecklich. Und bin dagegen. Es gab da schon deutlich optisch bessere Versionen. Eine weitere Box daneben macht die Newsline ziemlich dick und unschön. Und der Whitespace kommt je nachdem was in der News steht. Persönlich halte ich dieses Thema für ziemlich aufgebauscht, ähnlich wie das Mentorenthema damals. Es worden schon viel zu oft User auf Baustellen hingewiesen. Wir haben Mühen in Mitmachen, To-Dos usw. gelegt. Im Endeffekt hat sich allerdings nichts als hilfreiches Mittel erwiesen. Die Leserschaft will die Informationen vorgesetzt bekommen. Allerdings wollen die wenigsten Verstehen das ein Wiki nur durch Mitarbeit weiter wächst. Und solange sich das nicht ändert (und ich sehe Stellenanzeigen als kein mögliches Mittel) werden solche Sachen nur Perlen vor die Säue sein. Daher denke ich auch nicht das sowas das ganze verbessern wird. Das überlasse ich aber jedem selbst. Allerdings sollte dieser Stellenanzeiger, wenn die Mehrheit ihn will, nicht das Gesamtbild verschlechtern sondern sich in dessen Integrieren oder verbessern. Ich glaub auch nicht das dieses Ding groß jemand auf Dauer füllen wird, außer den paar euphorischen am Anfang. Man sieht ja wie schwer es ist das News hinzugefügt werden.* Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 22:32, 28. Apr. 2020 (CEST)
Ich denke die Idee das neben die News zu packen passt. Man sollte dann einfach bei der News drauf achten, das da nicht all zu lang ist. Die die da in mehrere Zeilen gehen scheinen mir definitiv kürzbar - und die News soll ja auch dazu aufrufen in die Artikel zu kucken, folglich braucht die nicht all zu lang sein. Die Gefahr, das das ganze hier nix bringt, besteht natürlich - aber hast du denn eine bessere Idee, Ryu? Ich nämlich aktuell gerade nicht, und das Problem nur zu erkennen hilft niemandem. (Ausserdem hatten wir hier ja ne Abstimmung wo sich die Mehrheit *für* die Dinger ausgesprochen hat). Bezüglich der Gefahr, das das ganze vergessen geht - wenn das Ding funktioniert wirds nicht vergessen gehen, wenn nicht is nicht so schlimm weil das Zeugs da drin sich nicht wirklich ändert... --Datei:Sugimori 672.pngMecanno-manMäh 00:56, 29. Apr. 2020 (CEST)
Sehe ich ganz anders. Die Breite der News über die gesamte Seite ist bewusst gewählt. Sie trennt die Navigation von wechselndem Wikizeugs. Durch die Splittung geht die klare Struktur verloren und die Leute wollen News, daher fände ich es verkehrt eine so wichtige Box zu halbieren. Die damalige Abstimmung war lediglich für Ja und Nein zur Box gedacht und wenn man sich die ansieht zeigt sich das die Gegenteiligen Argumente überwiegen. Allerdings zählen hier lediglich die Anzahl der Stimmen. Mmn kann sowas auf die Seite Mitmachen. Da ich wette das über 75% der Leser nicht über die Hauptseite ins Wiki gelangen. Und die restlichen 25% sollten Mitmachen bereits entdeckt haben ka.gif Denn User die aktiv mithelfen wollen werden auch auf Mitmachen klicken oder könnten darauf verwiesen werden. Halte ich zumindest für besser, wie die Verschandelung der Hauptseite durch etwas was nicht einmal einen Bruchteil der Leser interessiert. Hier können auch Postings auf SocialMedia zur stärkeren Promotion von Mitmachen weiter helfen. Statt über das Design dieser Box zu reden wäre erstmal der Inhalt zu klären. Denn hierzu gibt es (wenn man die Baustellenbanner mit einrechnet) außer die Projekte suchen Mitarbeiter seit Eröffnung der Diskussionen keine weiteren ersichtlichen Inhalte. Und diese Müsste-man-mal-machen-Sachen bleiben liegen weil sie einfach viel zu umfangreich sind. Da wirst du auch keinen Neuling für begeistern können. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:31, 29. Apr. 2020 (CEST)

Ziel ist es, Leuten zu zeigen, dass es im Wiki etwas zu tun gibt. Das auf eine Seite wie Mitmachen zu packen halte ich für verkehrt, denn da werden eh nur Leute hinkommen, die mithelfen wollen. Es geht darum Leute dazu aufzufordern überhaupt mitzuarbeiten. --Datei:Sugimori 672.pngMecanno-manMäh 12:11, 29. Apr. 2020 (CEST)

Welche Zeitung schreibt ihre Stellenanzeigen auf die Hauptseite? Sie stehen i.d.R. im entsprechenden Bereich. das könnte auch ganz unten über der EP Leiste sein... oder wir kürzen/verlängern das XdW einfach um paar Wörter. so das eine Box darunter oder daneben passt. Ist eine Idee. Aber im Großen und ganzen gehört dies nicht auf die HS sondern nach Mitmachen. und du hast selbst das Beste argument geliefert da werden eh nur Leute hinkommen, die mithelfen wollen. Genau diese Leute wollen wir doch. User die es wollen und nicht welche die sich genötigt fühlen oder aus langweile eher verschlimmbessern. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:09, 29. Apr. 2020 (CEST)
Ich sehe hier einen gravierenden Unterschied. Nehmen wir dein Beispiel mit der Zeitung; du gehst da nicht davon aus, dass du als Leser da einen Artikel drin verfassen kannst/darfst/sollst (Leserbriefe aussen vor gelassen, aber die sind klar als solche gekennzeichnet). Ich glaube, so ähnlich sehen viele User das Wiki, weil sie das Wikimodell gar nicht kennen. Diese Wissensdifferenz ist meinem Verständnis nach was wir mit den Stellenanzeigen überbrücken wollen. Mitmachen wird nur von Leuten aufgerufen werden, die entweder bereits wissen das hier jeder mitmachen kann, oder die denken das ganze laufe hier wie eine "normale" Fansite (vgl. Bisafans/Pokefans/Serebii) ab und wem man Artikel schicken soll (eine Hürde, der sich mehr Leute nicht gewachsen fühlen im Vergleich zu der vom Wiki). Gerade diese letztere Zielgruppe ist hier mMn. die die wir ansprechen wollen; diese werden aber vornehmlich wohl gar nicht erst auf mitmachen klicken, weil sie sich eh nicht glauben im Stande zu sein den Ansprüchen der Admins gerecht zu werden. --Datei:Sugimori 672.pngMecanno-manMäh 13:34, 29. Apr. 2020 (CEST)
Es war für mich noch nie so schwer einen gescheiten Diskussionsbeitrag zu schreiben. Meine Gedanken schwirren von einem Argument von Ryu zum anderen. Deshalb hier die komplett überarbeitete Version (ist hoffentlich besser als mein erster Entwurf (der nur lokal auf meinem PC ist)):
Das Ziel der Stellenanzeigen ist das offene Zeigen und aufmerksam machen. Deswegen der Platz auf der Hauptseite. Schön und gut, wenn Seiten wie "Mitmachen" oder die To-do-Liste verbessert wurden, aber das bringt wenig, wenn keiner sie findet. Auf der HS haben wir meines Wissens nach eine Fläche, die auf "Mitmachen" verlinkt und die ist zum Teil transparent, neben großen Bannern, die die Aufmerksamkeits-Erreger der Hauptseite sind. Das geht daneben einfach unter und noch allgemeiner als der Text davon gehts denke ich nicht. Das ist genau richtig für so eine Fläche, spricht aber mMn kaum einen an. Und natürlich finden trotzdem einige Leute die Seite, aber viele bemerken es einfach nicht und die wegfallen zu lassen, wäre höchst ineffizient. Links zu Seiten wie "Missionsbrett" oder "To-do-Liste" haben wir glaube ich bei den meisten Seiten nur versteckt in der Sidebar und dort gehen sie in der Masse der anderen Links unter. Da ist eben wieder der Vorteil, dass diese beiden Seiten durch die Stellenanzeigen-Box offen verlinkt werden würden. Außerdem soll die News-Box nicht halbiert werden, wurde sie auch in keinem Entwurf. "Aktuelles" war immer breiter und dominanter und hatte mehr Platz als die Stellenanzeigen-Box.
Etwas, das Mec in seinem Beitrag in etwa auch angesprochen hat: Meiner Ansicht nach besteht bei vielen Leuten der Mythos, dass Wikis bereits vollständig sind, sie nichts mit ihrem Wissen beitragen können oder ähnliches. Und diesen Irrglauben anzugehen sollte eines der wichtigsten Ziele von uns beim Thema Usergewinnung sein (und genau dafür sind die Stellenanzeigen wunderbar geeignet). Und wir haben doch bereits Beispiele, die zeigen, dass Leute aktiv geworden sind, als sie bemerkten, dass etwas fehlt (spontan fallen mir Luca und ich ein, es gibt aber auf jeden Fall noch weitere).
Dann noch etwas zur vergangenen Abstimmung, die Ryu angesprochen hat: Die Argumente der Contra-Seite der Abstimmung damals waren grob zusammengefasst: "Der Einstieg ist zu schwierig, wir brauchen ein Konzept, wie wir den neuen Usern helfen können." Und das ist ein völlig anderes Thema, weshalb die Kritik, dass bei der Abstimmung die Pro-Seite weniger Argumente aber mehr Stimmen hatte, meiner Ansicht nach unberechtigt ist.
Abschließend: Ryu, direkte Wortwahl ist ja schön und gut. Aber deine Direktheit geht teils klar in den beleidigenden Bereich. Und etwas, an dem viele Leute mit Ideen und Entwürfen gearbeitet haben, etwas, das ich mühsam im TestWiki nachgebaut habe, einfach als "Verschandelung" und "schrecklich" abzustempeln ist respektlos und unangemessen. Direktheit ist gut, aber es gibt einen Unterschied zwischen "Das gefällt mir nicht, das, das und das sollte geändert werden" und "Das ist scheiße". --DeXter 14:53, 29. Apr. 2020 (CEST)
Ich hatte eigentlich vorgehabt, mich hier vorerst noch zurückzuhalten, aber es gibt doch ein paar Sachen, die ich gerne loswerden würde. Ich kann Ryus Argumente grundsätzlich nachvollziehen. Wir weisen an vielen Stellen darauf hin, dass es Baustellen im Wiki gibt und sind jederzeit bereit, zu helfen, wenn jemand etwas machen möchte, aber nicht so richtig den Einstieg findet. Das Problem ist: Sowas passiert so gut wie nie. Ob es daran liegt, dass die Leute nicht wissen, dass sie helfen können, oder schlicht nicht helfen wollen, lässt sich natürlich nur schwer mit sicherheit sagen, aber es ist davon auszugehen, dass tatsächlich beides der Fall ist. Und so, wie sich momentan die VBW entwickeln, würde ich sogar so weit gehen und behaupten, dass letzteres in den vergangenen paar Jahren deutlich stärker auftritt als zuvor. Woran das jetzt liegt, sei mal dahingestellt, aber führt auf jeden Fall etwas interessantes auf: Bei den Leuten bringt uns auch nen Haufen Stellenanzeigen nichts. Für die, die ohnehin interessiert sind, muss ich Ryu dahingehend recht geben, dass diese sich auch freiwillig umsehen werden und beim Mitmachen und in der globalen To-Do fündig werden. Selbstverständlich würde es denen aber auch nicht schaden, wenn sie die Stellenanzeigen hätten. Und dann gibt es noch die, die unvoreingenommen im Wiki unterwegs sind und weder direkt dagegen sind, zu helfen, noch bewusst hier sind, um zu helfen. Auf die würden sich die Stellenanzeigen vermutlich am ehesten auswirken. Zu der Positionierung möchte ich mich an dieser Stelle nicht wirklich äußern, ich habe jetzt einige Designs gesehen, die teils mehr oder weniger vielversprechend waren, habe mir selber auch einige Gedanken gemacht, wo man die Box platzieren könnte und bin zu dem Schluss gekommen, dass es keine perfekte Möglichkeit gibt, mit der man alle zufrieden stellen kann. Man wird hier also irgendwie einen Kompromiss finden oder eine Abstimmung durchführen und danach eine harte Linie fahren müssen.
Etwas, dass mich aber schon länger bei den Stellenanzeigen stört und das ich schon mehrfach erwähnt habe, für das mir aber bisher niemand eine Lösung liefern konnte: Der Inhalt dieser Anzeigen. Sinnvollerweise würde man möglichst einfache Aufgaben angeben, damit Neulinge sich einfacher im Wiki einfinden können, ohne großartiges Vorwissen mitzubringen. Bisher ist es mir aber nicht gelungen, in einem meiner eigenen Projekte eine Aufgabe zu finden, die einfach genug ist, um diesem Anspruch gerecht zu werden und gleichzeitig nicht schnell genug einfach von mir selbst erledigt werden könnte. Vielfach ist es dabei auch wichtig, dass Aufgaben dringend sind, obwohl sie einfach sind. Ich werde unter keinen Umständen Aufgaben zurückstellen, die dringen erledigt werden müssen, nur weil sie einfach genug sind, dass sie ein blutiger Anfänger übernehmen könnte. Und damit wird auch meine Sorge offensichtlich: Einfaches ist häufig dringend und so einfach, dass ich es am schnellsten selber erledige, während lediglich komplexe Aufgaben liegen bleiben. Ich leite zwar "nur" drei Projekte im Wiki, gehe aber davon aus, dass es anderen genau so gehen wird, dass sie nicht in der Lage sein werden, Aufgaben zu stellen. Und dadurch befürchte ich, dass die Stellenanzeigen über kurz oder lang entweder (nahezu) leer stehen werden oder wieder aufwendige Aufgaben, wie sie bislang im Missionsbrett zu finden sind, hinzugefügt werden.
Abschließend noch zwei Punkte: Zum einen hatte mich damals bei der Abstimmung für die Stellenanzeigen ausgesprochen, obwohl ich bereits damals besorgt war, dass sich kein sinnvolles Konzept für den Inhalt finden würde und bislang scheint sich diese Sorge zu bewahrheiten. Sollten andere ebenfalls besorgt sein, dass sie selbst nichts zu den Anzeigen hinzuzufügen haben, möchte ich dazu aufrufen, zu überdenken, wie zukunftsfähig diese Idee tatsächlich ist. Wenn ich da mit meinem Projekt alleine stehe, dass ich dem nichts hinzufügen könnte, werde ich dem ganzen aber natürlich nicht im Weg stehen. Zum anderen muss ich mich auch gegen Ryus Wortwahl aussprechen. Ich kann nachvollziehen, dass du nicht ganz zufrieden mit dem Design und der Ausführung bist, aber das lässt sich definitiv anders ausdrücken. Eine weitere Verfolgung der Umsetzung wurde damals in einer fairen Abstimmung beschlossen, und wie alle Abstimmungen werden wir mit dem Ergebnis leben und nicht einfach alles umwerfen, nur weil einer nicht zufrieden ist. Du kannst aber natürlich wie sonst auch versuchen, einen besseren Vorschlag einzureichen; wenn es dir die Arbeit wert ist, kannst du sogar einen Vorschlag erstellen, der in eine vollkommen andere Richtung geht und die erzielten Punkte auf einem völlig anderen Weg erreicht. Ich behaupte einfach mal, dass wir grundsätzlich auch von den Stellenanzeigen als solchen absehen, wenn es einen Vorschlag gibt, der unseres Erachtens nach das Ziel der Nutzer-Anwerbung besser erreicht. Bis dahin wird die aktuelle Diskussion aber weiter verfolgt, du kannst zusätzliches Feedback angeben, aber das Vorhaben zu Stoppen ist definitiv nicht Sinn der Diskussion. -- RobbiRobb 15:41, 29. Apr. 2020 (CEST)
Sorry wenn du oder sonst wer sich auf den Schlips getreten fühlt. Ich werde allerdings meine Meinung nicht ändern nur damit sie jemanden gefällt. Und wie du sagst ich bin direkt. Wenn etwas Scheiße ist, dann kannst du sicher gehen das ich auch schreibe das es Scheiße ist. In dem Fall finde ich es lediglich Schrecklich, da es mMn das Gesamtbild verschlechtert. Und dabei bleibe ich auch. Klärt erstmal was in diese Box rein soll. Davon steht nirgends etwas. Und ich glaube auch nicht wenn eine Liste mit sämtlichen Projekten und davor nem "dieses Projekt braucht Mitarbeiter" die User animiert den Sinn und Zweck eines Wikis zu verstehen. Das dies zum Ziel führen wird, glaube ich seit der Baustellenbanner Diskussion nicht mehr. Auch so müsste-man-mal-machen-Sachen.... Es gibt unzähliges was was auf der To-Do versauert oder allgemein bekannt ist oder (an die Leute gerichtet die mich privat bzgl. Klamotten aus StSd angeschrieben haben mit Worten du hast es doch sonst auch immer gemacht, wann machst du es endlich mal, hoffe das ist dann auch vollständig...) Es wird einfach immer abgewälzt, da die Leute selbst keine Intention haben oder es für sie zu aufwendig ist. Und wenn es für "erfahrene" User zu aufwendig ist, dann wird sich ein Neuling dessen garantiert nicht annehmen. Daher sollte mMn andere Optionen angedacht werden. Und aus diesem Grund habe ich mich größtenteils aus dieser Diskussion raus gehalten. Nun geht es aber darum das News (ich betone halbierung das heißt: aus einer Box zwei zu machen) oder ein anderer Bereich dessen weichen soll. Und da bin ich wie gesagt dagegen. Zurück zum Kernpunkt was soll in diese Box rein, wie wäre es mal mit einer Liste der Angaben die da rein soll! So eine Projektliste scheitert ja schon am Wort XdW... Sobald der Inhalt geklärt ist starten wir einfach ne Abstimmung wo das Ding hin soll. Sollte die Mehrheit es auf die HS wollen so sei es... Auf die Hauptseite gehört es mMn aus vielen Gründen die bereits ellenlang diskutiert worden nicht hin. Ich werde diese hier nicht wiederholen. Das kann ja jeder selber nachlesen. Sobald Inhalt und Ort geklärt ist kann sich daran gemacht werden sich hier ein Design zu überlegen. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 15:53, 29. Apr. 2020 (CEST)
Erstmal: Ich hab nochmals nachgeschaut und die Abstimmung war über die Frage der Einbindung einer Stellenanzeigenbox auf der Hauptseite. Ich sähe es demnach nicht als rechtens diese irgendwo sonst einzubinden und dieser Punkt ist imo. damit bereits geklärt.
Bezüglich Inhalt könnte ich aus meinen Projekten Punkte wie „Gesucht: Schreiber von Charakterbeschreibungen der Charaktere aus Schwert/Schild“ oder „Gesucht: Jemand, der Spielmechanik-Artikel aus dem Ranger-Bereich aufpolieren möchte“. Ich denke nicht, das wir in diesen Anzeigen etwas so umfangreich wie die gesamte To-Do, noch etwas so klein wie die Missionsbrettsachen da aufschlagen sollten. Die Sachen sollten gross genug sein das wir im Zweifel mehr Leute dran haben können, aber auch klein genug das sie überschaubar sind. Wahrscheinlich wärs auch noch hilfreich, gleich einen Ansprechpartner im Auftrag anzuführen. --Datei:Sugimori 672.pngMecanno-manMäh 17:10, 29. Apr. 2020 (CEST)

Wie Mec geschrieben hat ist das Thema "Hauptseite ja oder nein" bereits vom Tisch, weil das in der Abstimmung mit enthalten war. Dann zum nächsten kritischen Themenbereich, von dem das Überleben dieses Konzepts abhängt: Dem Inhalt. Dazu habe ich vor geraumer Zeit hier geschrieben, dass die Stellenanzeigen nicht zu aufwendig sein sollten. Das möchte ich zum Teil zurücknehmen. Natürlich sollten da jetzt keine Mega-Aufgaben rein, aber ich kann mir gut vorstellen, auch Anzeigen zu nehmen, die beispielsweise aus, für Anfänger machbaren, Teilschritten bestehen, aber zusammengenommenn sehr viel Zeit beanspruchen (z. B. Attacken-Videos eines Spielepaars aufnehmen und einbinden).

Nach ein paar Überlegungen sind mir ein paar mögliche Stellenanzeigen eingefallen. Vorweg: Allgemein Punkte bei Spielrelease, die zeitaufwendig sind und zu denen es keine Daten in Dumps oder ähnlichem gibt (da man sie sonst botten könnte). Und nein, diese To-do-Punkte sollen keines Falls warten. Diese würden gezeigt werden, während Wiki-Leute bereits daran arbeiten und würden wieder aus der HS-Box entfernt werden, wenn die Sache erledigt ist. Also quasi ein temporäres Angebot für zusätzliche Hilfe. Ein Beispiel dafür wäre das Eintragen von Items mitsamt Item-Fundorten bei neuen Spielen. Denn dafür gab es bei StSd keine Dump-Daten, oder? Keine Ahnung ob das allgemein bei Release der Fall ist, aber das soll bloß ein Beispiel sein.

Dann zu Stellenanzeigen, die nicht bereits von Wikingern bearbeitet werden würden. Hier finde ich die von Mec schon ganz gut, auch wenn die mMn schon wieder etwas in die komplexe Richtung gehen, aber das ist Ansichtssache. Ich denke die Stellenanzeigen müssen eine eindeutige Aufgabe enthalten. Beispielsweise eben wie "Charakterbeschreibungen formulieren", aber nicht "Beim Projekt mithelfen". Hier ein paar Ideen von mir (die Formulierungen seien mal dahingestellt; da müssen noch bessere gefunden werden):

  • „Schreiber eines PdWs - ein ca. 1450 Zeichen langer, informativer Text über ein Pokémon. (mehr Info)“
  • „Jemand, der Attacken-Animationen aus Pokémon Schwert und Schild beisteuern kann. (mehr Info)“
  • „Jemand, der den Artikel Liste der Attackennamen in anderen Sprachen um die 8. Generation erweitert.“
  • „Jemand, der den Artikel Rückstoß-Attacke um die 8. Generation erweitert.“
  • „Jemand, der den Artikel Versteckte Fähigkeit/Fundorte (8. Generation) erweitert.“
  • „Jemand, der den Artikel Spezialattacke aktualisiert.“
  • „Jemand, der Trainer-Attacken in <Spielepaar, Region, sonst was> prüft und einträgt.“
  • „Jemand, der die Itemfundorte in <Spielepaar, Region, sonst was> bei Bedarf besser formuliert.“

Da sind einige Sachen, die noch im Attacken-Projekt erledigt werden müssen oder grad in Bearbeitung sind. Die müssen gemacht werden, aber ich bin noch z. B. u. a. (schön formuliert xD) mit den Effekten beschäftigt, die mMn wichtiger sind. Also könnte man das in der Zwischenzeit anwerben. Die wären ein Beispiel für "an sich wichtig, aber es gibt wichtigeres". Sowas fällt denke ich auch bei anderen Projekten an.--DeXter 17:35, 2. Mai 2020 (CEST)

Etwas, das nur einen einzelnen Artikel betrifft, ist imo. eher etwas fürs Missionsbrett. Ich finde da sollten eher Sachen hin, die mehrere Artikel befassen. Generell könnte man aber die ewigen blauen Missionen dahinverlagern. Wäre dann einfach die Frage ob die immernoch gemacht werden wenns keine Missionen mehr sind. --Datei:Sugimori 672.pngMecanno-manMäh 19:11, 2. Mai 2020 (CEST)

Abstimmung: Design der Stellenanzeigen-Box auf der Hauptseite

Abstimmung beendet. Variante 3 wird umgesetzt

Typenicons und wie wir entscheiden, welche wir nutzen.

Bekanntlich sind die neuen SWSH-Typenicons relativ einheitlich dunkel, weshalb sich die Frage stellt, ob wir diese überhaupt nutzen wollen. Da es hier nicht viele sachliche Argumente gibt (mir fallen konkret nur „Aktualität“ vs „Nutzerfreundlichkeit bzgl. Differenzierbarkeitsgeschwidigkeit“ ein) wäre ich dafür das irgendwie per Abstimmung zu machen. Da diese Entscheidung aber schlussendlich hauptsächlich Leser betrifft wäre ich dafür, diese auch in den Entscheidungsprozess mit einzubeziehen. Aus diesem Grund schlage ich vor, in unseren Social Media-Kanälen (also: FB und Twitter) Umfragen zu machen, welche Icons als Standard genutzt werden sollen (und die Stimmen einfach aufzuaddieren). So könnte man auch mal wieder unsere Social Media-Kanälen etwas Leben einhauchen. Hätte da irgendjemand etwas dagegen? --Datei:Sugimori 672.pngMecanno-manMäh 17:20, 15. Dez. 2019 (CET)

Bin der Idee, auch die Besucher in diese Entscheidung mit einzubeziehen, gegenüber aufgeschlossen, finde es nicht falsch, da auch weitere Meinungen zu berücksichtigen. Finde aber, dass eine ausschließliche Verwedung direkter Abstimmungen bei Twitter und Facebook das Problem auch nicht löst, da Benutzer, die dort keine Konten haben genau so ausgeschlossen sind, als würde man eine Abstimmung im Wiki durchführen; Unterschied wäre lediglich, dass die der Abstimmung zugrunde liegende Benutzerkontenzahl größer ist. Bringt im übrigen auch das Risiko mit sich, dass manche bei beiden Seiten an der Abstimmung teilnehmen werden und andere nicht, dadurch könnte das Ergebnis verfälscht werden. Mit am praktischsten wäre daher meiner Meinung nach eine Abstimmung, die zentral auf einer Seite ist und sowohl über Social Media als auch direkt im Wiki beworben wird und dort eine Teilnahme auch ohne Account ermöglicht. Ich sehe darin allerdings ganz klar auch Sicherheitsrisiken, da eine Abstimmung, bei der die Stimmen nicht eindeutig zugeordnet werden können, leicht verfälscht werden können, etwa wenn Stimmen über IPs gezählt werden, die sich vergleichsweise einfach ändern lassen. Für den Moment also mein Pro dazu, die breite Leserschaft mit einzubeziehen, allerdings gefällt mir die Methode nicht, wobei ich nicht sicher sagen kann, ob mein Vorschlag da so viel besser ist. -- RobbiRobb 21:59, 15. Dez. 2019 (CET)
Ich finde das mit der Doppelabstimmung auf beiden Seiten nicht wirklich problematisch, da die Leute die das tun werden wohl kaum etwas anderes bevorzugen als die Allgemeinheit, wodurch das schlussendliche Resultat nicht verändert wird. Geht allerdings zugegebenermassen auch nur bei so einer single-choice-Frage, nicht bei etwas komplexerem. Bezüglich dem Ausschliessen von Nutzern ohne Konto, die ein Konto im Wiki haben: Ich habe die Hoffnung, dass es so viele Stimmen geben wird, dass das irrelevant wird, weil wir so wenige Stimmen ausmachen. --Datei:Sugimori 672.pngMecanno-manMäh 22:44, 15. Dez. 2019 (CET)
Ich finde es ebenfalls gut die Meinung der Besucher einzubeziehen. Bezüglich der Zentralität, Sicherheit vor Mehrfachabstimmungen und der Möglichkeit einer Teilnahme ohne Konten bei Facebook und Twitter habe ich hier mal etwas über Google Formulare ausprobiert. (Ich bekomme nur die Antworten und den Zeitpunkt der Antwort zu sehen.) Natürlich bleibt zwar auch dort eine Beschränkung auf Leute mit Googlekonto, darin sehe ich jedoch kein allzu großes Problem, da vom Gefühl her fast jeder ein Googlekonto hat. Ich kann die Vorraussetzung auch rausnehmen, dann wären aber eine Mehrfachabstimmung wieder möglich. Über Feedback zu dieser Idee würde ich mich freuen. GrollenKette951 00:43, 16. Dez. 2019 (CET)
Würde diese Umfrage entscheiden, wie wir das mit den Typ-Icons handhaben wollen (siehe Überschrift des Abschnitts), oder soll sie die Follower auf Facebook und Twitter miteinbeziehen (siehe einleitender Text)? Das ist für mich ein kleiner, aber feiner Unterschied. Zudem vermag ich nicht grundsätzlich mein „Ok“ hier zu äußern, ohne zu wissen, wie eine solche Umfrage aussehen soll. Gibt es visuellen Input für die Abzustimmenden? Heißt grundsätzlich neu vs. alt oder auch beispielhafte Auswirkungen auf bestimmte Vorlagen. Mein Eindruck der Follower unserer sozialen Kanäle ist über die Jahre eher der, dass sie nicht die wirkliche Besucherbandbreite abbilden können. Allgemein behagt es mir, eine bzw. zwei Abstimmung(en) auf den beiden Kanälen durchzuführen, um über solch grundlegenden Dinge entscheiden zu lassen. ~ Taisuke Diskussion 10:29, 16. Dez. 2019 (CET)
Wenn wir das machen müsste es schon ein entscheiden sein, weil sich das ganz schlecht macht wenn wir ne Umfrage machen und die dann nicht umsetzen. Für mich ist es imo. grundsätzlich neu vs alt, mit Ausnahmen wie z. B. diese Tabelle. Etwas anderes zu machen macht imo aus rein technischer Sicht keinen Sinn, da damit relativ aufwändig für jeden Fall entschieden werden muss, ob man das neue oder das alte Icon nehmen will. Eine solche Entscheidung könnte man auch nicht über eine Abstimmung machen. Bezüglich der tatsächlichen Umsetzung finde ich durchaus, das Bildmaterial angeboten werden sollte; bevorzugterweise irgendwo an exponierter Einzelstelle, irgendwo in ner Aufzählung und auch einmal ne Aufzählung auf dunklerem Hintergrund. Über die genauen Bilder kann man aber definitiv noch reden. Die Idee das über eine Google-Umfrage zu machen finde ich allerdings auch gut, wenn nicht sogar für diese Zwecke besser; die Idee das per unsere Social Media-Kanäle zu machen hätte allerdings den Vorteil das diese zur Zeit relativ abgelegten Kanäle wieder irgendwas bieten. --Datei:Sugimori 672.pngMecanno-manMäh 23:33, 16. Dez. 2019 (CET)
Fürs Protokoll: Nach kurzen tests ist offensichtlich, dass Google Forms sich ohne Google Eccount lächerlich einfach austricksen lässt (bzw. Mehrfachbeantworten sogar zugelassen sind.) Das sollte man wenn mans nutzt also eindeutig mit Accountzwang machen. --Datei:Sugimori 672.pngMecanno-manMäh 23:47, 16. Dez. 2019 (CET)
Besucher miteinzubeziehen finde ich ebenfalls gut. Entscheidungen sollten aber mMn nicht durch eine Umfrage allein getroffen werden können. Durch derartige Umfragen z. B. über das Google Formular von Peter ist die "Bequemheit" zu groß, um alles bei dieser Entscheidung zu berücksichtigen, bevor man sie fällt (mal abgesehen von der mangelnden Erfahrung/Fachkenntnis der Besucher). Bei dem Formular wählt man eine Option aus, drückt auf "Senden" und fertig; das dauert wenige Sekunden, geht super einfach und man muss nicht viel nachdenken. Wenn man allerdings hier auf der AD etwas schreibt muss man erstmal seinen Text verfassen und liest nochmal drüber bevor man die Änderung speichert, das dauert länger und man denkt auch mehr über das Thema nach. Meiner Meinung nach sollten also solche Umfragen in Diskussionen wenn dann nur berücksichtigt werden, um die Nutzerfreundlichkeit bzw. den optischen Eindruck der Besucher zu ermitteln. Sollten solche Umfragen stattfinden, sollte mMn nach dem Beschluss eine Stellungnahme von uns warum es so entschieden wurde auf den Social Media Kanälen geposted werden, um je nach dem einen anderen Ausgang als den der Umfrage zu rechtfertigen, damit nicht der Eindruck entsteht wir würden Scheinumfragen o.ä. machen.--DeXter 15:24, 20. Dez. 2019 (CET)

Eingeschlafen oder geht es hier noch weiter? Wir verwenden immernoch die alten Icons. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:29, 13. Jan. 2020 (CET)

Ich bin gerade mehr durch Zufall auf diese Diskussion gestoßen. Zugegeben, so furchtbar finde ich die neuen Icons gar nicht, eher einfach nur etwas groß. Die ganze Diskussion ist total auf diese "Wie machen wir eine Umfrage"-Schiene gerutscht. Die Idee an sich ist zwar nett, aber wenn sich daran dann die Diskussion aufhängt, ist uns damit leider auch nicht geholfen. Vielleicht sollte man anstatt seine ganze Energie in eine Umfrage bei wo auch immer zu stecken, einfach ganz unvermittelt hier eine Abstimmung starten. Ich wundere mich gerade sowieso, wieso das eine Abstimmung braucht, früher wurde das doch auch einfach direkt zu den neuen Icons umgesetzt, oder? :'D Lg --Fliegen bis zum Horizont. Killuu 15:25, 29. Apr. 2020 (CET)
Das ganze war etwas versandet, nachdem auf Discord einige Zeit darin investiert wurde, Icons zu erstellen, die aktuell wirken aber gleichzeitig auch noch nutzerfreundlich sind, dann aber gestoppt wurde, weil wir keine selbsterstellten Icons mehr nutzen wollen und zuletzt Zeit darein investiert wurde, diese wo vorhanden gezielt zu entfernen. Ein Mittelweg wäre daher an dieser Stelle ausgeschlossen, man müsste also tatsächlich zwischen den beiden Möglichkeiten, die eingangs von Mec erwähnt wurden, entscheiden. -- RobbiRobb 15:49, 29. Apr. 2020 (CEST)
Ich bin immer noch dafür das wie von GrollenKette vorgeschlagen zu machen. Den Link könnte man dann neben Twitter/Facebook auch auf Discord irgendwo sowie im Wiki erwähnen. Wikiseitig ist nur etwas blöd das wir die Sitenotice grad für die VbW brauchen. --Datei:Sugimori 672.pngMecanno-manMäh 17:19, 29. Apr. 2020 (CEST)
Da bin ich nach wie vor anderer Meinung, Mec. Und nun geht die Diskussion wieder in dieselbe Richtung, wie von der lieben Killuu angemerkt, weshalb ich nicht verstehe, warum es just wieder nur darum zu gehen hat, wie die Abstimmung auszusehen hat... drop.gif
Anstatt sich wie die letzten 10 Jahre auf eine Abstimmung im Wiki einzulassen, die schnell organisiert und gut nachvollziehbare Stimmen mit Argumenten ermöglicht, möchtest du dich urplötzlich auf Stimmen verlassen, bei denen weder erkennbar ist, ob sie ernst gemeint sind, es doppelte Stimmabgaben mittels verschiedener Accounts bzw. einfach auf unterschiedlichen Plattformen gegeben hat und am Ende vermutlich überhaupt nicht möglichst objektiv einschätzen können, in welchen Artikeln das zu Veränderungen führt. Das kann ich nicht nachvollziehen.
Ich bin mir sicher, dass wäre die Abstimmungsart von Anfang an gar nicht ins Spiel gebracht worden, hätten wir unlängst eine umgesetzte Entscheidung innerhalb des Wikis. ~ Taisuke Diskussion 17:32, 29. Apr. 2020 (CEST)
Der Grund warum ich das nicht einfach als Wiki-Abstimmung machen möchte ist, das sich das Thema gut dazu eignet Aufmerksamkeit für die Arbeit am Wiki zu generieren. Es ist ne banale ja/nein-Frage wo man sich nicht all zu lange einlesen muss um mitentscheiden zu können. Ausserdem kann man mit einer öffentlichen, transparenteren Abstimmung auch schonmal die "Öh, warum isn das jetzt so, das is doof"-Kommentare umgehen. --Datei:Sugimori 672.pngMecanno-manMäh 18:12, 29. Apr. 2020 (CEST)
Solche Entscheidungen sind aber nicht dafür da, um damit irgendwelche sozialen Kanäle zu beleben. Wer im Wiki mitentscheiden möchte, arbeitet mit und erarbeitet sich das Recht dafür. Wollen wir beispielsweise die Stimmberechtigung nun ad absurdum führen, da nun einfach jeder Hans und Franz Mitspracherecht innehat? Ich meine, wofür ist dieser Rang dann überhaupt noch da? Versteh mich nicht falsch, für Meinungsumfragen oder anderweitiges Feedback über soziale Kanäle bin ich jederzeit zu haben und auch dankbar, aber eine Entscheidungsgewalt außerhalb des Teams etablieren zu wollen, halte ich für grundsätzlich falsch. Wenn ich mich – überspitzt gesagt – fortan bei wichtigen Grundsatzentscheidungen immer einer fremden bzw. äußeren Marschroute beugen muss, dann weiß ich nicht, wie lange der Laden hier noch läuft. ~ Taisuke Diskussion 18:35, 29. Apr. 2020 (CEST)
Insgesamt unterstütze ich Tais Argumente. Robbi hat gerade auf Discord noch einen ganz wichtigen Punkt reingeworfen. Falls für irgendeine Abstimmung irgendein Account außerhalb des Wikis nötig ist, nimmt man eventuell stimmberechtigten Nutzern ihr Abstimmungsrecht. Ich würde außerdem auf Social Media eher sowas schreiben wie "Es wurde XY entschieden. Wollt ihr bei der nächsten Abstimmung auch eure eigenen Ideen einbringen? Dann werdet zum Wikinger!". Und insgesamt finde ich es verwunderlich, dass sowas banales zur Abstimmung mit der Leserschaft vorgeschlagen wird, diese aber bei ganz anderen Dingen außen vor gelassen wird, zum Beispiel nicht im Anschluss nach ihrer Meinung gefragt wird (aka Attackenauslagerung, das scheint ja immer wieder zu Problemen zu führen). Ich meine sowas wie "Wir haben die Pokémonseiten umstrukturiert, wie findet ihr das?" oder so. Insgesamt empfinde ich es halt als unbefriedigend, dass diese doch so leicht entscheidbare Sache hier seit Ewigkeiten hier rumgammelt wegen einer eigentlich ganz anderen Diskussion (Beleben von Social Media). Wollte hierzu ja eigentlich nichts mehr schreiben, weil ich meine Meinung schon kundgetan hatte, ich hoffe, du bist mit dieser Antwort halbwegs zufrieden Mec :). --Fliegen bis zum Horizont. Killuu 21:32, 29. Apr. 2020 (CET)
Die meisten Sachen sind zu kompliziert für eine allgemeine Umfrage; die Attacken-Auslagerung war ja z. B. hauptsächlich aus technischen Gründen herausgegangen - das ist nicht etwas, was einem normalen User voraussetzbar ist. Deshalb finde ich ja gerade dieses Thema eignet sich dafür - es ist extrem simpel. --Datei:Sugimori 672.pngMecanno-manMäh 21:51, 29. Apr. 2020 (CEST)
Vielleicht habe ich es zu schwammig formuliert. Ich meine nicht, dass zum Beispiel die Attackenentscheidung durch Leser hätte entschieden werden sollen, sondern dass man ihnen im Nachhinein nochmal Möglichkeiten für Kritik und neue Anregungen gibt. --Fliegen bis zum Horizont. Killuu 21:55, 29. Apr. 2020 (CET)

Da ich ja durch das voreilige Erstellen einer Testumfrage ja nicht ganz unschuldig bin an der aktuelle Situation, hier mal meine Meinung: Sowohl Mec als auch Tai bringen Argumente, die ich unterstütze. Zum einen müssen immer noch die Personen hinter dem Wiki entscheiden, wie und ob die Typ-Icons aus SWSH benutzt werden sollen. Zum anderen wäre es natürlich hilfreich die Meinung der Leser mit einzubeziehen, da diese eventuell Interesse hätten an der Verwendung der neuen Icons. Die Idee, das ganze über Social Media zu machen, kam ja auch, da unsere, zu diesem Zeitpunkt toten, Kanäle (besonders Twitter) einen kleinen Push brauchten.
Insgesamt bin ich der Meinung, dass man den Lesern über Social Media ein minimalstes Mitentscheidungsrecht geben sollten, in Form der Umfrage. Diese sollte dann aber klar als Meinungssammlung ersichtlich sein und auch klarstellen, dass im Anschluss an die Umfrage alle Stimmberechtigten Benutzer eine Abstimmung halten über das weitere Vorgehen unter Betrachtung der Umfrage halten. So geben wir den Lesern nur ein kleines Mitspracherecht und das ganze Vorhaben wird immer noch von den aktiven Autoren, die sich mehr mit dem Wiki auskennen entgültig entschieden. GrollenKette951 22:10, 29. Apr. 2020 (CEST)

Ich glaube eine nicht-bindende öffentliche Meinungsumfrage ist so ziemlich das schlechteste was wir machen können. Wenn wir uns da dann im Nachhinein anders entscheiden wird das eine Imageschädigung zur Folge haben - das genau Gegenteil von dem was wir mit einer öffentlichen Umfrage bewirken wollen. --Datei:Sugimori 672.pngMecanno-manMäh 03:21, 30. Apr. 2020 (CEST)
Da ich mit meiner Meinung weitestgehend alleine bin, will ich die Entscheidungsfindung nicht länger aufhalten. Führt eure Umfragen auf den sozialen Kanälen durch und setzt das danach dann zeitnah dem Ergebnis entsprechend um. Ich werde mich an dem Prozess nicht beteiligen und auch nicht abstimmen. Bin schon gespannt, welche Frage zukünftig mit Ja oder Nein beantwortet werden kann und daher als „simpel“ oder „banal“ genug angesehen wird – trotz einer hier über sechs Monate geführten Diskussion ohne Ergebnis – um sie erneut an eine kleine Gruppe der Leser abzugeben. Lustigerweise wissen wir über unser Entscheidungsgremium lediglich, dass sie mal ein „Like“ hinterlassen haben. Ob sie das PokéWiki überhaupt (noch) aktiv nutzt, weiß niemand. Die meisten stillen Mitleser werden durch die beiden Kanäle wohl kaum das Gefühl bekommen, dass sie mehr einbezogen worden sind als sonst. Aber bevor ich hier noch weiter ausschweife, lasse ich es lieber sein. Have fun! 20120215170011_sonne.gif ~ Taisuke Diskussion 08:41, 30. Apr. 2020 (CEST)
Nur mal so am Rand. @Tai, ich teile hier vollständig deine Meinung. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:00, 30. Apr. 2020 (CEST)
Pro Tai! --Toben des Meeres. Killuu 09:56, 30. Apr. 2020 (CET)

Die DLCs

Ich weiß nicht, wie weit es schon klar ist, wie wir sie behandeln. Aber ich wäre für eigene Artikel und Kürzel. Z.B. IR=Insel der Rüstungen und SK=Schneelande der Krone. Weitere Meinungen dazu bitte. Das Isso 08/15 Konter 22:59, 9. Jan. 2020 (CET)

Da die DLCs Versionsunterschiede haben werden bräuchte man zumindest zwei/DLC, einfach nur IR und SK werden also nicht passen. --Datei:Sugimori 672.pngMecanno-manMäh 03:11, 10. Jan. 2020 (CET)
🤔 Für was überhaupt? Es ist immernoch die Galar-Region und immernoch Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/Sd. Wenn wir soetwas brauchen würden dann würde ich nicht die Einzelnen Inseln nehmen sondern ein in Gelb/Grün gehaltenes EX wie es die offizielle Seite macht oder EP für Erweiterungspass, natürlich in Sk-Optik. So lässt sich bei bedarf das Kürzel für den Erweiterungspass dahintersetzen, denn in diesem sind beide Inseln enthalten, denn die Unterschiede sind nicht zwischen den Inseln sondern weiterhin zwischen den Spielen. Und Linktechnisch hätte ich gesagt geht das EX/EP dann entweder zu StSd/EX bzw. EP oder man macht aufgrund des Kontent einen eigenständigen Artikel StSw EX bzw. EP. Grüße * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 08:51, 10. Jan. 2020 (CET)
Der Ansatz und das Design deiner Idee gefällt mir, Ryu. Leider gibt es zwischen den Inseln auch Unterschiede. So sind unterschiedliche Pokémon auf den Inseln erhältlich, z. B. Coronospa erst mit dem zweiten Teil des Erweiterungspasses. Daher brauchen wir in meinen Augen schon mehr als nur ein Kürzel. ~ Taisuke Diskussion 09:23, 10. Jan. 2020 (CET)
@Taisuke: Die unterschiedlichen Pokémon sind doch Schwert, Schild abhängig was auf der Rüstungsinsel und später auf der Krone kommt, da der EX-Pass für beide Inseln pro Spiel ist wüsste ich nicht für was es weitere Sks benötigt. Auf der Rüstungsinsel gäbe es 3 Kombinationen Vorlage:Spielkuerzel/StEX, Vorlage:Spielkuerzel/SdEX, und Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdEX oder man macht 3 einzelne Sk mit StEX, SdEX und StSdEX.... ob man da eines macht und das immer dran hängt oder 3 separate soll mir da egal sein, jedenfalls lässt sich mit diesen mMn eindeutig zeigen: das der Content Editionsabhängig ist und das dafür der EX-Pass benötigt wird der ja schließlich beide Inseln freischaltet. Somit hat jeder mit Zugang zur Rüstungsinsel später auch Zugang zur Krone.... daher kann ich der Notwendigkeit mehrerer Sks nicht ganz folgen da es ja nur ein Pass ist. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:39, 10. Jan. 2020 (CET)
Man könnte auch nehmen was da ist ka.gif wie hier am Beispiel Sk plus das jeweilige Icon... mein Favorit ist aber weiterhin EX da es kurz prägnant und zudem in Kombination mit dem Spielkürzel mMn ausreichen wäre
Vorlage:Spielkuerzel/StDatei:Icon Rüstungsinsel.png
Vorlage:Spielkuerzel/StDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/StDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.png
Vorlage:Spielkuerzel/SdDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.png
Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png
* Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 11:21, 10. Jan. 2020 (CET)
Ich wüsste nicht, was dagegen sprechen würde, für jeden Teil des Erweiterungspasses ein eigenes Spielkürzel, im Endeffekt also insgesamt vier neue (Schwert-Rüstung, Schild-Rüstung, Schwert-Krone, Schild-Krone) einzuführen. Ich kann für mich hauptsächlich für den Item-Bereich sprechen, aber ich kann mir auch vorstellen, dass auch andere Bereiche davon profitieren könnten. Und zwar möchte ich ungerne neue Item-Fundorte zu den bereits existierenden hinzufügen, um Besucher, die die DLCs nicht besitzen, nicht zu verwirren, wenn dort Fundorte für Orte angegeben sind, die sie überhaupt nicht erreichen können. Da beide DLCs jeweils einen neuen Bereich freischalten, würde ich da auch gerne die Fundorte getrennt anbieten können, sodass dort auch nicht gemischt wird. Ich denke, die Richtung, in die ich möchte, sollte klar werden ^^
Visuell wäre ich dafür, einfach einen weiteren Buchstaben anzuhängen, der neben dem Hauptspiel klar macht, welche Erweiterung gemeint ist: STR, SDR, STK, SDK. Damit wäre man für alle möglichen Lagen gewappnet und müsste sich keine Sorgen machen, wenn irgendwelche verrückten, Editions- und gleichzeitig auch noch DLC-Spezifischen Inhalte kommen, bei denen wir uns eigentlich sicher sein können, dass es sie geben wird. -- RobbiRobb 17:34, 10. Jan. 2020 (CET)
Ich denke auch, dass neue Spielkürzel sinnvoll wären. Die Anhängung eines weiteren Buchstabens, wie mein Vorredner es bereits verdeutlichte, finde ich als Lösung recht einfach und gut.
P.S.: Wir haben ja sogar n Spielkürzel für etwas, das nicht einmal ein Spiel ist: Pokémon Bank BANK :D also warum dann einer Erweiterung, die ja schon etwas neues ist, das verwehren? -- GrüßeShortyBuzz 17:43, 10. Jan. 2020 (CET)
Mein Problem ist eher das einige Sks sowohl für Rüstung als auch Krone wollen, wo ich bisher immernoch nicht den Sinn heraus sehe da ja jeder der DLCs beides beinhaltet (Rüstung und Krone) nur halt Zeitversetzte veröffentlichung in 2 teilen und jeder der sich im Herbst den Pass für Krone holt sollte damit auch zur Rüstung kommt, mir würde jetzt kein Szenario einfallen was beides benötigt. Aber lässt sich ja wenn es soweit ist alles nochmal ändern ka.gif Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 18:43, 10. Jan. 2020 (CET)
Ich würde das ganze erst einmal abwarten und schauen, in wie weit es wirklich notwendig ist. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 03:45, 12. Jan. 2020 (CET)

Dem kann ich nur zustimmen -- Opii Wunschtraum 17:21, 13. Jan. 2020 (CET)

Mal eine Frage, wie wollen wir Die Insel der Rüstung und Die Schneelande der Krone behandeln? AN und für sich sind sie durch Neue Handlung, neue Pokémon usw wie eine Zusatzedition die einfach nur direkt ins aktuelle Spielnachgepacht wird. Daher fände ich es sinnvoll die DLC wie eigenständige Zusatzeditionen inklusive Spieleartikel zu behandeln. WIe ist da hier die allgemeine Meinung zu? Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 19:31, 21. Jan. 2020 (CET)

Der Meinung bin ich nicht. Es bleibt dasselbe Spiel wie vorher, zumal ja die Pokémon auch für die dazugepatcht werden, die den DLC nicht erwerben. Gleichnis: Mario Kart 8 ist auch Mario Kart 8 geblieben, obwohl damals 4 neue Cups hinzugefügt wurden. Etwas anderes ist das hier auch nicht. Zudem bin ich der Ansicht, dass wir für solche Entscheidungen abwarten sollten, in wiefern die Erweiterungspässe wirklich wie "eigene Spiele" behandelt werden können. Außerdem bin ich der Meinung, dass die Idee dahinter gar nicht neu ist. Früher hat man halt solche neuen Inhalte schon vorher auf das Spiel gepackt und einfach nur (mehr oder weniger erfolgreich) versucht geheim zu halten (Eichs Brief, Azurflöte ...). Im Grunde waren das auch nichts weniger als kleine (kostenlose) DLCs. Mit dem Unterschied, dass heute so etwas wirklich geheim gehalten werden kann, indem man erst später in die Spiele einfügt.
Also kurzum: Ich bin nicht dafür, dass man diese DLCs so separiert betrachtet. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 21:35, 21. Jan. 2020 (CET)
Seh ich ähnlich wie TiMauzi; wir sind btw so auch schon mit vorherigen Zusatzinhalten so verfahren (z. B. die Updates in Go oder die Portale-DLCs) --Datei:Sugimori 672.pngMecanno-manMäh 22:23, 21. Jan. 2020 (CET)


Ich würde mich freuen wenn wir die Diskussion Zeitnah zu Ende bringen. Persönlich würde ich mich bereits anhand des Materials vom ersten DLC für neue SK aussprechen. z.b. Vorlage:Spielkuerzel/St EX, Vorlage:Spielkuerzel/Sd EX und Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/Sd EX * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 17:16, 18. Jun. 2020 (CEST)

Hatte mich ja bereits auf Discord dafür ausgesprochen und spiele weiterhin mit dem Gedanken, bei den Items zwischen Hauptspiel und Erweiterungspass zu trennen, auch vor dem Hintergrund, dass bei einigen wenigen Items die Beschreibungen geändert wurden. (ups.gif) Die Frage ist aber ein Kürzel für beide Erweiterungen? Oder zwei getrennte, um noch mal besser differenzieren zu können? Für die Items wäre vermutlich letzteres praktischer, wie sieht das in anderen Bereichen aus? -- RobbiRobb 17:27, 18. Jun. 2020 (CEST)
Wie ich auch schon gestern merhfach im VC gesagt habe, bin ich eindeutig für eigene Spielekürzel; es entsteht nur Chaos, wenn dann mit dem StSd-Sk Sachen eingetragen werden, die aber nur im DLC vorhanden sind. Einfach um auf Nummer sicher zu gehen würde ich sagen eine Sk-Variante fürs 1. DLC und eine fürs 2. GrollenKette951 17:32, 18. Jun. 2020 (CEST)
Für z. B. die Fundortetabellen bei Pokémon und Items ist es sicherlich hilfreich eines zu haben, ich würde es aber z. B. bei Item- und Pokémontabellen in Orten lieber nicht sehen. Trotzdem sollte man imo. erst mal eines erstellen. --Datei:Sugimori 672.pngMecanno-manMäh 14:32, 19. Jun. 2020 (CEST)

Da wir alle keine Freunde von Abstimmungen sind, habe ich mich dazu entschlossen, die eigenen Spielkürzel ohne weitere Rückfragen zu erstellen. Aufgrund der Tatsache, dass Eintragungen oder Kontrollen nicht getätigt werden, weil hier erst eine Entscheidung benötigt wird, wäre es unangebracht noch mehr Zeit verstreichen zu lassen. Sollten wir feststellen, dass wir eines oder mehrere Spielkürzel nicht benötigen (Vorlage:Spielkuerzel/StRVorlage:Spielkuerzel/SdR, Vorlage:Spielkuerzel/StKVorlage:Spielkuerzel/SdK & Vorlage:Spielkuerzel/StEXSHEX), können wir das zu einem späteren Zeitpunkt immer noch wieder ändern und die Einbindungen in Artikeln mittels eines Bots entfernen lassen. Auch die Linkziele könnten bei Bedarf noch angepasst werden. Jedoch ist es wichtig, erstmal etwas zu haben, mit dem man arbeiten kann. Schließlich entsteht gerade ein kleines Chaos durch unterschiedliche Handhabungen improvisierter Spielkürzel, sodass ein Bedarf an eigenen Kürzeln nicht von der Hand zu weisen ist. ~ Taisuke Diskussion 11:54, 22. Jun. 2020 (CEST)

Zentrale Hinterlegung von Trainerdaten

Hab mir vor kurzem überlegt das es eigentlich unsinnig ist sowohl Vorlage:Team/Kopf als auch Vorlage:Orte Trainer/Kopf zu haben, da beide schlussendlich in etwa dasselbe machen. Bei der Idee, einfach im Charaker-Projekt die Orte-Vorlage zu nutzen ist mir dann aufgefallen, das es mehr Sinn machen würde, die Daten einfach in einem Artikel zu hinterlegen und dann daraus in die anderen zu ziehen. Ich würde deshalb vorschlagen, die ganzen Daten in den Orten und bei Charakteren aus den Trainer-Unterseiten zu ziehen, und da in nem includeonly ne Vorlage drum zu bauen, das man über nen Parameter auswählen kann welchen Trainer man haben möchte. Die tatsächliche technische Umstrukturierung würde ich aber vorschlagen nur Stück für Stück zu machen, da das nicht wirklich iwas is, was all zu wichtig ist. Wollte demnach nur mal fragen ob hier jemand grundsätzlich dagegen ist, insbesondere @GoPika, Cliffichen, Ryuichi und SortyBuzz, sowie RobbiRobb, an dem das ganze wahrscheinlich hängen bleiben wird... --Datei:Sugimori 672.pngMecanno-manMäh 17:46, 27. Feb. 2020 (CET)

Erstmal, der Name SortyBuzz gefällt mir grin.png. Dann kann ich mir nicht wirklich vorstellen, wie das funktioniert mit der von dir angesprochenen Datenhinterlegung über includeonly und Parameter. Aus diesem Grund kann ich mich noch nicht zu 100 % dafür aussprechen, wobei ich den Vorschlag nicht schlecht finde. Kann man dort auch irgendwie Vorlage:Berühmte Trainer und/oder Vorlage:Weitere Trainer einbinden? -- Cliffichen 22:56, 28. Feb. 2020 (CET)
Ne das geht nicht, es geht mir nur drum das die Orte/Trainer nicht an drei Orten mit identscher Befüllung steht. --Datei:Sugimori 672.pngMecanno-manMäh 23:06, 28. Feb. 2020 (CET)
An und für sich habe ich nichts dagegen einen Zentralen Platz zu schaffen von dem aus die Daten abgegriffen werden können, ob dieses dann auch funktioniert ist die andere Frage. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 23:31, 28. Feb. 2020 (CET)
Ich finde schön, dass schon davon ausgegangen wird, dass ich das übernehme. Das aber erst mal beiseite, ich halte es grundsätzlich für umsetzbar. Mit includeonlys und onlyincludes dürfte sich eine Struktur erstellen lassen, mit der sich alle Daten zentral an einem Ort lagern und in anderen Artikeln aufrufen lassen. Ich sehe allerdings zwei Probleme: Das System ist sehr anfällig, ein kleiner Fehler in den Konstrukten und es werden mehr als eine Seite zerlegt. Das führt auch gleich zum zweiten Problem: Einsteigerfreundlich sieht anders aus. Neue Nutzer werden schwierigkeiten haben, den Ursprung eines Fehler zu finden, helfen dadurch entweder gar nicht oder machen irgendwas anderes, um vielleicht doch noch ihr Ziel zu erreichen. In jedem Fall besteht die Gefahr, dass dabei ordentlich was schief geht. Sofern man aber bereit ist, dieses Risiko einzugehen, denke ich, dass man damit durchaus einen Gewinn haben könnte, da Daten dann global gleich sind. Vielleicht wäre es hier aber besser, noch in eine andere mögliche Richtung zu forschen, ob man die Daten nicht besser hinterlegen könnte. Wobei dann fragwürdig ist, ob es etwas gibt, dass sich leicht bedienen lässt und trotzdem in der Lage ist, unsere Daten zu speichern. -- RobbiRobb 23:33, 29. Feb. 2020 (CET)
So rein konzeptionell fällt mir keine Idee ein, auch nicht iwie mit externer Datenbank oder sowas, womit man die Daten von mehreren Orten aus ändern kann, ausser nem Bot der iwie auf Änderungen an der Vorlage achtet. Das halte ich aber für keine gute Idee. Demnach haben für mich alle potenziellen anderen Lösungen die von dir angesprochenen Userfreundlichkeits-Nachteile ebenfalls. Bezüglich das mit den mehreren Seiten kaputtmachen, ja das stimmt, gäbe es denn irgendwelche anderen Lösungen, die das umgehen und realistisch in der Umsetzung sind? --Datei:Sugimori 672.pngMecanno-manMäh 23:53, 29. Feb. 2020 (CET)
Die WMF-Extension LabeledSectionTransclusion könnte für so ein Unterfangen vermutlich hilfreich sein, und ist auch nicht allzu komplex. Das ermöglicht es, innerhalb einer Seite mehrere "benannte Onlyinclude" zu erstellen und per Parserfunktion einzubinden. Dadurch dürfte das Gesamtkonstrukt auch weniger fehleranfällig sein.
Eine umfangreiche Datenbanklösung neu aufzubauen (Zum Beispiel mit Wikibase, vermutlich alternativ mit Semantic MediaWiki oder Cargo) halte ich mit unseren personellen und technischen Ressourcen für unrealistisch, und wäre wenn ein Projekt, bei dem man sich mit Bulba kurzschließen sollte. Das Thema haben wir ja vor etwa 4 Jahren schon mal diskutiert.
-- Skelabra2509 (Diskussion | Beiträge) 17:44, 8. Mär. 2020 (CET)

Sind weitere Pokémon-Formen als Parameter notwendig?

Hallo zusammen!

Wie einige von euch sicherlich schon mitbekommen haben, liegen die HOME-Sprites sämtlicher Pokémon seit Upload noch nahezu ungebraucht herum. Das Ganze liegt an mir und einer Entscheidung, die ich diesbezüglich treffen müsste. Wollt ihr also einen Schuldigen haben: Hier bin ich! msnsorry.gif

Um das Ganze nun aber mal zu lösen, verfrachte ich die Entscheidung hierher, um sie nicht alleine treffen zu müssen, denn das möchte ich nicht. Grundsätzlich gab es im Jahre 2018 bereits eine kurze Diskussion zu diesem Thema, die aber am Ende ohne wirkliches Ergebnis eingeschlafen ist. Dies führte dazu, dass wir teilweise Duplikate und teilweise Weiterleitungen haben und ganz allgemein es in verschiedenen Vorlagen unterschiedlich gehandhabt wird.

Wer keine Lust hat sich die vorangegangene Diskussion durchzulesen (auch wenn sie nicht wirklich lang ist), bekommt hier ne kurze Zusammenfassung des Problems:

Es gibt bestimmte Pokémon, die in den Spieldaten über Formen verfügen, die bei uns aber als solche nicht verstanden werden. Am einfachsten lässt sich das an einem Beispiel erklären, wie z. B. Meteno. Grundsätzlich kennen wir die Meteorform und die sieben farbigen Kerne. Jedoch gibt es innerhalb der Spieldaten nicht nur eine Meteorform, sondern sieben: Eine je farbigen Kern. Auch wenn dies nie irgendwo ersichtlich ist, so handelt es sich in den Spieldaten um verschiedene Datensätze. Ein ähnliches und aktuelleres Dilemma haben wir beispielsweise bei Riffex, dessen Gigadynamax-Form bei beiden Formen (Hoch- und Tief-Form) dieselbe ist, sie in den Spieldaten aber als zwei unterschiedliche gehandhabt werden. Darüber hinaus gibt es aber auch bestimmte Event-Pokémon, wie z. B. Wuffels, die sich zwar nicht optisch vom eigentlichen Pokémon unterscheiden, jedoch spielintern als separate Form aufgeführt werden. Mit Pokémon Schwert und Schild gibt es nun zudem diese Wuffels-Form (heißt: mit Tempomacher) auch in Dyna-Raids.

Daher gilt es nun zu schauen und anschließend zu entscheiden, ob man zusätzliche Parameter für solche Fälle haben möchte oder nicht. Sollte man sich für die Verwendung einiger solcher neuen Parameter entscheiden, würden bei optischer Gleichheit keine Duplikate der Sprites, sondern Datei-Weiterleitungen erstellt werden.

Bevor ich hier aber noch weiter ausschweife, habe ich mich mit Ryu zusammengesetzt, um zu überlegen, welche weiteren Formen wir bislang nicht mit Parametern bedacht haben, warum dies der Fall war und ob man daran nicht etwas ändern sollte. Am Ende unserer Gespräche haben wir diese Formen wie folgt zugeordnet:

Benötigt einen Parameter:
(A): 658a (Quajutsu mit Freundschaftsakt) + 658b (Ash-Quajutsu) → gibt es bereits!
(B): 718c (50%-Zygarde mit Scharwandel) + 718d (10%-Zygarde mit Scharwandel)
(C): 744a (Wuffels mit Tempomacher)
(D): 6 weitere Parameter für die Meteorform von Meteno (vom nicht ersichtlichen farbigen Kern abhängig; wie diese Parameter dann genannt werden, ist noch nicht beschlossen – ob generell vor den Kernformen oder immer im Wechsel)
Benötigt keinen Parameter:
(E): 20 weitere Purmel-Parameter (je nach Form des Vivillon am Ende)
(F): 20 weitere Puponcho-Parameter (je nach Form des Vivillon am Ende)
(G): Zygarde-Kern und Zygarde-Zelle → sind momentan noch als Parameter vorhanden!
(H): Zweiter Parameter für G-Riffex aufgrund zugrunde liegender Form
(I): Weitere Parameter für G-Pokusan aufgrund zugrunde liegender Form
(J): Schatten-Mewtu (nur in Pokémon Tekken)
(K): Schatten-Dialga (nur in PMD)
(L): Lila Kecleon (nur in PMD)
(M): Herrscher-Pokémon, Crypto-Pokémon und Ähnliches
(N): Ukulelen-Pichu (nur in Ranger)
(O): Thu-Fi-Zer (nur im Manga)
(P): Volly (nur im Manga)
(Q): Kristall-Onix (nur im Anime)
(R): Kostümierte Pokémon aus Shuffle & GO (lediglich Kostüme)
(S): Rüstungs-Mewtu (zwar unterschiedliche Medien mit Anime & GO, aber aus unserer Sicht ein Kostüm)
Keine eindeutige Entscheidung:
(T): Klon-Pokémon (sowohl im Anime als auch in Pokémon GO vorhanden)
(U): Crypto-Lugia (zentrales Pokémon des Spiels)
Nachträglich hinzugefügt:
(V): Moterpel (besitzt spielintern je nach Form von Burmy eine von drei Formen)

Den Entscheidungen liegt zugrunde, dass wir im Vorfeld alle möglichen Formen unterschiedlichster Medien gesammelt haben, ganz unabhängig, ob sie denn auch in Spielen vorkommen. Danach haben wir geschaut, ob diese Formen auch in mehr als einem Medium vorkommen, um deren Wichtigkeit einschätzen zu können. Vorrang hatten hierbei jedoch stets in den Hauptspielen auftretende Formen, die nicht zwingend in einem weiteren Medium berücksichtigt werden mussten.

Wir haben versucht, eine gewisse Balance zu wahren und stellen euch hiermit vor, welche Parameter wir am ehesten hinzufügen würden. Damit dieser Beitrag nicht noch mehr ausufert, habe ich die Begründungen für einzelne Fälle kurz gehalten oder gar ganz weggelassen. Für Rückfragen und Anregungen sind wir jedoch stets offen; wollen aber auch zeitnah eine Umsetzung anstreben. Deshalb wäre es cool, die Sache kurz abzunicken oder Verbesserungsvorschläge zu machen.

Abstimmung

Aus diesem Grund schließe ich diesen Beitrag mit einer zweiwöchigen Abstimmung (Ende: 27. Juli 2020 um 23:59 Uhr), bei der ihr euch entweder an unserer Einschätzung orientieren oder bestimmte Einzelfälle anders einschätzen könnt. Wahlberechtigt sind bei dieser Wahl alle stimmberechtigten Benutzer! Am Ende der zwei Wochen wird jeder Parameter mit einer ⅔-Mehrheit hinzugefügt oder eben nicht. Somit haben wir dann endlich mal eine bindende Grundlage für diese Entscheidung!

Legende:

✔ → Es soll einen Parameter für diesen Fall geben.
✘ → Es soll keinen Parameter für diesen Fall geben.
— → Ich enthalte mich, ob es für diesen Fall einen Parameter geben soll.
Benutzer A B C D E F G H I J K L M N O P Q R S T U V
Taisuke
Ryuichi
SwowoJonny
Haijo18
BeyJim
Mooni000
Mecanno-man
Impoleon xy
GrollenKette951
DeXter


Kommentare

Ich habe bereits meine Stimmen für die einzelnen Fälle angegeben, sodass ihr euch an dem Muster orientieren bzw. die Zeile als Vorlage für eure Stimmen nutzen könnt. Und am Ende geht wie immer ein Ping an alle stimmberechtigten Benutzer, damit niemand sagen kann, er hätte von dieser Abstimmung nichts mitbekommen. :)

Grüße gehen raus an: Buoysel, Cliffichen, CLina, DeXter, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Mecanno-man, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny + AAWiki, BeyJim, BlauesSerpiroyal, Der Sternendiamantritter, Haijo18, Hydrokyu, Jass, Killuu, K0pplosio, Lasagne, Mario-WL, Mooni000, Nescientist, Pintauranimus, Pk-fan, PokéSpe, PokemontutorialTV, Vircaprae, Xatuhatu, Zeynex

Ich hoffe, nichts vergessen zu haben. ^_^ ~ Taisuke Diskussion 12:35, 13. Jul. 2020 (CEST)

Ich bin mir hier nicht vollständig im klaren darüber, für was für eine Änderung hier abgestimmt wird. Es ist meiner Meinung nach offensichtlich das einige Vorlagen einige dieser Sonderfälle irgendwie berücksichtigen müssen (z. B. Go-Sprites mit Hut) und andere nicht (irgendwelche Strategie-Sachen brauchen den ganzen Co-Kram garantiert nicht). Geht es hier einfach darum zu entscheiden, was die XXXa-Nummern etc. bekommt? Wenn ja, wie würden dann andere Sachen miteinbezogen, die nicht in dieses Schema passen? Wäre es evtl. eine Idee hierfür Schema wie XXXzz, XXXzy etc. zu nutzen, für non-Hauptspiel-Sachen? Oder hab ich hier völlig am Thema vorbeigeschossen und es geht um etwas anderes? --Datei:Sugimori 672.pngMecanno-manMäh 14:09, 13. Jul. 2020 (CEST)
PS: In der Liste fehlt Moterpel. Das hat spielintern auch drei Formen.
Danke für den Hinweis mit Moterpel, das habe ich als nun als weitere Option ergänzt. Da müsstet ihr Fünf (1, 2, 3, 4, 5) am besten nochmals schauen und eure Entscheidung diesbezüglich nachtragen. :)
Um aber auf deine eigentliche Frage zurückzukommen: In erster Linie sollte es hiermit eigentlich generell um neue Parameter gehen, die unserem bisherigen Schema folgen (XXXa), aber im Gegensatz zu den vorhandenen Formen (noch) nicht berücksichtigt werden. Die restlichen Punkte sind im Zuge dessen ins Auge gesprungen und haben für uns auch eine Erwähnung hier verdient, um zu schauen, ob wir solche Formen zukünftig auch berücksichtigen wollen. Momentan werden Spin-off-Sonderfälle wie die unzähligen Pikachu-Formen in Shuffle oder GO einfach als 025_X genutzt, sodass z. B. die Sprites-Vorlage auf diese zurückgreifen kann. Aber als eigenständige Parameter sind diese bislang nicht angelegt, da Vorlage:Namenr usw. mit diesem nie (?) genutzt werden würden. So ähnlich würde es doch vermutlich auch den anderen Spin-off-Sonderfällen gehen oder?
Falls das in der Art aber nicht mehr erwünscht wäre und wir dafür ein neues Parameter-Schema, wie von dir vorgeschlagen, nutzen wollen würden, wäre das für mich natürlich auch in Ordnung. ~ Taisuke Diskussion 14:20, 14. Jul. 2020 (CEST)
Danke für die Antwort; möchte hier noch kurz meine Stimmen erklären: Meiner Meinung nach macht es Sinn das aktuelle Schema nur für Hauptspiele + eventuell Go zu verwenden (wegen zukünftiger Home-Anbindung), da man nur bei diesen wirklich davon ausgehen kann das sie vorwärts getragen werden, irgendwie. Bei Formen die irgendwelche non-Unterschiede haben (Purmel, Moterpel etc.) macht es von mir aus gesehen weiter Sinn diese zu allokieren, damit nicht in Zukunft irgendwelche botgestüzte Programme beim durchgehen irgendeines Spiele-extracts durcheinander geraten. All zu viel Einfluss sollte das ja schlussendlich kaum haben, da diese Werte wahrscheinlich nirgends benutzt werden würden. Die anderen Spin-Off-Sachen (Shuffle, PMD, etc.) könnten in eine Art Nebenschema eingefügt werden, sei dies über 352zzz oder sowas wie 352lila, wobei letzteres wahrscheinlich sinnvoller wäre da so nicht ein Haufen kurioser Buchstabenketten entstehen - so können diese grundsätzlich auch über dieselben Vorlagen aufgerufen werden, wo nötig. Ich würde allerdings davon absehen Anime-, Manga und TCG-spezifische Sachen* aufzunehmen; selbst wenn man diese einfügt wüsste ich nicht wo man sie gescheit verwenden könnte. --Datei:Sugimori 672.pngMecanno-manMäh 15:59, 14. Jul. 2020 (CEST)
Als jemand, der sich mit diesem Thema noch nicht wirklich auseinandergesetzt hat, würde ich gerne wissen, was genau der Nutzen dieser zusätzlichen Parameter wäre, wenn die Sprites gleich sind. Ist es eine Absicherung für den Fall, dass z. B. irgendwann die Sprites von den Meteno-Meteorformen so geändert werden, dass man die Farbe des Kerns erkennen kann? Oder werden aktuell bzw. sollen irgendwann über Vorlagen zusätzliche Informationen anhand des eingestellten Form-Parameters dargestellt werden, z. B. die verfügbaren Fähigkeiten des Pokémon?
Eine Sache, die ich aber auf jeden Fall noch anmerken möchte, ist dass sowohl die Herrscher-Pokémon als auch die Pokémon in Herrscher-Größe (gegen erstere kämpft man in SM/USUM, letztere kann man in USUM erhalten) sich nicht nur durch ihre Darstellungsgröße unterscheiden, sondern zumindest laut Bulbapedia auch in den Werten Größe und Gewicht (ich weiß nicht, ob diese Werte im PokéWiki überhaupt irgendwo eingetragen sind, auf Bulbapedia stehen sie aber auf jeden Fall hier). Das erhöhte Gewicht dieser Pokémon in Herrscher-Größe hat sogar aufgrund von Attacken wie Rammboss oder Strauchler sogar Auswirkungen auf Kämpfe. Zudem haben diese Herrscher-Pokémon festgelegte Fähigkeiten. Auch wenn diese Formen bzw. Größen mit der 8. Generation wieder entfernt wurden, sind solche direkten spielerischen Unterschiede meiner Meinung nach ein besserer Grund für eigene Parameter als solche indirekten und ausschließlich optischen wie bei Meteno, zumindest wenn ich mit meinen Vermutungen bezüglich des Nutzens dieser Parameter einigermaßen richtig liege. -- Lasagne (Diskussion) 22:52, 14. Jul. 2020 (CEST)
Ich vermute mal, dass Mecanno-man mit den TCG-spezifischen Sachen sowas wie Koiking-gokku Pikachu und Poncho o Kita Eievui meint, oder vergesse ich hier noch mehr TCG-Sonderfälle, die ich kenne sollte? GrollenKette951 00:17, 15. Jul. 2020 (CEST)
Naja, Delta-Pokémon könnte man diskutieren, aber die Kostüme war schon eher das was ich gemeint hab. Plus all die anderen sinnlosen, also iwie das einkaufende, das Fussballspielende etc. --Datei:Sugimori 672.pngMecanno-manMäh 01:12, 15. Jul. 2020 (CEST)