Ist SelfHTML tot?

[Sven Rautenberg]

Werte Netzgemeinde, liebe Diskursführende, hallo Leser! :)

Als Swen Wacker diesen Thread hier auf Twitter am Freitag "beworben" hat, habe ich ihn ohne großes Zögern sowohl auf meinem Account, als auch über @SELFHTML retweeted. Jeena hat das im späteren Verlauf noch einmal wiederholt.

Für mich war klar: Die existierende Redaktion ist entweder ohne Abschiedsgruß entschwunden, oder durch die tägliche Arbeit, insbesondere aber durch das Nicht-Bewältigen der selbst gesetzten Ziele, so frustriert, dass die Analyse von _Robert ohne Frage zutrifft: Die Arbeit an der Dokumentation ist derzeit tot. Das noch existierende Team hat - neben all den Dingen, die man unter Privat- und Berufsleben zusammenfasst - gerade genug damit zu tun, den Status Quo zu erhalten: Die Server laufen einwandfrei, das Forum wird moderiert, reinkommende Mails werden bearbeitet. Für mehr fehlt uns tatsächlich die Energie und Motivation.

Deshalb hatte ich durchaus Hoffnung, dass diese Diskussion vielleicht Lichtblicke und Hoffnungsschimmer liefert, dass der Netzgemeinde diese bekannteste deutsche Dokumentation nicht ganz egal ist.

Zu Beginn hat sich dann leider doch die typische Diskussion entwickelt, die zu erwarten war:

• Unsere Informationspolitik ist Schuld, wir sagen ja nix... obwohl der Redaktionsbereich schon seit Jahren so offen ist, wie es nur geht, wir sogar extra für den aus Sicherheitsgründen notwendigen SSL-Zugriff für teures Geld ein vernünftig signiertes Zertifikat angeschafft haben, und nicht mehr das von CAcert einsetzen. Pauschales Gegenargument: Egal wo wir es hinschreiben würden, es wäre für irgendwen immer genau die Stelle, die er übersehen hat. Andererseits stimmt's natürlich: Sonderlich aktiv um Mitarbeit geworben haben wir nicht, die Strategie bislang war, gezielt diejenigen Leute anzusprechen, die durch fachliche Kompetenz hier im Forum positiv in Erscheinung getreten waren.

• Die Technik ist Schuld, wenn's doch nur ein Wiki gäbe... Diese Argumentation hat Thomas J.S. in meinen Augen ziemlich gut analysiert: Keine Technik ist so perfekt, dass nicht irgendwer was zu meckern hätte. Wir haben gute Gründe dafür, dass die Technik derzeit auf dem WYSIWYG-XML-Editor (für diejenigen, die es gerne bunt haben) basiert, das SDML ist aber nicht so bösartig, dass man es nicht auch von Hand schreiben könnte. Über die Verwendung von SVN als Versionskontrollsystem kann es eigentlich auch keine zwei Meinungen geben - unter der Voraussetzung, dass mehrere Redakteure ihre Texte in SDML erfassen, ist SVN die einzige sinnvolle Lösung für die Zusammenarbeit.

• Es ist doch Wahnsinn, SELFHTML komplett neu schreiben zu wollen, warum nicht die alte Version umarbeiten... Auch dazu hatten wir uns in der Redaktion intensiv Gedanken gemacht, und sind zu dem Entschluss gekommen, dass die gesamte Struktur des alten SELFHTML schon viel zu lange nicht mehr dem Stand der Technik entspricht. Die Kapitel, wie sie sich in der aktuellen Version 8.1.2 darstellen, basieren dem Grunde nach auf Version 7.0 aus dem Jahre 1998. Und es gibt viele Textabschnitte, die seitdem nicht mit einer Silbe überarbeitet wurden, sondern immer nur "mitübertragen".

Aber zum Glück wendet sich das Blatt, und diese ersten Reaktionen, vielleicht sollte man sie als Eingangsstatements verstehen, werden jetzt tatsächlich diskutiert, indem die Seiten argumentieren und sich auch überzeugen lassen. Das stimmt mich zunächst wieder hoffnungsvoll.

Vielleicht noch mal ein paar ausführlichere Worte zu unseren Gründen, warum der Zustand der Redaktionsarbeit mit/für/an SELFHTML jetzt so ist, wie er ist:

1. Wir wollen eine downloadbare HTML-Version von SELFHTML anbieten. Dieses Feature erscheint uns extrem wichtig. Netzzugänge sind nicht verlässlich und/oder kosten in manchen Teilen der Welt immer noch viel Geld. Server sind nicht verlässlich, sondern können auch mal ausfallen. Deshalb ist die Verfügbarkeit der Dokumentation unter http://de.selfhtml.org eben gerade nicht 100% für die gesamte Weltbevölkerung. Genau deshalb halten wir uns für den Download der läppischen 8,5 Megabyte der alten Version noch immer ein Mirror-Netzwerk.

Die Nutzung eines Wikis macht eine downloadbare Version natürlich nicht unmöglich. Man könnte vermutlich problemlos einen Spider losschicken und eine lokale Version erzeugen. Oder man exportiert die Daten einfach "irgendwie" und schreibt sich "irgendwie" einen Exportfilter, der HTML erstellt.

Und es hab ja auch tatsächlich einen kurzen Versuch, ein Wiki zu installieren und zu nutzen. Dieser Versuch ist leider gescheitert. Ich gehe dazu auch gerne ins Detail, wenn Interesse besteht - unter dem Strich ist festzuhalten, dass das Thema Wiki sich seit diesem Versuch in der Redaktion im Prinzip erledigt hatte, und unsere gesamte Energie auf SDML konzentriert wurde.

2. Dieser Weg erschien vor allem dadurch realistisch, dass wir diesen XMLMind XML-Editor entdeckt hatten - ein in Java geschriebener Editor für Windows, Mac OS und Linux, also keine Speziallösung für jedes einzelne Betriebssystem, sondern nur eine einzige Software - in den Wichtigen Details der Bedienung auf allen Systemen gleich.

Und mit einem Mal wurde ein riesiges Problem, nämlich das bis dahin notwendige Coden von SDML-Quelltext, kinderleicht. Weil der Editor gleich nach DTD validieren kann, kann es keine Probleme mit invalidem SDML mehr geben, der Autor wird hinsichtlich seiner Absichten bestmöglich unterstützt, ihm werden nur die erlaubten Elemente zur Nutzung angeboten - er kann sich, so die Hoffnung, wirklich primär auf das Schreiben des Textes konzentrieren.

Dass damit alles in Butter sein würde - das war natürlich eine Illusion. Denn leider gibt es auch heute noch Computer, die einfach zu langsam sind und zu wenig RAM haben, um die Java Virtual Machine in akzeptabler Geschwindigkeit ausführen zu können - und einige Redakteure nutzen noch solche Rechner. Aber das Arbeiten mit SDML-Quelltext funktioniert ja weiterhin - wenn man auf sowas steht. Diese Arbeitsweise erfordert ebenfalls viel Einarbeitung - aber dadurch wurden auch noch einige Probleme in der DTD von SDML offenbart und behoben, weil z.B. Dinge nicht vorgesehen waren, die man aber haben wollte.

3. Die dritte Komponente im Spiel ist SVN - und die kritischste, denn mit Versionskontrolle hat ein privater User normalerweise nichts zu tun. Und das muss man leider auch noch von vielen professionellen HTML-Schreibern und Software-Entwicklern sagen. Andererseits sind die verfügbaren Tools zur Nutzung von SVN gerade für grafische Oberflächen mittlerweile sehr ausgereift und einfach zu bedienen. Und da im täglichen Betrieb gerade einmal zwei Kommandos (Update und Commit) relevant sind, sind wir zu der Ansicht gelangt, dass eine Mitarbeit auch nicht an SVN scheitern sollte.

Gewiss: Die Einstiegshürde für Autoren ist damit hoch - definitiv höher, als bei einem Wiki. Aber auch Wikis sind alles andere als einfach zu bedienen, wie ja schon in diesem Thread festgestellt wurde. Außerdem soll ja auch nicht jeder x-beliebige User etwas an der Dokumentation verändern können.

4. Als letzten Punkt: Warum wir SELFHTML komplett neu schreiben wollen, anstatt die alte Version zu aktualisieren? Weil wir in einem Workshop zu der Erkenntnis gelangt sind, dass uns "der alte Scheiß" viel mehr behindert, als es darum ging, ein Konzept zu erstellen, welches unserem Ziel gerecht wird, eine Dokumentation zu schreiben, die nicht nur für Anfänger einen Einstieg schafft, sondern sich auch für Fortgeschrittene und Profis noch als wertvoll erweist - aber natürlich mit anderen Aspekten.

Wir hatten bis zu dieser Entscheidung die alte SELFHTML-8.1.2 auch tatsächlich schon automatisch in SDML konvertiert (es wäre also echt sinnlose Doppelarbeit, wenn jemand diesen Versuch jetzt noch einmal manuell unternähme - die alte Version ist im SVN als Revision 5679 getaggt). Uns war bewußt, dass wir uns damit sehr viel Arbeit machen würden. Deshalb wollten wir uns zunächst auf die drei Kernthemen "HTML", "CSS" und "Javascript" stürzen, zu diesen Einsteigertutorials und Fortgeschrittenen-Doku schreiben. Alle weiteren Themen sollten (und sollen noch) dann dazu kommen, wenn dieses Kerndokument erschienen wäre.

Im Prinzip ist diese gewählte Strategie aus meiner heutigen Sicht auch richtig. Das derzeit betrachtbare mangelhafte Resultat liegt wohl darin begründet, dass wir uns alle die Arbeit tatsächlich nicht so komplex vorgestellt hatten. Selbst zu einem überarbeitenden Copy&Paste der relevanten alten Textpassagen reichte es bislang nicht. Und Begründungen, warum's nicht vorangeht, finden sich, wie Thomas J.S. richtig feststellt, individuell immer ganz leicht.

Der Editor ist dabei nicht das Problem. SVN ist nicht das Problem. Das Problem ist, seinen Hintern für einen Zeitraum von mindestens einer Stunde vor den Rechner zu pflanzen und Text zu tippen, ohne sich dabei ablenken zu lassen.

Aus diesem Grund haben wir in der Redaktion viele nebensächliche Aktivitäten auf Null zurückgefahren. Es gibt kein französisches Forum mehr. Es gibt keine Versuche mehr, die Version 8.1.2 in andere, weitere Sprachen zu übersetzen. Selbst das Lounge-Forum ist seit dem Jahreswechsel geschlossen. Es reicht trotzdem nicht aus.

Und ich stelle mir langsam auch die Frage, ob unsere Strategie, Besucher des Forums, vornehmlich solche mit hohem Antwortaufkommen, in die Redaktion zu rufen, nicht genau der falsche Weg ist. Denn so jemand hält sich doch natürlich sehr viel im Forum auf und ist dadurch gerne abgelenkt. Stefan Münz sieht's ja ähnlich: "Programmierer sollten keine Programmier-Dokus schreiben".

Aber wenn das zuträfe - wie fänden sich dann fachlich ausreichend bewanderte nichtprogrammierende Redakteure?

- Sven Rautenberg