Site-Management-Tools gesucht!

[Michael Schröpl]

Oder einfach weitere gute Tips zum Umgang mit der Datei-/Navigationsstruktur in G R O S S E N Projekten?

<predigt>

Modularisieren und automatisieren - wie bei allen großen (Software-) Projekten.

Für HTML heißt das m. E.:

• Tiefe Verzeichnisstruktur.
  Innerhalb eines Verzeichnisses nur Dokumente mit strengem inhaltlichen Zusammenhang und gleicher Abstraktionsebene. Keine Angst vor langen URLs - lieber dies, als alles in einen Topf werfen und sich später darin nicht mehr auskennen. Kleine Häppchen sind flexibler handhabbar, besser identifizierbar und deshalb besser automatisch verarbeitbar. ("www.teamone.de/selfaktuell/" ist für meinen Geschmack zu "flach", SelfHTML zu linear und einfügeunfreundlich. ;-)

• Relative URLs.
  Innerhalb eines Moduls alles relativ verknüpfen. Was für das Domain-invariable Publizieren gilt, erleichtert auch das Verschieben eines Moduls.

• Dünne Kanten.
  Verbindung zwischen den Modulen möglichst überschaubar halten. Es mag inhaltlich sinnvoll sein, hundert Verweise auf die Definition eines Begriffs zu machen - wenn man dessen Zielort jemals ändert, wird es teuer. Deshalb:

• Stabile URLs.
  URLs für besonders attraktive targets (z. B. ein firmenweites Stichwortverzeichnis) nur im Notfall ändern. Schon beim Entwurf der Verzeichnisstruktur möglichst viele künftige Erweiterungen mit einplanen. Zusätzliche leere Verzeichnisse stören niemanden; später eine zusätzliche Abstraktionsebene einziehen zu müssen ist bitter, und sie nicht zu haben, wenn man sie braucht, ebenfalls.
  Unwichtige Teile sind mobil - wichtige Teile nicht, denn wer paßt die Bookmarks der Besucher an? Ach ja, gleich dazu:

• Tolerante Fehlerbehandlung.
  Bei URL- und Bookmarkleichen nicht "404 - ätsch", sondern ein intelligentes CGI-Skript, welches möglicherweise sogar eine Liste aller "Umzüge" als Datei besitzt und die neue Adresse damit *erraten* kann. Mindestens aber ein Verweis auf eine Suchfunktion, mit der man die neue URL herausfinden kann.

• Navigation und Corporate Identity als Module auffassen.
  Eine Linkleiste in tausend Dokumente nicht kopieren, sondern einbinden (SSI und Ähnliches) und nur an einer Stelle ändern müssen. Kopf- und Fußzeilen, Header, CSS-Referenzen etc. ebenfalls. Je größer, desto SSI; Bausteine sind beherrschbar, wie UNIX uns täglich beweist.

• Redundanzen meiden.
  Was fünfmal gespeichert ist, muß fünfmal gewartet werden. (Und kann prima inkonsistent werden. ;-) Besser mehr generieren als mehr tippen - keine Angst vor CGI und Co.

• Konsistenz automatisieren.
  Wenn man denn wirklich mal etwas verschieben muß und vielleicht nur 10 oder 20 Links anzupassen hat, dann muß man diese auch in 1000 Dokumenten schnell und zuverlässig finden können. Es gibt gute Links-Checker als Freeware.

Und wenn es dann ganz flexibel sein soll:

• Generische Dokumentinhalte.
  Eine eigene Konfigurationsdatei mit Variablen für wesentliche Baum-Positionen halten, und in allen Quelltexten solche Variablen verwenden und Verweise aus ihnen generieren. Dann kann die Verschiebung eines kompletten, heftig vernetzten Moduls durch die Änderung einer einzigen Zeile und einen Generatorlauf über den gesamten Baum erfolgen. Auf diese Weise kann man neben Links auch andere interessante Informationen in die Dokumente hineingenerieren (Datum der letzten Änderung, URL des Dokuments im WWW etc. alles ohne JavaScript).
  Ob diese Metastruktur in separaten Dateien proprietärer Formate abgelegt wird (so machen es vermutlich kommerzielle SiteManagement-Systeme) oder in selbstdefinierten Zusatz-Tages (so habe ich es in Freeware-Systemen gesehen), ist eine reine Geschmacksfrage: Beides müssen die Autoren generischer Dokumente zusätzlich lernen.

Nicht zuletzt:

• Disziplinierung und Überwachung.
  Es hilft nichts, Richtlinien aufzustellen, wenn man keine Werkzeuge besitzt, deren Nichteinhaltung wenigstens zu bemerken.
  Man könnte beispielsweise ein Skript schreiben, welches den gesamten Dokumentbaum nach genau denjenigen Strings durchsucht, welche als "heilig" in der Konfigurationsdatei definiert wurden ... das ist nicht weniger wichtig als der nächtliche oder wöchentliche Lauf des links-Checkers.
  cron ist geduldig, und nicht-leere Fehlerlisten können dem Administrator automatisch zugemailt werden.

Und abschließend:

• Qualität wollen.
  Qualität kostet Aufwand und Infrastruktur, ist aber schwer quantifizierbar. Ohne Budget geht es nicht, und ohne den ernsthaften Anspruch, sie haben zu wollen, erst recht nicht. Schon die Fragestellung, also das Erkennen des Problems, gehört zum Thema "Qualität".
  <überspitzt>Wer Qualität will, erreicht Durchschnitt; wer Perfektion will, erreicht Qualität.</überspitzt>

</predigt>