Die Philosophie von »OffSiteEdit«

­Lesedauer 3 - 4 Min.­

Ich erstelle und pflege seit vielen Jahren Webseiten. Von Unternehmen sowie eigene. In den Anfängen des „öff­ent­lich­en WWW“ waren das noch hand­ge­knüpf­te Seiten aus HTML-Befehlen mit über­schau­baren For­ma­tier­ungs­mög­lich­keiten.

In meinem Blog ist ab ca. 20071 sporadisch doku­mentiert, wohin es mich jeweils getrieben hat. Alle von mir teilweise verwendeten „CMS-Platz­hirsche“ (Typo3, Word­press, Joom­la, Dream­weaver,…) waren mir für das angestrebte Ziel immer „viel zu viel“. Deshalb habe ich recht früh, lang und intensiv Contao eingesetzt. Das wuchs sich leider mit der Zeit ebenfalls zu einem (für meine Zwecke unnötig) komplexen System aus.

Für „ein bisschen Webseiten anzeigen“ stellte sich mir immer mehr die Frage, weshalb es dafür eine Datenbank sowie zunehmend komplexere Konfi­gu­ra­tio­nen braucht. Das haben sich andere ebenfalls gefragt, die bei­spiels­weise Pico oder Yellow entwickelt haben. Letzteres gefiel mir besonders: Ohne Bib­lio­theken, riesigen Frameworks oder Megabyte-weise Javascript lassen sich damit fluffige Webseiten erzeugen. Ohne Datenbank, mit ein bisschen PHP, HTML, CSS und Markdown.

Dafür sind meinerseits eine Anzahl „Extensions“ entstanden, die bei GitHUB her­un­ter­ge­la­den werden können. Genau daraus ist über die Zeit be­dauer­lich­er­weise ein stetig größer werdender Konflikt entstanden: Während Yellow für mich ein Werkzeug für die Web­sei­ten­er­stel­lung sein sollte, was eine gewisse Ver­läss­lich­keit und Kontinuität voraussetzt, wurden Updates regelmäßig zum Spieß­ruten­lauf. „Än­der­ungs­do­ku­men­ta­tion“ ist – so der Entwickler – der Programm-Code. Objektiv zweifellos korrekt, für den praktischen Nutzen auf unzähligen Webseiten trotzdem ein „schlechtes Karma“: Die wurden bei Updates regelmäßig „abgeschossen“.

Auf der Suche nach Al­ter­na­ti­ven ist mir (unter anderem) Hugo vor die Füße gefallen. Das fand ich vom Ansatz charmant, allerdings „much too geeky“. Wenn selbst seitenweise Erklärungen einer Erklärung bedürfen, machen ver­gleichs­weise dürftige Ergebnisse nach sehr viel (Zeit-)Einsatz klar: »Du hast andere Hobbies«.

Aus den ver­schie­den­en Eindrücken formte sich die Idee, die vor sich hin dümpelnde Eigen­ent­wick­lung „SpeedMark“ zu „SpeedEdit“ (nie ver­öf­fent­licht) in »OffSiteEdit« auszubauen. Der Anspruch war „bequem und schnell zu Ergebnissen“. Statt voneinander losgelöster Projekte sollte eine Projekt-Zentrale entstehen, die das schnelle Erweitern und Bearbeiten aktueller Projekte von einem Punkt aus ermöglicht.

Der eigentliche Editor selbst ist zurückhaltend. Dem visuelle Feature­ismus von Markdown-Editoren wie Caret oder Typora stehen funk­tio­nal­ere Spe­zia­lis­ten wie WriteMonkey oder der mit­tler­weile leider von der Down­load­seite ver­schwun­den­en „MarkdownEdit“ von Mike Ward gegenüber. Allen ist gemein, dass es dabei „nur ums Markdown“ geht. Was im Kern völlig in Ordnung ist. Im praktischen Gebrauch sind im Anschluss weitere Werkzeuge er­for­der­lich, damit aus dem Text eine Webseite wird.

Dafür sind – für mich – technische Aspekte relevanter als wohlgeformter Editor-Text. Zweifellos soll der Text einer Webseite das Wesentliche sein. Für seine gelungene Prä­sen­ta­tion sind verknüpfte Dateien, Quer­ver­weise,…, bei der Erstellung wichtig. Daher ist »OffSiteEdit« ein Pro­gram­mier-Editor mit den dafür typischen Funktionen (Sprung­marken, Zeilen schieben, …), ergänzt um Schreib­hilfen, wie Wort­wieder­ho­lun­gen, Ko­rrek­tur­un­ter­stüt­zung, …, und ein „Upload-Manager“, der automatisch dafür sorgt, dass lokal verknüpfte Information tatsächlich verfügbar ist.

Das Projekt »OffSiteEdit« ist „im Fluss“ – mir schwirren noch diverse Er­wei­ter­ungs­ideen durch den Kopf. Doch bei all dem bleibt der eigentliche Grund der Entwicklung im Fokus: Das Ergebnis. Im konkreten Fall sind das die Webseiten, die damit erstellt und gewartet werden (sollen).

Ein per­sön­liches Ziel ist, dafür ohne externe Bib­lio­the­ken, Frameworks, sowie best­möglich ohne Javascript auszukommen. Das macht die Webseiten unabhängig von externen Servern. Außerdem erhalten „Bib­lio­theks­an­bie­ter“ keine Auskünfte über meine Webseiten-Be­such­en­den und mich, die erzeugten Seiten lassen sich einfacher gegen böse Buben abschotten, … .

Ent­wick­lungs­sei­tig macht es mich frei: Niemand fährt mir mit einem Update dazwischen, das seinerseits wohl­über­legt sein kann, mir aber einen Berg Arbeit macht, ohne dass es am wahrnehmbaren Ergebnis etwas ändert: Von vorne betrachtet sehen die Webseiten mit ak­tu­ali­sier­ter CMS-Engine am Ende genauso aus wie vorher. Was es schwierig macht, Kunden einen Aufwand von teilweise mehreren Tagen (!) darzustellen (s.o. „Hobbies“…).

Da sich dieser Aufwand mit der Anzahl betreuter Webseiten multi­pli­ziert, erschien der (Zeit-)Einsatz für eine eigene „Webseiten-Software“ attraktiv, denn: Es wird die Folge­auf­wände reduzieren. Jede mit »OffSiteEdit« erzeugte Seite „steht für sich“. Selbst wenn in Teilen des Webaurtritts Änderungen erfolgen (können), bleiben die vorhandenen Seiten davon unberührt. Was fraglos eine gewisse Weitsicht bei der Planung erfordert: Genau das kann bei umfangreicheren Änderungen Aufwände auslösen. Schlimm­sten­falls müssen (momentan noch) alle Seiten von Hand neu generiert werden. Es fehlt die Funktion „alles neu“ (eine weitere Idee für den Stapel). Er­fah­rungs­gemäß ist das jedoch selten bis nie erforderlich. Ständiges „botoxen“ einer Seite verwirrt Kunden eher, als dass es neue In­te­res­sen­ten gewinnt.

Das (unbearbeitete) Bild stammt von Pixabay.

1Der Blog als solches ist erst 2013 entstanden. Aus organisatorischen Gründen wurden Meldungen der Homepage NoSi.de aus der Zeit davor dorthin überführt.