Hilfe:Wikistruktur

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

In diesem Bereich soll die Struktur und Seitenhierarchie des SelfHTML-Wikis behandelt werden. Anders als in der Wikipedia verwendet SelfHTML für Artikel eine inhaltlich begründete hierarchische Dokumentation anstatt alle Artikel in einer Hierarchieebene im Hauptnamensraum abzulegen.

Namensräume[Bearbeiten]

Die ursprüngliche SELFHTML Doku hatte einen relativ statischen Aufbau, der nach 2003 nicht mehr groß erweitert wurde. Daraus ergab sich die Notwendigkeit weiterführendes Wissen und Fachartikel in einem neuen Bereich SELFHTML-aktuell zu präsentieren.

Als das Wiki 2010 aufgesetzt wurde, wurden so eine Vielzahl von Namensräumen konfiguriert:

  • Doku: (für den Hauptteil der Dokumentation)
  • Artikel: (Beiträge zu speziellen Themen)
  • Kurse: (Lehrgänge zu einzelnen Themen)
  • Themen: (Beiträge zu Themenschwerpunkten)
  • Referenzen: (Übersichtstabellen für den Profi)
  • Glossar: ( nur kurze Erläuterungen zu Fachbegriffen und Abkürzungen)

Leider erwies sich das als kontraproduktiv zur Arbeitsweise der verwendeten MediaWiki-Software. Die ist mehr für ein Lexikon mit Begriffen im Hauptnamensraum (das ist der ohne einen Vorsatz) ausgelegt und weniger gut für hierarchische Dokumentationen, wie diese hier. Die Suchfunktion beispielsweise kann einen Artikel direkt anspringen, wenn das Suchwort mit dem Titel übereinstimmt. Das funktioniert aber nicht, wenn der Artikel sich nicht im Hauptnamensraum befindet.

Lösung[Bearbeiten]

Die Artikel werden (mit Ausnahme der Referenzen und des Glossars) direkt im Hauptnamensraum einsortiert.

Auch die Einteilung in Bereiche wie Basiswissen, Grundlagen, Praxisnah, Weiterführendes Wissen und Technische Ergänzungen wird nicht weiterverfolgt. Seiten sind entweder direkt im Hauptnamensraum angelegt oder unter Grundlagen einsortiert.

Mehrdeutigkeit[Bearbeiten]

Manche Stichwörter (zum Beispiel font) sind mehrdeutig und nicht nur einem Themenbereich zuzuordnen. Die Wikipedia löst dieses Problem, indem mehrere Artikel erstellt werden, die jeweils einen klärenden Zusatz in Klammern angehängt bekommen, wie font (html) und font (css).

Im Gegensatz zu einem Lexikon, in dem die Stichwörter mehr oder weniger zusammenhanglos aufgeführt werden, ist eine Dokumentation deutlich klarer strukturiert beziehungsweise strukturierbar. Hier kann man die Bereiche HTML und CSS erstellen und die jeweiligen font-Seiten darunter einsortieren, à la HTML/Elemente/font und CSS/Eigenschaften/font. Daraus geht auch klar hervor, in welchem Zusammenhang das jeweilige font steht.

Mit dieser Strukturierung ergibt sich aber auch wieder der Nachteil, dass die Suchfunktion nicht direkt eine dieser Unterseiten anspringen kann, wenn nur der Begriff statt des vollständigen Titels der Seite eingegeben wurde. Doch es ergibt sich ein entscheidender Vorteil. Für diese Seiten mit Unterseiten erstellt die Wiki-Software ohne weiteres Zutun einen Breadcrumb-Pfad. Das heißt, auf die Seiten zu HTML und HTML/Elemente respektive CSS und CSS/Eigenschaften wird gleich unter dem Seitentitel verwiesen und man muss nicht händisch eine Navigation einbauen, so wie das bei Stichwort-Seiten im Hauptnamensraum der Fall wäre.

Lösung[Bearbeiten]

Die beiden Vorteile lassen sich mit einem Kompromiss nutzen. Der eigentliche Text zu den Stichwörtern wird auf einer (Unter-)Seite in der jeweiligen zum Themengebiet spezifischen Struktur einsortiert (Beschreibungsseite).

Für die Suchfunktion und zur besseren Verlinkbarkeit (…/begriff statt …/struktur_1/struktur_2/begriff) wird pro mehrdeutigem Begriff eine Seite direkt im Hauptnamensraum angelegt, die entweder eine direkte Weiterleitung auf den strukturierten Titel ist oder eine Begriffsklärung mit Auswahlmöglichkeit erhält (Stichwortseite).

Beispiele[Bearbeiten]

CSS-Eigenschaft font-size:

font als CSS-Eigenschaft, HTML-Element, Schriftart-Datei, …

Weitere Hinweise zur Begriffsklärung unter Hilfe:Wikistruktur/Begriffsklärung.

Einzelseiten statt Monsterseiten[Bearbeiten]

Wenn eine Seite zu groß wird, werden unter anderem Bearbeitungen immer unhandlicher. Dieses Problem kann man teilweise umgehen, indem man nur einen Bereich zum Bearbeiten wählt und nicht die gesamte Seite.

Diese Bereiche ergeben sich automatisch anhand von Zwischenüberschriften. Für jede Überschrift setzt das verwendete Wiki-System automatisch einen Anker, der aus dem Text der Überschrift gebildet wird, so dass man diesen Teilbereich aus dem Inhaltsverzeichnis der Seite oder von anderswo aus verlinken kann (…/Seitenname#Überschrift).

Im Gegensatz zur Verlinkung auf eine Seite an sich, werden die Links auf Anker bei einer Änderung der Überschrift nicht weiter berücksichtigt. Beim Verschieben/Umbenennen einer Seite wird zumindest unter dem alten Namen eine Weiterleitung erstellt. Anker werden nur im Browser ausgewertet und beim Klicken auf Links nicht an den Server übermittelt, so dass dieser rein technisch nicht in der Lage ist, Weiterleitungsmaßnahmen zu ergreifen. Zur Unterstützung beim Pflegen von Links gibt es auch keine Funktion „Verweise auf Anker finden“. Genauer gesagt, sie tauchen auf keiner der Wartungslisten auf. Im Gegensatz dazu kann man Links auf eine bestimmte Seite problemlos anzeigen lassen und die Wartungslisten verwenden.

Das bedeutet vor allem für Themen, die regelmäßig auch direkt angesprungen werden, dass die Stabilität von Verweisen leidet. Solche Themen sind beispielsweise die Beschreibungen von Eigenschaften und Methoden der Javascript-Objekte oder von Attributen der HTML-Elemente. Nicht unbedingt darunter fallen zum Beispiel Abschnitte in einem Tutorial.

  • JavaScript/…/window ist die Seite für allgmeine Informationen zum window-Objekt
  • Die Seiten für Eigenschaften und Methoden werden benannt:
    • JavaScript/…/window/name
    • JavaScript/…/window/blur
    • usw.

Allerdings ist diese Vereinzelung teilweise auch nachteilig für den Leser. Wenn er sich zwischen den Abschnitten hin- und herbewegen möchte, muss er die Seiten wechseln. Die im Browser eingebaute Suchfunktion wirkt nur auf einzelne Seiten und nicht übergreifend. Beispielsweise bestehen reguläre Ausdrücke üblicherweise aus Sonderzeichenkombinationen, die sich schwer bis gar nicht über Suchmaschinen finden lassen. Die Browser-Suchfunktion kann sie jedoch innerhalb einer Seite finden, bei aufgeteilten Seiten hingegen nicht mehr.

Diese Nachteile kann man ohne das Hinzufügen der Nachteile für das Bearbeiten von großen Seiten umgehen, indem auf der übergeordneten Seite oder einer eigens angelegten Zusammenfassungsseite diese Einzelseiten wie eine Vorlage eingebunden werden. An deren Stelle erscheint für den Leser der gespeicherten Seite der Inhalt dieser Vorlage / Einzelseite, im Code bleibt weiterhin der Vorlagen-Verweis stehen.

Beispiel: der Seite für JavaScript/…/window
Allgemeiner Text über das window-Objekt. == Eigenschaften == {{:JavaScript/…/window/name}} usw. == Methoden == {{:JavaScript/…/window/blur}} usw.

Fortsetzung:

← Wikistruktur Hilfe Namenskonventionen →