Jump to content

Shadowhelix - Kategorieüberarbeitung


Loki
 Share

Recommended Posts

(So wie ich mir das zuerst vorgestellt habe, würde ich es doch nicht umsetzen, weil es zu aufwändig ist. Deshalb anstatt der Demonstration zuerst der Vorschlag.)

 

Ansatz zur Überarbeitung: Ich würde ein zweigleisiges System für alle Kategorien mit Hierarchieebene einführen.

 

Konkret für das Beispiel der Schattenklinik Flower Power Stitches (FPS) in Redmond. Sie bekommt nur die sichtbaren Kategorien "Location (Schattenklinik)" und "Location (Redmond)". Aber sie wird außerdem in die versteckten Kategorien "Alle Locations (Redmond)", "Alle Locations (Seattle)", "Alle Locations (UCAS)" usw. eingetragen. Der Unterschied zwischen "Location" und "Alle Locations" ist folgender:

  • Location (Redmond) enthält FPS.
  • Alle Locations (Redmond) enthält FPS.
  • Location (Seattle) enthält FPS nicht.
  • Alle Locations (Seattle) enthält FPS.
Das heißt "Alle Locations" funktioniert wie bisher, aber "Location" enthält immer nur die Einträge auf dieser Ebene. Man würde also in "Location (Seattle)" alle Einträge sehen, die keinem Distrikt zugeordnet wurden. Man kann von dort zu "Alle Locations (Seattle)" wechseln und alles sehen wie früher oder zu "Location (Redmond)", wo dann wiederum nur die Redmond-Einträge sind (ohne Einträge, die nochmal eine Ebene darunter liegen, zum Beispiel Touristville, wenn es diese gibt).

 

Wenn man zusätzlich der Meinung ist Schattenkliniken sollten eine eigene Kategorie sein, kann man Flower Power Stitches auch in die Kategorie "Location (Schattenklinik, Redmond)" oder wenn man diese Ebene nicht für sinnvoll hält stattdessen "Location (Schattenklinik, Seattle)" einordnen, entsprechend gibt es auch wieder versteckte "Alle Locations (Schattenklinik, Seattle)" usw. Die Unterkategorien zu Locationtypen können zusätzlich über "Location (..)" erreicht werden.

 

Das wären zwei (oder drei) Kategorien für diese Location. Deutlich übersichtlicher als bisher. Zusätzlich hätte man sowohl die Sammelkategorien als auch Kategorien aus denen sofort ersichtlich ist, welche Inhalte nur auf dieser Ebene vorhanden sind. Das ist im Moment überhaupt nicht möglich.

 

(Übrigens wäre das auch der Moment, wo man den Namen "Location" ändern könnte in "Ort". Ich glaube darüber wurde auch mal nachgedacht.)

Link to comment
Share on other sites

So, ich habe das für drei Artikel eingerichtet: Basil's Faulty Bar, Greenwoods Inn und Plastic Jungles. In den Artikeln steht jeweils nur ein Location-Eintrag. Als zusätzliche Navigationshilfe sind in der entsprechenden Kategorie auch nochmal Navigationsleisten eingefügt, die den schnellen Wechsel auf einer Hierarchieebene ermöglichen. Auf der Ebene darüber kann man jetzt den Unterschied sehen zwischen:

 

Kategorie:Location (Seattle)

 

und

 

Kategorie:Alle Locations (Seattle)

 

Letztere funktioniert wie die bisherigen Locations-Kategorien, also mit sämtlichen, erstere als neue Hauptkategorie enthält immer nur die Einträge auf der entsprechenden Ebene.

Link to comment
Share on other sites

Also, ehrlich gesagt fand ich es schöner, wenn etwas in Locations und dann runtergebrochen auf die einzelnen Unterkategorien steht. Also: "Locations", "Locations (Staat)", "Locations (Land)",

"Locations (Stadt)" - und so vorhanden "Locations (Stadtteil)" + "Locations (Typ)" falls für den betreffenden Location-Typ eine Kategorie existiert (z. B. "Locations (Flughäfen)").

Link to comment
Share on other sites

Also mit anderen Worten so wie bisher.

 

Das ist weniger übersichtlich und dann stellt sich halt die Frage, ob das mit einem Mehrwert zu rechtfertigen ist:

 

Also nehmen wir wieder den Fall ich befinde mich bei der Straßenklinik in Redmond. Wie oft kommt es vor, dass ich dann sage, ich würde jetzt gerne alle Locations in den UCAS sehen? Zumal dort dann auch wirklich alles aufgelistet ist, nicht nur die explizit den UCAS zugeordneten Locations. (Auf Kontinentalebene sind die Kategorien eigentlich schon kaum zu gebrauchen außer für die technische Auswertung, für die es im neuen System die neue "Alle Locations"-Variante gibt.) Was ich mir schon eher vorstellen kann, dass man andere Seattler Locations sehen will, aber das ist über die "Location (Redmond)"-Kategorie ja auch mit nur einem Klick mehr möglich. Und gerade die Typ-Kategorien gehen neben vielen geographischen Hierarchieebenen leicht unter.

 

Eine Kritik von Sascha war ja die Abschreckung durch zu viele komplizierte Vorlagen. Das neue System erfordert natürlich auch eine komplizierte Vorlage, aber man liegt mit der einfachen Angabe "[[Kategorie: Location (Ort)]]" auf jeden Fall schonmal richtig. Mit dieser einen Angabe wird zumindestens das eine der beiden parallelen Kategoriesysteme richtig befüllt, ohne dass man hinterherräumen oder jemanden die Vorlagenfunktion beibringen muss. Und mehr sieht man ja auch erstmal nicht. Gleichzeitig wird so ein Ankerpunkt geschaffen, um die Kategorie später halbautomatisch oder automatisch anzupassen.

Link to comment
Share on other sites

Wie muss ich erstmal sehen, wenn ich die entsprechende Vorlage baue.

 

In jedem Fall wird die Umstellung längere Zeit dauern, mein Bot läuft immer noch nicht wieder. Aber das lässt sich genauso nach und nach machen: Da die beiden neuen Kategoriesystem mit "Location" und "Alle Locations" anders heißen als "Locations" kann das ohne weiteres nebeneinander bestehen.

 

Übrigens hast du durchaus Zugriff auf einen Bot, musst du dir nur installieren, das ist keine Funktionalität des Wikis.

Link to comment
Share on other sites

Hm, dachte es könnte komplizierter werden, aber für den einfachsten Fall ist die einzige Änderung gegenüber KatSort, dass man die unterste Ebene nach vorne stellen muss. (Allerdings habe ich auch die Zuordnung "Location" zu "Alle Locations" in die Vorlage einkodiert, damit man sie nicht jedesmal angeben muss.) Ich würde das verwenden:

{{KatML|cat=Location|Stadt|Land|Kontinent|Erde}}
und für Locations außerhalb der Erde folgendes, um den Nutzen von Alle Locations für diesen Raum zu erhöhen:

{{KatML|cat=Location|Ort außerhalb der Erde|...|Gruppe|Sonnensystem}}
ML steht für Multilevel.

 

Metaebenen muss ich mal darüber nachdenken, aber da gibt es im Allgemeinen nicht so viele Lokalisierungsstufen anzugeben.

Link to comment
Share on other sites

.... oder man macht einfach

[[Kategorie: XYZ]]

Wir erinnern uns... das ganze sollte entkompliziert werden, was vor allem auch durch Lesbarkeit geschieht. Drölfzig begriffe die mit einem kompliziertem Kürzel beginnen und nur mit einem | getrennt werden, sind für Laien nicht lesbar.

Link to comment
Share on other sites

Ich denke das wird dem gerecht, weil wie gesagt sichtbar ist von:

{{KatML|cat=Location|Stadt|Land|Kontinent|Erde}}
nur

Kategorie:Location (Stadt)
Und das kann man in einem eigenen Artikel auch ohne weiteres als einzige Kategorie eintragen. Um das komplexere System dahinter kann sich jemand anders immer noch später kümmern.
Link to comment
Share on other sites

Es geht darum, dass der "Code" des Artikels für Leute lesbar ist, die ihn benutzen wollen um zu verstehen, wie man selber einen Artikel schreibt. Und die Verstehen nicht wie aus {{KatML|cat=Location|Stadt|Land|Kontinent|Erde}} einfach nur Kategorie:Location (Stadt) wird. Sie verstehen aber sehr gut wie aus [[Kategorie:Location (Stadt)]] Kategorie:Location (Stadt) wird.

Link to comment
Share on other sites

Erstens glaube ich das nicht wirklich, also natürlich verstehen sie es vermutlich nicht inhaltlich, aber durch die Position ist durchaus klar, hier ist ein Kategorieelement, hier ist eine Tabelle usw.

Zweitens das muss man den Bearbeitern schon zumuten, denn das gleiche gilt ja für ggf. Hinweistexte, Infoboxen, Shadowtalk, Tabellen, ref-Tags, Indexspalten oder die Quellenvorlage. Wenn die Anwesenheit solcher Konstrukte eine derartige Abschreckung entfalten würde, müssten wir - lange bevor man bei den Kategorien ganz am Ende ankommt - zuerst auf Infoboxen am Artikelanfang verzichten, denn da wird man sofort mit kompliziert formatiertem Text konfrontiert, der überhaupt nicht zum eigentlichen Anfang des Artikels passt.

Drittens, wenn KatML, KatSort etc. dort steht, muss an den Kategorien überhaupt nichts geändert werden. Warum sollte jemand da auf die Idee kommen überhaupt eine Kategorie hinzufügen zu wollen? Und mit der neuen Variante sammelt man aus anderen Artikeln die Erfahrung, dass man in einen potentiellen eigenen nur "Kategorie:Location (Stadt)" hinzufügen muss. Wobei auch da muss ich sagen, man kommt doch recht schnell auf die Idee einen anderen Artikel zu kopieren und einfach nur abzuwandeln, und dann erschließen sich auch schnell kompliziertere Konstrukte. Oder was auch passiert Kleinigkeiten werden nachgebessert und dann sieht man am Unterschied ebenfalls recht schnell, wie Dinge funktionieren.

 

Ich habe die Komplexität des Kategoriesystems ehrlich gesagt immer aus Nutzersicht gesehen.

Link to comment
Share on other sites

Und aus Nutzersicht ist, dass kann ich nach etlichen Jahren Informatikstudiums zu recht sagen, effizienter, kurzer Code verdammt unleserlich. Deshalb ist es für die Benutzerfreundlichkeit manchmal sinnvoller umständlicher zu arbeiten, um Code für andere lesbarer zu machen.

 

Und Infoboxen sind durchaus einfach lesbar. Jede Spalte ist (im Idealfall) mit dem Beschriftet, was auch im fertigen Artikel steht, jede Spalte der Box hat auch im Code eine eigene Spalte, unausgefüllte Spalten erscheinen auch nicht im Artikel.

 

Langer Bandwurmcode, wo Dinge eingefügt sind, die dann später aber nicht auftauchen, weil damit voll coole fancy Dinge gemacht werden, sind nicht auf den ersten Blick zu verstehen.

 

Wenn jemand einen neuen Artikel schreibt, muss er Kategorien einfügen. Und es kommt durchaus vor, dass von Zeit zu Zeit neue Kategorien hinzukommen, oder wieder entfernt werden - it's a Wiki.

Link to comment
Share on other sites

 Share

×
×
  • Create New...