Die Entstehungsgeschichte

🔍

✖

Es war zum Haare raufen, bis ein entscheidender Anstoß erfolgte.

Ich erstelle und pflege seit vielen Jahren Webseiten. Von Unternehmen sowie eigene. In den Anfängen des „öffentlichen WWW“ waren das handgeknüpfte HTML-Seiten, mit überschaubaren Formatierungsmöglichkeiten.

Ab ca. 20071 ist in meinem Blog sporadisch dokumentiert, wohin es mich jeweils getrieben hat. Alle „CMS-Platzhirsche“ (Typo3, Wordpress, Joomla, Dreamweaver,…) waren für das angestrebte Ziel meistens »viel zu viel«. Deshalb war Contao ab Version 1 lange das Werkzeug meiner Wahl. Doch das wurde mit der Zeit für den Zweck ebenfalls unnötig komplex.

Für ein bisschen Webseiten anzeigen stellte sich zunehmend die Frage, weshalb das eine Datenbank sowie aufwendige Konfigurationen erfordert. Das haben sich andere ebenfalls gefragt, die beispielsweise Pico oder Yellow entwickelt haben. Letzteres gefiel mir besonders: Auch ohne Bibliotheken, riesigen Frameworks oder Megabyte-weise Javascript, lassen sich damit fluffige Webseiten erzeugen. Ohne Datenbank, mit ein wenig PHP, HTML, CSS und Markdown.

Dafür sind meinerseits eine Anzahl „Extensions“ entstanden, die weiterhin bei GitHub heruntergeladen werden können, mittlerweile jedoch hoffnungslos veraltet sein dürften. Aus diesen „Extensions“ ist ein stetig größer werdender Konflikt entstanden: Während Yellow für mich ein Webseiten-Werkzeug sein sollte, was eine grundlegende Verlässlichkeit und Kontinuität voraussetzt, wurden Updates zunehmend ein Spießrutenlauf. Der Programm-Code als einzige „Änderungsdokumentation“ (lt. des Entwicklers) ist für den praktischen Gebrauch „schlechtes Karma“: Bei Updates wurden Webseiten regelmäßig „abgeschossen“.

Auf der Suche nach Alternativen fiel mir (unter anderem) Hugo vor die Füße. Charmanter Ansatz, doch „way too geeky“. Wenn selbst seitenweise Erklärungen einer Erklärung bedürfen, machen vergleichsweise dürftige Ergebnisse nach intensivem (Zeit-)Einsatz klar:

Als ich Ende 2020 im Gespräch mit meinem Bruder Harald meinem Unmut darüber freien Lauf ließ, kommentierte der trocken: „Schreib doch selbst was. Kannste doch.“

Ein naheliegender Vorschlag, der bei mir jedoch erst durch diesen Seitenhieb konkrete Formen annahm. Verschiedene Eindrücke entwickelten sich auf Basis eines vorhandenen, experimentellen „proof of concept“, eines eigenen Editors (SpeedMark), zu einem konkreten „Werkzeug“:  OSE .

Der Anspruch:

• (für mich) bequem,
• zuverlässig,
• schnell belastbare, solide Ergebnisse.

Ein besonderer Aspekt dabei war, dass statt voneinander unabhängiger Projekte eine Projekt-Zentrale das Erstellen, Bearbeiten, Erweitern und Verwalten meiner Web-Projekte von einem Punkt aus ermöglichen sollte.

Der „Editor-Teil“ wurde und ist deshalb zurückhaltend. Dem visuellen Featureismus von Markdown-Editoren wie Caret oder Typora stehen funktionale Spezialisten wie WriteMonkey oder der mittlerweile leider von der Downloadseite verschwundenen „MarkdownEdit“ von Mike Ward gegenüber. Allen ist gemein, dass Markdown im Fokus steht. Damit eine Webseite daraus wird, sind im Anschluss weitere Werkzeuge erforderlich.

Für mich ist der gesamte „Erstellungsprozess Webseite“ relevant. Schicker Editortext ist dafür zu wenig. Der Inhalt einer Webseite, genauer: das Ergebnis auf dem Server, ist das Wesentliche. Für eine gelungene Präsentation sind verknüpfte Dateien, Querverweise,... bei der Erstellung wichtig.  OSE  ist funktional, ein „Programmier-Editor“, mit dafür typischen Funktionen (Sprungmarken, Zeilen schieben, …), ergänzt um „Schreibhilfen“, wie Wortwiederholungen anzeigen, Korrektur-Unterstützung, je nach Sichtweise schrägen oder ausgefuchsten Zusatzfunktionen und einem „intelligenten Site-Manager“, der automatisch dafür sorgt, dass lokal verknüpfte Information auf dem Server des jeweiligen Projekts verfügbar ist.

Die ursprünglich formulierten Anforderungen waren überraschend schnell erfüllt. Die ersten Webseiten wurden bereits Anfang 2021 „umgerüstet“. Seither sind diverse weitere Funktionen hinzugekommen. Das ist der Vorteil einer Eigenentwicklung: Wenn was fehlt, liegt es in den eigenen Händen, ob das so bleibt. Das führt teilweise dazu, dass mitten in der Bearbeitung einer Webseite  OSE  geschlossen wird (merkt sich ja alles …), die Entwicklungsumgebung hochfährt, eine Funktion ergänzt, die Programmdatei in die Arbeitsumgebung kopiert und die Webseite mit der neuen Funktion fertiggestellt wird.

Konzeptionell ist  OSE  immer „abwärtskompatibel“, weshalb „dynamisches Weiterentwickeln“ keine Auswirkung auf bestehende Projekte hat. Das liegt primär daran, dass damit Webseiten ohne externe Bibliotheken, Frameworks, sowie fast immer ohne Javascript erstellt werden können, die trotzdem modern und schick sind. Das macht sie unabhängig von externen Servern, „Bibliotheksanbieter“ erhalten keine Auskünfte über Webseitenbesucher und Betreiber, die erzeugten Seiten lassen sich mit geringem Aufwand gegen böse Buben abschotten, sie sind schlank und deshalb Wiesel-flink.

Dieser Ansatz macht bei der Entwicklung von Webseiten frei: Niemand verändert mit einem Update oder einer angepassten, von sonst woher nachgeladenen Bibliothek erstellte Webseiten. Was wohlüberlegt und mit besten Absichten erfolgt sein kann, hat für mich in der Vergangenheit ohne erkennbaren Nutzen regelmäßig einen Haufen Arbeit verursacht.

🔍

✖

Alles halb so wild – sobald die ersten Schritte gegangen sind …

„Aufwand x Anzahl betreuter Webseiten“ relativierte die Bedenken vor dem Entwicklungsaufwand einer eigenen „Webseiten-Software“. Mittlerweile ist gesichert:

Jede mit  OSE  erzeugte Seite „steht für sich“. Selbst wenn in Teilen des Webauftritts Änderungen erfolgen (können), bleiben die vorhandenen Seiten davon unberührt. Was dennoch eine gewisse Weitsicht bei der Planung zweckmäßig macht: Genau das könnte andernfalls bei umfangreicheren Änderungen Aufwände auslösen.

Mittlerweile gibt es dafür eine Funktion: „Projekte → Projektverwaltung → Projekt neu generieren“ erzeugt in einem Zug das komplette Projekt neu. Was selbst mehrere Hundert Seiten umfassende Webseiten zügig „auf Stand“ bringt. Die Funktion ist gut für den eigenen Seelenfrieden, weil sich damit unter anderem Änderungen in Modulen auf alle Seiten, in denen das Modul verwendet wird, übertragen lassen. Was »vorn« selten eine sichtbare Änderung nach sich zieht: Ständiges „botoxen“ einer Seite verwirrt Kunden eher, als dass es neue Interessenten gewinnt. Weshalb dieser „Minimalaufwand“ für solche Änderungen umso bedeutsamer ist.

Meine Bearbeitungsgeschwindigkeit hat mit  OSE  signifikant zugenommen. Seit dem Umstieg gab es keine „Totalausfälle“ mehr. Kunden erfreut das in mehrfacher Hinsicht:

Wartungs- und Bearbeitungsaufwand wird von mir „nach Zeit“ abgerechnet. Aus betriebswirtschaftlicher Sicht ist die signifikant höhere Performance durch und mit  OSE  „suboptimal“. Gewonnene Freizeit, sowie andere Effekte wiegen das jedoch um ein Vielfaches auf.