PokéWiki:Chattreffen: Unterschied zwischen den Versionen
K (RS) |
KKeine Bearbeitungszusammenfassung |
||
| Zeile 12: | Zeile 12: | ||
break=no | break=no | ||
</inputbox>Vorhandene Archivierung: [[PokéWiki:Chattreffen/Archiv|Archiv]]<br /> | </inputbox>Vorhandene Archivierung: [[PokéWiki:Chattreffen/Archiv|Archiv]]<br /> | ||
- zuletzt archiviert von [[Benutzer:Ryuichi|<span style="font-family:Segoe Script;color:#397257;text-shadow:0 0 5px#397257,0 0 10px#397257;font-size:150%">* Ryuichi</span>]] ~ [[Datei:Sugimori_004.png|20px|link=]]<sup>'''[[Pokéwiki:Orte-Projekt|<span style="color:#00cc4f>PL</span>]]'''</sup> ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch [[Benutzer Diskussion:Ryuichi|<sup>Diskussion</sup>]] | - zuletzt archiviert von [[Benutzer:Ryuichi|<span style="font-family:Segoe Script;color:#397257;text-shadow:0 0 5px#397257,0 0 10px#397257;font-size:150%">* Ryuichi</span>]] ~ [[Datei:Sugimori_004.png|20px|link=]]<sup>'''[[Pokéwiki:Orte-Projekt|<span style="color:#00cc4f>PL</span>]]'''</sup> ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch [[Benutzer Diskussion:Ryuichi|<sup>Diskussion</sup>]] 14:35, 7. Mär. 2021 (CET) | ||
|}{{clear}} | |}{{clear}} | ||
== Protokoll vom | == Protokoll vom 06.03.2021 == | ||
=== Helferlein und Visual Editor === | === Helferlein und Visual Editor === | ||
Helferlein blieben in der Diskussion außen vor. Hier gab es keine Beanstandung. Beim Visual Editor (VE) zeigt sich durch die Änderungsmarkierung in den LÄ das gerade sehr viele Neue/Unerfahrene User den Editor nutzen. Er scheint eine gute Möglichkeit die Start-Hemmschwelle und Quelltextüberforderung für Neulinge zu minimieren. Für die Anlockung Mehr neuer Nutzer durch einfachere Editierung scheint der VE keine Verbesserung zu erzielen. Ist Zitat Robbi „mehr son "nice to have", um den Einstieg etwas zu erleichtern“. In der Nutzung zeigt sich das der VE teils eine sehr lange Ladezeit hat und ab und an seltsame Dinge verusacht.<sup>[https://www.pokewiki.de/index.php?title=Events/8._Generation/Europa&curid=256186&diff=2127569&oldid=2127458 [1]][https://www.pokewiki.de/index.php?title=Arenaleiter&diff=prev&oldid=2127045 [2]][https://www.pokewiki.de/?diff=2110238 [3]]</sup> | |||
Vor allem an Vorlagen, die nicht der standard-Formatierung folgen, macht der VE Probleme. [[Benutzer:RobbiRobb|Robbi]] hat dazu eine Erläuterung bei [https://www.mediawiki.org/wiki/Help:TemplateData#Custom_formats Mediawiki] gefunden mit der das ganze entsprechend angepasst werden kann, das würde großflächige Änderungen erfordern. Für die weitere Nutzung des VE ist für uns wichtig die oben aufgezeigten Fehler OBJ uws. zu beseitigen. [[Benutzer:Buoysel|Buo]] wird bei den anderen EP abklären ob diese ebenfalls derartige Fehler haben und wie Sie diese ggf. bereits behoben haben. Weitere Fehler die nicht oben gelinkt sind sollen an Buo geschickt werden damit er das soweit möglich beheben kann. | |||
= | |||
=== | |||
=== | |||
=== | === Zentrale Hinterlegung von Trainerdaten === | ||
Die Extension als solches ist praktisch. Es zeigt sich allerdings das die Nutzung für Trainerdaten derzeit noch nicht gegeben ist. Hauptproblematik liegt in der Verwendung von Toggle innerhalb der Zeilen-Vorlage. Es müssen sämtliche Toggle bei der "Einbindungsseite" entfernt werden. Dies wäre für [[Benutzerin:Cliffichen|Cliffi]] in Ordnung solange es keinen Datenverlust gibt. Wann dies durchgeführt werden soll ist derzeit unklar. Es wurde entschieden den Punkt auf der AD erst einmal offen zu lassen. Hauptpriorität liegt momentan auf der Mobilen-Nutzung der Trainer-Vorlagen. | |||
=== | === Erweiterung der Typen-Artikel === | ||
Zitat [[Benutzer:Taisuke|Tai]] Dieser Punkt ist noch offen, braucht aber nicht beim Chattreffen erneut thematisiert werden. | |||
[[Benutzer: | |||
=== Welche Formwechsel sollen wie im Abschnitt Entwicklung dargestellt werden? === | |||
Die Damals Entwickelte [[Benutzer:Ryuichi/EvoListe|Vorlage]] war in einigen Details noch nicht Go Life, es zeigt sich allerdings aufgrund der geplanten Änderungen für eine Mobile Darstellung das diese Form nicht taugt und neu überdacht werden muss. [[Benutzer:Ryuichi|Ryu]] wird sich dazu einmal Gedanken machen ob man hier mit GridBoxen ggf. umswitchen kann von Horizontal auf Vertikal oder es ein völlig neues Konzept zur Darstellung der inzwischen Teils umfangreichen Entwicklungen und Formwechsel wie am Beispiel Pikachu zu sehen ist braucht. | |||
[[Benutzer:Ryuichi| | |||
=== | === Darstellung Zuchteltern === | ||
[[Benutzer:DeXter|DeXter]] stellt per Stream seine im Aufbau befindliche Spezialseite zu Zuchteltern vor. Allgemein fand die Darstellung großen Anklang. DeXter zeigt am Beispiel Pikachu und Ausdauer auch die Probleme für welche er noch an einer Lösung arbeitet. Die Ausgabe kann in zwei Betrachtungen Locker oder Streng vorgenommen werden. Es ist gewünscht das dies direkt vom User gewählt werden kann. Auch haben sich Punkte ergeben die ebenfalls noch zur Klären oder vorab zu erledigen sind. Die Entwicklung erfolgt momentan nur durch DeXter, bei einer Implementation ins Wiki muss gewährleistet sein das dies Zukunftsfähig ist. Updates müssen auch durch andere Erfahrene User oder Buo eingefügt werden können. Dies benötigt eine Ausführliche Dokumentation. DeXter schlägt vor den Quellcode über GitHub zugänglich zu machen so das jeder mit Zugang und Kenntnissen Ihn Updaten könnte und Buo lediglich das Update einspeisen müsste. An Beispiel von Pikachu zeigt sich eine längere Ladezeit. Hier wurde sich gewünscht dem User in welcher Form auch immer anzuzeigen das, dass System rechnet. Buo fragt ob man die Ergebnisse ggf. auch leicht cachen könnte, damit es nicht jedesmal länger dauert. Ein Vorschlag war ggf. über PHP, vielleicht mit serialize und unserialize. Damit kann man fertige Arrays oder Objekte wegspeichern und wieder laden. DeXter wird durch Grundfunktion und Dokumentation weiter aufbereiten und nachfolgend die technische Implementation und Ladezeitoptimierung mit Buo vor dem Go Life abklären. Eine Dauer ist derzeit noch nicht abschätzbar. | |||
=== | === Definitionsklarheit: Rivalen === | ||
Im letzten Masters-Update fand eine Definition der Integrierten Rivalen statt nun ist offiziell bestätigt wer davon Rivale ist, und da sind es Bell als auch Gladio und auch N der bisher überhaupt nicht als Rivale gewertet wurde. Es wurde sich darauf geeinigt die Masters-Definition für Rivalen zu übernehmen. | |||
=== | === Anführer der legendären Gruppen === | ||
Wir sind uns einig das eine Diskussion den Rahmen einen Chattreffen sprengen würde. Es ist vieles Historisch gewachsen und es gibt keine Einheitliche Definition. Die Vorlage selbst definiert Gruppen ohne Ihrer "höhergestellten" Anführer. Höhergestellt wäre z.B. Lugia bei den Vögeln oder Regigigas da er Lt Forschungsauftrag aus dem Schwer/Schild Pass kein Bestandteil der Legendären Giganten ist. Bei anderen Gruppen wie den Wetterlegenden oder oder dem Auren-Trio gibt es keinen direkten Übergestellten Anführer sondern meistens eine A- und B-Seite die über ein drittes Pokémon aufgrund diverser Eigenschaften miteinander verknüpft sind wie z.B. Fähigkeiten die das Wetter beeinflussen oder Auren-spezifische Fähigkeiten. Eine Übersicht warum wir wie bei jeder einzelnen Gruppe entschieden haben scheint von Lesern erwünscht. Wie diese Übersicht gestaltet werden kann ohne das jede Gruppe in Frage gestellt wird ist nooch unklar. Falls sich jemand bereit erklärt für einen derartigen Text dann gerne übernehmen. | |||
==== | === Allgemeine Diskussionsseite === | ||
Diskussionen auf Ad wurden wie folgt besprochen: | |||
* Gestaltung der Stellenanzeigen/Ausschreibungen → siehe Chattreffen Protokoll vom 06.03.2021 | |||
* Typenicons und wie wir entscheiden, welche wir nutzen. → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
* Die DLCs → siehe Chattreffen Protokoll vom 06.03.2021 | |||
* Zentrale Hinterlegung von Trainerdaten → siehe Chattreffen Protokoll vom 06.03.2021 | |||
* Sind weitere Pokémon-Formen als Parameter notwendig? → ✘ Benötigt scheinbar weitere Diskussion und wurde nicht archiviert. | |||
* Typen-Icons → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
* Umgestaltung der Rechtesruktur → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
* Trivia: Bezüge aus der realen Welt → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
* Umfragen auf der Hauptseite → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
* sīc erat scriptum → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
* Vorstellung: Pokémon-Zuchtrechner → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
* Event-Screenshots der Schwert und Schild-Spiele → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
* Animeexklusive Pokémonformen und Varianten → ✔ Benötigt keine weitere Diskussion und wurde archiviert. | |||
=== | === Strategie-Projekt === | ||
Es wurde angemerkt das mehrere hundert Artikel noch kein Patroll hatten. Durch die beiden DLCs musste das, was im Juni aktuell war, zweimal beinahe vollständig aktualisiert werden. Es gibt solche massiven Änderungen teilweise heute noch, weshalb viele Änderungen einfach noch nicht seitens der PL abgesegnt werden konnten, bis sich die große Änderungswelle gelegt hat. Das Smogon Format ist halt das Format, was in der Regel am beliebtesten ist, weil es sich an 6vs6 Kämpfen orientiert, während sich die "Nintendo-Formate" an 3vs3 bzw. 4vs4 orientieren und sich mittlerweile auch im dreimonatigen Takt vollständig verändern. Es ist allen klar das eine Konkurrierung mit Smogon nicht zeitgemäß ist. Den Zug haben wir vor langer Zeit verpasst. Die Frage ist wie können wir einen Wikigerechten Dokumentarischen zweck erfüllen und auch gleichzeitig Neulingen Strategieformen näher bringen. Fortgeschrittene CP-Spieler verirren sich nur selten ins Wiki für Strategie bzw. Unterstützen deren Ausbau nicht bzw. nicht ausreichend. Es gibt die Überlegung die ganzen Tier-basierten Strategien zu entfernen da sie rein inoffiziell sind. Stattdessen soll versucht werden, Tier-unabhängige Strategien zu schreiben, die „weniger Pflege“ brauchen und somit nicht allzu stark unter einem Mangel an aktiven Schreibern leiden. Der Aufbau von allgemeinen Übersichten ist nach Erläuterung von Luca nicht zielführend da die meisten sich eher fragen: "wie kann ich mein [Pokémonname] spielen?", anstelle nach bestimmten Rollen für ihr Team Ausschau zu halten. Luca manifestiert dies am Beispiel Glurak und Quappo: „Wenn wir beim Beispiel Glurak bleiben, würde zu Glurak vermutlich zu einer Übersichtsseite für offensive Pokémon führen. Dort würde dann stehen, dass möglichst starke Attacken gewählt werden sollen, die zum höheren Angriffswert passen. Daraus würde dann beispielsweise das Moveset Feuersturm, Orkan, Fokusstoß, Drachenpuls resultieren. In der Realität spielt man aber fast immer Ruheort auf Glurak, man kann aber nicht allgemein sagen, dass man es bei jedem Pokémon empfehlen kann, eine Selbstheilungsattacke zu verwenden. Auch Erdbeben ist eine solide Option für Glurak, die aber wegen des niedrigeren Angriffswertes in einer allgemeinen Empfehlungen nicht genannt werden kann, da eben nicht jedes Pokémon mit einer so großen Differenz zwischen beiden Angriffswerten Attacken beider Schadensklassen anwenden kann. | |||
Glurak folgt den allgemeinen Richtlinien aber noch recht genau. Mir fällt als Extrembeispiel Quappo ein, das in Generation 7 ausschließlich speziell gespielt wurde, obwohl sein Angriff um 25 Basispunkte höher war. Solche Fälle lassen sich nicht allgemein angeben, da sie immer aus ganz speziellen Gründen entstehen. | |||
Deswegen wäre meine aktuelle Tendenz eher, auf Glurak/Strategie beispielsweise ein Moveset aus Feuersturm/Orkan/Fokusstoß/Ruheort anzugeben. Das wäre relativ universell und auch in einem Jahr noch eine mögliches Moveset. Nach aktuellen Richtlinien würde ein neu angelegtes Glurak-Set aktuell aus Flammenwurf/Ruheort/Auflockern/Toxin bestehen, was zwar das aktuell beste Set in seinem Tier ist, aber in 2 Monaten wieder vollkommen nutzlos sein kann. Das andere Moveset ist hingegen wohl nie die optimale Spielweise, aber halt auch nie nutzlos“. Es wurde sich darauf geeinigt das Luca sich hierzu Gedanken macht und ein mögliches Konzept auf der Projekt-Diskussionsseite online stellt. | |||
=== | === Planung von Events / Auswertung VBW / Die Sinnoh-Initiative === | ||
Mögliche Upcoming Events sind Ostern, Halloween, Weihnachten, VBWs Initiativen: | |||
Es wurde sich darüber Gedanken gemacht wie wir die Community der aktiven Schreiber, der Leser in Form von Events, Initiativen oder VBW ansprechen können. Buo merkt klar an das er keine "verramschung" von Events will. Events sollen Belohnend für Teilnehmer ausfallen. Ein Möglichkeit ist hier eine materielle Bepreisung. Eine Bepreisung ist immer auf die aktuelle Lage anzuwenden. Dies zeigt sich auch in der letzten VBW. Diese wurde kurzfristig aufgrund der Pandemie-Situation online gestellt. Der Gedanke war das mehr zu Hause sind und es daher der beste Zeitpunkt dafür wäre. Die Realität hat hier jedoch das Gegenteil gezeigt. Viele mussten sich auf veränderte Private Umstände Home-Schooling usw. einstellen was zu einer geringen Beteiligung führte. Auch waren die in der schnelle Ausgewählten Preise in Form von Schwert/Schild (ohne DLC) in der Zeit des DLC -Releases eher veraltet und suboptimal gewählt. Es wurde sich geeinigt das bei Events 2021 Preise in Form der kommenden Spielreleases (<small>{{sk|NSNP|SD|LP|PLA}}</small>), Merch rund um 25 Jahre Pokémon, falls Verfügbar aktuelles TCG oder Merch aus Japan der hier i.d.R. nicht zu bekommen ist genutzt werden soll. Ein derartiges vorgehen wird auch für die kommenden Jahre bevorzugt. Wichtig ist Ideen für Events frühzeitig #intern und bei materieller Bepreisung mit Buo abzuklären. Buo gibt klar zu verstehen das er gerne auch Preise für Aktionen die nicht auf User-Neugewinnung sondern lediglich Ausbau/Erneuerung diverser Wikidinge durch erfahrene User ausgelegt sind zur Verfügung stellt. | |||
=== | === Gestaltung der Stellenanzeigen/Ausschreibungen === | ||
Der Status Quo wurde besprochen. Es fehlt lediglich Bilder einzelner Projekte und einige Aufgaben. An sonsten steht die Basis. DeXter wird zeitnah Projektleiter anschreiben wo noch Sachen fehlen. Abgabefrist ist der 14.03.2021. Nachfolgend wird es DeXter ins LiveWiki einbauen. Sollte er es aufgrund privater Umstände DeXter zeitlich nicht ermöglichen können wird die Einbindung seitens der Admins übernommen. | |||
=== | === PokéWiki Diskussion:Spiele-Projekt#Freundschaft, Zutrauen und Zutraulichkeit === | ||
Zu vielen Änderungen mit der Einführung Gen8 fehlen uns Spielinterne Daten. Solange ist eine größere Erweiterung bzw. Vertiefung des bisherigen Artikels nicht möglich. Für die Implementation in die Pokédex-Artikel hat sich Tai überlegt einen separaten Abschnitt mit der Auflistung von Veränderungen über die Generation einzufügen. Einen Namen für den Abschnitt hat er noch nicht. Es wurde sich überlegt ggf. eine Ideenfindung über die Projekt-Diskussionsseite oder den Discord-Projekt-Channel anzuregen. Nach Implementation des Abschnittes werden sämtliche ältere Daten aus der Infobox entfernt und nur noch die Aktuellen angezeigt. | |||
=== | === Spielkürzel === | ||
Es wurde sich darauf geeinigt die Spielkürzel für Park der Freunde (Bestandteil DPPT) und PokéWalker (Bestandteil HGSS) zu entfernen und vorhandenes in die zugehörigen Spiele zu integrieren. PokéMove wird vorrangig im Benutzernamensraum genutzt behandelt allerdings ein eigenständiges Spiel. Es wurde dessen verbleib entschieden. Die Nutzung der Schwert/Schild DLC sks wurde besprochen. Die speraten sks für Die Insel der Rüstung und für Die Schneelande der Krone sind in Summe unter 50. Aufgrund der Einbindungszahlen gegenüber den sks mit EX-suffix wurde sich entschieden SWR, SWK, SHR und SHK zu löschen. Für die kommenden Spiele [[Pokémon Strahlender Diamant und Leuchtende Perle]] wurde sich für die sk {{sk|SD}} und {{sk|LP}} entschieden und für [[Pokémon-Legenden: Arceus]] das sk {{sk|PLA}} welche bereits von Robbi hinzugefügt wurden. | |||
=== | === VB-Wahlen === | ||
Es | Es wurde die Grundthematik Wiki und Verpflichtung besprochen. Fakt ist das eine Pflicht nicht ohne Sanktion eingefügt werden kann. Gerade in höheren Ebenen sind wir allerdings auf jede Hand angewiesen. Es wurde sich darauf geeinigt das die derzeitige Formulierung "Der Vorschlag gilt als autorisiert, wenn ⅔ der Administratoren (Bürokraten nur einberechnet, wenn sie ihre Stimme abgeben) und Redakteure ihn unterstützen. Die erste Wahlrunde läuft so lange, bis ein Ergebnis vorliegt." den Spielraum frei gibt das User nur Verpflichtet sind abzustimmen solange eine ⅔-Mehrheit noch nicht erreicht ist oder bereits >⅓ Contra gestimmt hat. Solange nicht die überwiegende Mehrheit der Abstimmungen ignoriert wird. Jedem User der zur VB-Wahl gestellt wird, wird der Posten eines Projektleiters grundsätzlich zugetraut. Eine separate Kennzeichnung ist nicht notwendig. Der Wunsch jemanden als PL haben zu wollen kann in der Stimmbegründung vermerkt werden. Teilnahmeberechtigt sind User in der ersten Wahlrunde User die während gesamten ersten Wahlrunde den Status eines Admins oder Redakteurs inne haben. In der zweiten Wahlrunde sind alle Verlässlichen Benutzer zugelassen die bei Start mindestens den Rang VB besitzen und Ihn bei regulärem Wahlende noch inne haben | ||
=== Wertschätzung === | |||
Im Zuge der Diskussion zur Umgestaltung der Rechtestruktur gab es zwischen vielen Ebenen und Usern Konflikte. Diese konnten zwischenzeitlich beräumt werden und ein besserer offene Umgang bei diversen Themen beschlossen. Weiter wurde beschlossen das [[Benutzer:Mecanno-man|Mec]] die Neueinbringung solcher Vorschläge dauerhaft untersagt wird {{smiley|grin}} ''→ Anmerkung: Mec weiß aus persönlichen Gesprächen wie diese Aussage im Detail gemeint ist und das sie keinen Angriff auf Ihn darstellt.'' Es wurden allgemeine Zustände im Rollbackverhalten, Nutzung der Danke-Funktion, Emoji-Verwendung, Umgangston widergespiegelt. Der Allgemeine Konsens ist hier das ein jeder von uns eine stärkere Selbstreflektion durchführen sollte. Statt immer wieder kommentarlosen Rollbacks sollte lieber zurücksetzen mit Kommentar durchgeführt werden (Vandalismus ausgenommen). Auch wenn es vielleicht der fünfte neue Benutzer auf Discord oder im Wiki ist der an dem Tag den selben Fehler macht dann gilt ein respektvoller Umgang und erst der Neutrale Hinweis des Falschverhaltens oder aufzeigen des "Fehler" im Wiki. Jemand der Unbelehrbar ist oder dessen Verhalten klar vandalierend/mutwillig ist. Beispielsweise Schädliche Edits die Sogar zum Schutz der Allgemeinheit versteckt werden müssen. User die auf Discord kommen und direkt Verboten Symbole posten usw.. Bei diesen Usern darf ruhig direkt dann der Bannhammer geschwungen werden. Sachen die Unklar sind wie div. Bilder/Statuseinträge gehören immer erst im Mod/Intern-Bereich abgeklärt werden oder Mann kann denjenigen auch direkt fragen, was das Emoji (bedeuten) soll, dies kann man ja mal laut Empfehlung Buo versuchen. Dann merkt derjenige vielleicht, dass das nicht abgebracht war. Und der Angegriffene fühlt sich ggf. verteidigt und nicht in die Ecke gestellt. Durch Selbstreflektion wollen wir weg kommen von entnervten Eindrücken außenstehender oder dem vergraulen potenzieller User. Eine der Kernfragen ist dabei „Wie kann man es besser machen?“ Es wurden in diesem Zuge Beispiele genannt für die Nutzung der Danke-Funktion, Nutzung der Diskussionsseite unter dem Gesichtspunkt der Unterstützung. Bsp. ''Du hast die Vorschau nicht wie angezeigt genutzt. Gibt es Probleme bei der Nutzung. Kann man dir helfen? Der Hinweis hat diesen und jenen Grund. Also wenn Fragen stell sie gerne.'' Die Idee der Unterstützung der Wertschätzung durch Einführung immer wieder neuer Babel für Qualität usw. wurde verworfen. Kernproblematik ist die oftmals fehlende Hineinversetzung in andere/neue User. Was auch für erfahrene Benutzer ein stätiger Lernprozess werden und bleiben muss. Es wurde sich darauf geeinigt das alles was uns Einfällt um die Situation der Wertschätzung zu verbessern gesagt wurde. Es wurde sich darauf geeinigt einen neuen Punkt zur Wertschätzung auf der AD zu eröffnen nach dem Motto was können wir verbessern, wo seht ihr Probleme mit aktiven Ping auch über Discord an die SBs. DeXter wird entsprechendes vorbereiten. | |||
=== | === Mobiles Design === | ||
Buo gab eine Auswertung der zehn häufigsten Auflösungen (1920x1080, 414x896, 375x812, 375x667, 360x780, 360x640, 412x915, 412x869, 360x740, 1536x864). Auf dieser Grundlage und vielen Mindestanforderungen wurde sich darauf geeinigt das wir als Mindestbreite 320px Nutzen. Alles darunter wird zukünftig von Vorlagen nicht berücksichtigt werden können. Für die Mobile Ansicht wurde sich auf ein Spektrum von 320px bis 480px geeinigt. Bei diesem sollen Infoboxen über die komplette Breite gehen und Inhalte darunter erfolgen. Weiter wurde sich darauf geeinigt keinen Mischmasch zu betreiben. Die Größenorientierung gilt Projektübergreifend. Buo stellt einige Tests und Optimierungen (sowohl Grafisch als auch rechtlich) für das Wiki vor. Diese Test zeigen adaptiertes Aussehen für Mobile Darstellung mit wechselnder Anpassung bei 850, 1080 und 1450. Buo prüft die Möglichkeit der Anpassung auf 750 was vermutlich eher auf 768 hinauslaufen wird. Die Tests wurde besprochen und diverse Optimierungen festgelegt welche Buo umsetzt. Für ein Mobiles Design sind auch Änderungen an der Topbar notwendig. Die Notwendigen Änderungen sind nicht überall auf Anklang gestoßen. Es wurde sich darauf geeinigt hier Funktionen zu implementieren die von User CSS/js angesteuert werden können. Damit sich jeder selbst seine Topbar gestalten kann. Die Reorganisation diverser bisheriger Einblendungen muss geprüft und mit Tests abgeklärt werden. Es wurden Lösungsansätze für Aufzählungsvorlagen (Navigationsleisten usw.) die auf volle Breite mit <nowiki><br /></nowiki> ausgelegt sind besprochen. Es soll geprüft werden inwieweit wir in diesen auf Trennungszeichen wie • und fixe breaks verzichten können und stattdessen einen fixen Abstand von z.B. 3px zwischen den Aufzählungen verwenden um einen sauberen Umbruch je nach Seitenbreite zu erzeugen. Die Orte Trainer Vorlage könnte neu Strukturiert mittels GridBoxen angepasst werden. Ryu lernt noch Blumen und Unkraut zu gießen. Andere Vorlagen wie Orte/Unterschied oder die Ursprünglich geplante Entwicklungsvorlage würden in Ihrer jetzigen Basis einen Massiv komplexen Umbau benötigen wo der Punkt offen ist Sie nicht durch andere Konzepte zu ersetzen. Sämtliche Details zum Mobilen Design und Status der Anpassung bleibt bis auf weiteres auf interner Ebene bis die Anpassungen repräsentativ und fehlerfrei für die Masse sind. | |||
Version vom 7. März 2021, 15:35 Uhr
| Chattreffen
Zweck dieser Seite ist es, die Inhalte des Chattreffen im Wiki zu dokumentieren |
Vorhandene Archivierung: Archiv - zuletzt archiviert von * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 14:35, 7. Mär. 2021 (CET) |
Protokoll vom 06.03.2021
Helferlein und Visual Editor
Helferlein blieben in der Diskussion außen vor. Hier gab es keine Beanstandung. Beim Visual Editor (VE) zeigt sich durch die Änderungsmarkierung in den LÄ das gerade sehr viele Neue/Unerfahrene User den Editor nutzen. Er scheint eine gute Möglichkeit die Start-Hemmschwelle und Quelltextüberforderung für Neulinge zu minimieren. Für die Anlockung Mehr neuer Nutzer durch einfachere Editierung scheint der VE keine Verbesserung zu erzielen. Ist Zitat Robbi „mehr son "nice to have", um den Einstieg etwas zu erleichtern“. In der Nutzung zeigt sich das der VE teils eine sehr lange Ladezeit hat und ab und an seltsame Dinge verusacht.[1][2][3] Vor allem an Vorlagen, die nicht der standard-Formatierung folgen, macht der VE Probleme. Robbi hat dazu eine Erläuterung bei Mediawiki gefunden mit der das ganze entsprechend angepasst werden kann, das würde großflächige Änderungen erfordern. Für die weitere Nutzung des VE ist für uns wichtig die oben aufgezeigten Fehler OBJ uws. zu beseitigen. Buo wird bei den anderen EP abklären ob diese ebenfalls derartige Fehler haben und wie Sie diese ggf. bereits behoben haben. Weitere Fehler die nicht oben gelinkt sind sollen an Buo geschickt werden damit er das soweit möglich beheben kann.
Zentrale Hinterlegung von Trainerdaten
Die Extension als solches ist praktisch. Es zeigt sich allerdings das die Nutzung für Trainerdaten derzeit noch nicht gegeben ist. Hauptproblematik liegt in der Verwendung von Toggle innerhalb der Zeilen-Vorlage. Es müssen sämtliche Toggle bei der "Einbindungsseite" entfernt werden. Dies wäre für Cliffi in Ordnung solange es keinen Datenverlust gibt. Wann dies durchgeführt werden soll ist derzeit unklar. Es wurde entschieden den Punkt auf der AD erst einmal offen zu lassen. Hauptpriorität liegt momentan auf der Mobilen-Nutzung der Trainer-Vorlagen.
Erweiterung der Typen-Artikel
Zitat Tai Dieser Punkt ist noch offen, braucht aber nicht beim Chattreffen erneut thematisiert werden.
Welche Formwechsel sollen wie im Abschnitt Entwicklung dargestellt werden?
Die Damals Entwickelte Vorlage war in einigen Details noch nicht Go Life, es zeigt sich allerdings aufgrund der geplanten Änderungen für eine Mobile Darstellung das diese Form nicht taugt und neu überdacht werden muss. Ryu wird sich dazu einmal Gedanken machen ob man hier mit GridBoxen ggf. umswitchen kann von Horizontal auf Vertikal oder es ein völlig neues Konzept zur Darstellung der inzwischen Teils umfangreichen Entwicklungen und Formwechsel wie am Beispiel Pikachu zu sehen ist braucht.
Darstellung Zuchteltern
DeXter stellt per Stream seine im Aufbau befindliche Spezialseite zu Zuchteltern vor. Allgemein fand die Darstellung großen Anklang. DeXter zeigt am Beispiel Pikachu und Ausdauer auch die Probleme für welche er noch an einer Lösung arbeitet. Die Ausgabe kann in zwei Betrachtungen Locker oder Streng vorgenommen werden. Es ist gewünscht das dies direkt vom User gewählt werden kann. Auch haben sich Punkte ergeben die ebenfalls noch zur Klären oder vorab zu erledigen sind. Die Entwicklung erfolgt momentan nur durch DeXter, bei einer Implementation ins Wiki muss gewährleistet sein das dies Zukunftsfähig ist. Updates müssen auch durch andere Erfahrene User oder Buo eingefügt werden können. Dies benötigt eine Ausführliche Dokumentation. DeXter schlägt vor den Quellcode über GitHub zugänglich zu machen so das jeder mit Zugang und Kenntnissen Ihn Updaten könnte und Buo lediglich das Update einspeisen müsste. An Beispiel von Pikachu zeigt sich eine längere Ladezeit. Hier wurde sich gewünscht dem User in welcher Form auch immer anzuzeigen das, dass System rechnet. Buo fragt ob man die Ergebnisse ggf. auch leicht cachen könnte, damit es nicht jedesmal länger dauert. Ein Vorschlag war ggf. über PHP, vielleicht mit serialize und unserialize. Damit kann man fertige Arrays oder Objekte wegspeichern und wieder laden. DeXter wird durch Grundfunktion und Dokumentation weiter aufbereiten und nachfolgend die technische Implementation und Ladezeitoptimierung mit Buo vor dem Go Life abklären. Eine Dauer ist derzeit noch nicht abschätzbar.
Definitionsklarheit: Rivalen
Im letzten Masters-Update fand eine Definition der Integrierten Rivalen statt nun ist offiziell bestätigt wer davon Rivale ist, und da sind es Bell als auch Gladio und auch N der bisher überhaupt nicht als Rivale gewertet wurde. Es wurde sich darauf geeinigt die Masters-Definition für Rivalen zu übernehmen.
Anführer der legendären Gruppen
Wir sind uns einig das eine Diskussion den Rahmen einen Chattreffen sprengen würde. Es ist vieles Historisch gewachsen und es gibt keine Einheitliche Definition. Die Vorlage selbst definiert Gruppen ohne Ihrer "höhergestellten" Anführer. Höhergestellt wäre z.B. Lugia bei den Vögeln oder Regigigas da er Lt Forschungsauftrag aus dem Schwer/Schild Pass kein Bestandteil der Legendären Giganten ist. Bei anderen Gruppen wie den Wetterlegenden oder oder dem Auren-Trio gibt es keinen direkten Übergestellten Anführer sondern meistens eine A- und B-Seite die über ein drittes Pokémon aufgrund diverser Eigenschaften miteinander verknüpft sind wie z.B. Fähigkeiten die das Wetter beeinflussen oder Auren-spezifische Fähigkeiten. Eine Übersicht warum wir wie bei jeder einzelnen Gruppe entschieden haben scheint von Lesern erwünscht. Wie diese Übersicht gestaltet werden kann ohne das jede Gruppe in Frage gestellt wird ist nooch unklar. Falls sich jemand bereit erklärt für einen derartigen Text dann gerne übernehmen.
Allgemeine Diskussionsseite
Diskussionen auf Ad wurden wie folgt besprochen:
- Gestaltung der Stellenanzeigen/Ausschreibungen → siehe Chattreffen Protokoll vom 06.03.2021
- Typenicons und wie wir entscheiden, welche wir nutzen. → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
- Die DLCs → siehe Chattreffen Protokoll vom 06.03.2021
- Zentrale Hinterlegung von Trainerdaten → siehe Chattreffen Protokoll vom 06.03.2021
- Sind weitere Pokémon-Formen als Parameter notwendig? → ✘ Benötigt scheinbar weitere Diskussion und wurde nicht archiviert.
- Typen-Icons → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
- Umgestaltung der Rechtesruktur → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
- Trivia: Bezüge aus der realen Welt → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
- Umfragen auf der Hauptseite → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
- sīc erat scriptum → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
- Vorstellung: Pokémon-Zuchtrechner → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
- Event-Screenshots der Schwert und Schild-Spiele → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
- Animeexklusive Pokémonformen und Varianten → ✔ Benötigt keine weitere Diskussion und wurde archiviert.
Strategie-Projekt
Es wurde angemerkt das mehrere hundert Artikel noch kein Patroll hatten. Durch die beiden DLCs musste das, was im Juni aktuell war, zweimal beinahe vollständig aktualisiert werden. Es gibt solche massiven Änderungen teilweise heute noch, weshalb viele Änderungen einfach noch nicht seitens der PL abgesegnt werden konnten, bis sich die große Änderungswelle gelegt hat. Das Smogon Format ist halt das Format, was in der Regel am beliebtesten ist, weil es sich an 6vs6 Kämpfen orientiert, während sich die "Nintendo-Formate" an 3vs3 bzw. 4vs4 orientieren und sich mittlerweile auch im dreimonatigen Takt vollständig verändern. Es ist allen klar das eine Konkurrierung mit Smogon nicht zeitgemäß ist. Den Zug haben wir vor langer Zeit verpasst. Die Frage ist wie können wir einen Wikigerechten Dokumentarischen zweck erfüllen und auch gleichzeitig Neulingen Strategieformen näher bringen. Fortgeschrittene CP-Spieler verirren sich nur selten ins Wiki für Strategie bzw. Unterstützen deren Ausbau nicht bzw. nicht ausreichend. Es gibt die Überlegung die ganzen Tier-basierten Strategien zu entfernen da sie rein inoffiziell sind. Stattdessen soll versucht werden, Tier-unabhängige Strategien zu schreiben, die „weniger Pflege“ brauchen und somit nicht allzu stark unter einem Mangel an aktiven Schreibern leiden. Der Aufbau von allgemeinen Übersichten ist nach Erläuterung von Luca nicht zielführend da die meisten sich eher fragen: "wie kann ich mein [Pokémonname] spielen?", anstelle nach bestimmten Rollen für ihr Team Ausschau zu halten. Luca manifestiert dies am Beispiel Glurak und Quappo: „Wenn wir beim Beispiel Glurak bleiben, würde zu Glurak vermutlich zu einer Übersichtsseite für offensive Pokémon führen. Dort würde dann stehen, dass möglichst starke Attacken gewählt werden sollen, die zum höheren Angriffswert passen. Daraus würde dann beispielsweise das Moveset Feuersturm, Orkan, Fokusstoß, Drachenpuls resultieren. In der Realität spielt man aber fast immer Ruheort auf Glurak, man kann aber nicht allgemein sagen, dass man es bei jedem Pokémon empfehlen kann, eine Selbstheilungsattacke zu verwenden. Auch Erdbeben ist eine solide Option für Glurak, die aber wegen des niedrigeren Angriffswertes in einer allgemeinen Empfehlungen nicht genannt werden kann, da eben nicht jedes Pokémon mit einer so großen Differenz zwischen beiden Angriffswerten Attacken beider Schadensklassen anwenden kann. Glurak folgt den allgemeinen Richtlinien aber noch recht genau. Mir fällt als Extrembeispiel Quappo ein, das in Generation 7 ausschließlich speziell gespielt wurde, obwohl sein Angriff um 25 Basispunkte höher war. Solche Fälle lassen sich nicht allgemein angeben, da sie immer aus ganz speziellen Gründen entstehen. Deswegen wäre meine aktuelle Tendenz eher, auf Glurak/Strategie beispielsweise ein Moveset aus Feuersturm/Orkan/Fokusstoß/Ruheort anzugeben. Das wäre relativ universell und auch in einem Jahr noch eine mögliches Moveset. Nach aktuellen Richtlinien würde ein neu angelegtes Glurak-Set aktuell aus Flammenwurf/Ruheort/Auflockern/Toxin bestehen, was zwar das aktuell beste Set in seinem Tier ist, aber in 2 Monaten wieder vollkommen nutzlos sein kann. Das andere Moveset ist hingegen wohl nie die optimale Spielweise, aber halt auch nie nutzlos“. Es wurde sich darauf geeinigt das Luca sich hierzu Gedanken macht und ein mögliches Konzept auf der Projekt-Diskussionsseite online stellt.
Planung von Events / Auswertung VBW / Die Sinnoh-Initiative
Mögliche Upcoming Events sind Ostern, Halloween, Weihnachten, VBWs Initiativen: Es wurde sich darüber Gedanken gemacht wie wir die Community der aktiven Schreiber, der Leser in Form von Events, Initiativen oder VBW ansprechen können. Buo merkt klar an das er keine "verramschung" von Events will. Events sollen Belohnend für Teilnehmer ausfallen. Ein Möglichkeit ist hier eine materielle Bepreisung. Eine Bepreisung ist immer auf die aktuelle Lage anzuwenden. Dies zeigt sich auch in der letzten VBW. Diese wurde kurzfristig aufgrund der Pandemie-Situation online gestellt. Der Gedanke war das mehr zu Hause sind und es daher der beste Zeitpunkt dafür wäre. Die Realität hat hier jedoch das Gegenteil gezeigt. Viele mussten sich auf veränderte Private Umstände Home-Schooling usw. einstellen was zu einer geringen Beteiligung führte. Auch waren die in der schnelle Ausgewählten Preise in Form von Schwert/Schild (ohne DLC) in der Zeit des DLC -Releases eher veraltet und suboptimal gewählt. Es wurde sich geeinigt das bei Events 2021 Preise in Form der kommenden Spielreleases (NSNPSDLPPLA), Merch rund um 25 Jahre Pokémon, falls Verfügbar aktuelles TCG oder Merch aus Japan der hier i.d.R. nicht zu bekommen ist genutzt werden soll. Ein derartiges vorgehen wird auch für die kommenden Jahre bevorzugt. Wichtig ist Ideen für Events frühzeitig #intern und bei materieller Bepreisung mit Buo abzuklären. Buo gibt klar zu verstehen das er gerne auch Preise für Aktionen die nicht auf User-Neugewinnung sondern lediglich Ausbau/Erneuerung diverser Wikidinge durch erfahrene User ausgelegt sind zur Verfügung stellt.
Gestaltung der Stellenanzeigen/Ausschreibungen
Der Status Quo wurde besprochen. Es fehlt lediglich Bilder einzelner Projekte und einige Aufgaben. An sonsten steht die Basis. DeXter wird zeitnah Projektleiter anschreiben wo noch Sachen fehlen. Abgabefrist ist der 14.03.2021. Nachfolgend wird es DeXter ins LiveWiki einbauen. Sollte er es aufgrund privater Umstände DeXter zeitlich nicht ermöglichen können wird die Einbindung seitens der Admins übernommen.
PokéWiki Diskussion:Spiele-Projekt#Freundschaft, Zutrauen und Zutraulichkeit
Zu vielen Änderungen mit der Einführung Gen8 fehlen uns Spielinterne Daten. Solange ist eine größere Erweiterung bzw. Vertiefung des bisherigen Artikels nicht möglich. Für die Implementation in die Pokédex-Artikel hat sich Tai überlegt einen separaten Abschnitt mit der Auflistung von Veränderungen über die Generation einzufügen. Einen Namen für den Abschnitt hat er noch nicht. Es wurde sich überlegt ggf. eine Ideenfindung über die Projekt-Diskussionsseite oder den Discord-Projekt-Channel anzuregen. Nach Implementation des Abschnittes werden sämtliche ältere Daten aus der Infobox entfernt und nur noch die Aktuellen angezeigt.
Spielkürzel
Es wurde sich darauf geeinigt die Spielkürzel für Park der Freunde (Bestandteil DPPT) und PokéWalker (Bestandteil HGSS) zu entfernen und vorhandenes in die zugehörigen Spiele zu integrieren. PokéMove wird vorrangig im Benutzernamensraum genutzt behandelt allerdings ein eigenständiges Spiel. Es wurde dessen verbleib entschieden. Die Nutzung der Schwert/Schild DLC sks wurde besprochen. Die speraten sks für Die Insel der Rüstung und für Die Schneelande der Krone sind in Summe unter 50. Aufgrund der Einbindungszahlen gegenüber den sks mit EX-suffix wurde sich entschieden SWR, SWK, SHR und SHK zu löschen. Für die kommenden Spiele Pokémon Strahlender Diamant und Leuchtende Perle wurde sich für die sk SD und LP entschieden und für Pokémon-Legenden: Arceus das sk PLA welche bereits von Robbi hinzugefügt wurden.
VB-Wahlen
Es wurde die Grundthematik Wiki und Verpflichtung besprochen. Fakt ist das eine Pflicht nicht ohne Sanktion eingefügt werden kann. Gerade in höheren Ebenen sind wir allerdings auf jede Hand angewiesen. Es wurde sich darauf geeinigt das die derzeitige Formulierung "Der Vorschlag gilt als autorisiert, wenn ⅔ der Administratoren (Bürokraten nur einberechnet, wenn sie ihre Stimme abgeben) und Redakteure ihn unterstützen. Die erste Wahlrunde läuft so lange, bis ein Ergebnis vorliegt." den Spielraum frei gibt das User nur Verpflichtet sind abzustimmen solange eine ⅔-Mehrheit noch nicht erreicht ist oder bereits >⅓ Contra gestimmt hat. Solange nicht die überwiegende Mehrheit der Abstimmungen ignoriert wird. Jedem User der zur VB-Wahl gestellt wird, wird der Posten eines Projektleiters grundsätzlich zugetraut. Eine separate Kennzeichnung ist nicht notwendig. Der Wunsch jemanden als PL haben zu wollen kann in der Stimmbegründung vermerkt werden. Teilnahmeberechtigt sind User in der ersten Wahlrunde User die während gesamten ersten Wahlrunde den Status eines Admins oder Redakteurs inne haben. In der zweiten Wahlrunde sind alle Verlässlichen Benutzer zugelassen die bei Start mindestens den Rang VB besitzen und Ihn bei regulärem Wahlende noch inne haben
Wertschätzung
Im Zuge der Diskussion zur Umgestaltung der Rechtestruktur gab es zwischen vielen Ebenen und Usern Konflikte. Diese konnten zwischenzeitlich beräumt werden und ein besserer offene Umgang bei diversen Themen beschlossen. Weiter wurde beschlossen das Mec die Neueinbringung solcher Vorschläge dauerhaft untersagt wird 
→ Anmerkung: Mec weiß aus persönlichen Gesprächen wie diese Aussage im Detail gemeint ist und das sie keinen Angriff auf Ihn darstellt. Es wurden allgemeine Zustände im Rollbackverhalten, Nutzung der Danke-Funktion, Emoji-Verwendung, Umgangston widergespiegelt. Der Allgemeine Konsens ist hier das ein jeder von uns eine stärkere Selbstreflektion durchführen sollte. Statt immer wieder kommentarlosen Rollbacks sollte lieber zurücksetzen mit Kommentar durchgeführt werden (Vandalismus ausgenommen). Auch wenn es vielleicht der fünfte neue Benutzer auf Discord oder im Wiki ist der an dem Tag den selben Fehler macht dann gilt ein respektvoller Umgang und erst der Neutrale Hinweis des Falschverhaltens oder aufzeigen des "Fehler" im Wiki. Jemand der Unbelehrbar ist oder dessen Verhalten klar vandalierend/mutwillig ist. Beispielsweise Schädliche Edits die Sogar zum Schutz der Allgemeinheit versteckt werden müssen. User die auf Discord kommen und direkt Verboten Symbole posten usw.. Bei diesen Usern darf ruhig direkt dann der Bannhammer geschwungen werden. Sachen die Unklar sind wie div. Bilder/Statuseinträge gehören immer erst im Mod/Intern-Bereich abgeklärt werden oder Mann kann denjenigen auch direkt fragen, was das Emoji (bedeuten) soll, dies kann man ja mal laut Empfehlung Buo versuchen. Dann merkt derjenige vielleicht, dass das nicht abgebracht war. Und der Angegriffene fühlt sich ggf. verteidigt und nicht in die Ecke gestellt. Durch Selbstreflektion wollen wir weg kommen von entnervten Eindrücken außenstehender oder dem vergraulen potenzieller User. Eine der Kernfragen ist dabei „Wie kann man es besser machen?“ Es wurden in diesem Zuge Beispiele genannt für die Nutzung der Danke-Funktion, Nutzung der Diskussionsseite unter dem Gesichtspunkt der Unterstützung. Bsp. Du hast die Vorschau nicht wie angezeigt genutzt. Gibt es Probleme bei der Nutzung. Kann man dir helfen? Der Hinweis hat diesen und jenen Grund. Also wenn Fragen stell sie gerne. Die Idee der Unterstützung der Wertschätzung durch Einführung immer wieder neuer Babel für Qualität usw. wurde verworfen. Kernproblematik ist die oftmals fehlende Hineinversetzung in andere/neue User. Was auch für erfahrene Benutzer ein stätiger Lernprozess werden und bleiben muss. Es wurde sich darauf geeinigt das alles was uns Einfällt um die Situation der Wertschätzung zu verbessern gesagt wurde. Es wurde sich darauf geeinigt einen neuen Punkt zur Wertschätzung auf der AD zu eröffnen nach dem Motto was können wir verbessern, wo seht ihr Probleme mit aktiven Ping auch über Discord an die SBs. DeXter wird entsprechendes vorbereiten.
Mobiles Design
Buo gab eine Auswertung der zehn häufigsten Auflösungen (1920x1080, 414x896, 375x812, 375x667, 360x780, 360x640, 412x915, 412x869, 360x740, 1536x864). Auf dieser Grundlage und vielen Mindestanforderungen wurde sich darauf geeinigt das wir als Mindestbreite 320px Nutzen. Alles darunter wird zukünftig von Vorlagen nicht berücksichtigt werden können. Für die Mobile Ansicht wurde sich auf ein Spektrum von 320px bis 480px geeinigt. Bei diesem sollen Infoboxen über die komplette Breite gehen und Inhalte darunter erfolgen. Weiter wurde sich darauf geeinigt keinen Mischmasch zu betreiben. Die Größenorientierung gilt Projektübergreifend. Buo stellt einige Tests und Optimierungen (sowohl Grafisch als auch rechtlich) für das Wiki vor. Diese Test zeigen adaptiertes Aussehen für Mobile Darstellung mit wechselnder Anpassung bei 850, 1080 und 1450. Buo prüft die Möglichkeit der Anpassung auf 750 was vermutlich eher auf 768 hinauslaufen wird. Die Tests wurde besprochen und diverse Optimierungen festgelegt welche Buo umsetzt. Für ein Mobiles Design sind auch Änderungen an der Topbar notwendig. Die Notwendigen Änderungen sind nicht überall auf Anklang gestoßen. Es wurde sich darauf geeinigt hier Funktionen zu implementieren die von User CSS/js angesteuert werden können. Damit sich jeder selbst seine Topbar gestalten kann. Die Reorganisation diverser bisheriger Einblendungen muss geprüft und mit Tests abgeklärt werden. Es wurden Lösungsansätze für Aufzählungsvorlagen (Navigationsleisten usw.) die auf volle Breite mit <br /> ausgelegt sind besprochen. Es soll geprüft werden inwieweit wir in diesen auf Trennungszeichen wie • und fixe breaks verzichten können und stattdessen einen fixen Abstand von z.B. 3px zwischen den Aufzählungen verwenden um einen sauberen Umbruch je nach Seitenbreite zu erzeugen. Die Orte Trainer Vorlage könnte neu Strukturiert mittels GridBoxen angepasst werden. Ryu lernt noch Blumen und Unkraut zu gießen. Andere Vorlagen wie Orte/Unterschied oder die Ursprünglich geplante Entwicklungsvorlage würden in Ihrer jetzigen Basis einen Massiv komplexen Umbau benötigen wo der Punkt offen ist Sie nicht durch andere Konzepte zu ersetzen. Sämtliche Details zum Mobilen Design und Status der Anpassung bleibt bis auf weiteres auf interner Ebene bis die Anpassungen repräsentativ und fehlerfrei für die Masse sind.