Hintergrund

🔍 Es ist manchmal zum Haare raufen…

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 aufwändige Konfigurationen erfordert. Das haben sich andere ebenfalls gefragt, die beispielsweise Pico oder Yellow entwickelt haben. Letzteres gefiel mir besonders: Ohne Bibliotheken, 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 weiterhin bei GitHUB heruntergeladen werden können, mittlerweile aber hoffnungslos veraltet sein dürften. Denn aus den „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“ 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:

Du hast noch andere Hobbies.

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.“

Eine 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 ein konkreten „Werkzeug“: OffSiteEdit.

Der Anspruch:

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

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

Der „Editor-Teil“ ist deshalb zurückhaltend. Dem visuelle 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 dagegen der Erstellungsprozess relevanter als schicker Editortext. Der Inhalt einer Webseite ist das Wesentliche. Für eine gelungene Präsentation sind verknüpfte Dateien, Querverweise,…, bei der Erstellung wichtig. OffSiteEdit ist funktional, ein Programmier-Editor“ mit dafür typischen Funktionen (Sprungmarken, Zeilen schieben, …), ergänzt um „Schreibhilfen“, wie Wortwiederholungen, Korrektur-Unterstützung, je nach Sichtweise schrägen bzw. 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 Anfang 2020 „umgerüstet“. Seither sind diverse weitere Funktionen hinzu gekommen. 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 einer Webseite OffSiteEdit 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 fertig gestellt wird.

Konzeptionell ist OffSiteEdit 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.

Entwicklungsseitig macht es frei: Niemand verändert mit einem Update oder einer angepassten, von sonstwoher 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 …

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

Doch mittlerweile gibt es dafür einen Affengriff2: Mit Shift Ctrl Alt F4 wird in einem Zug das komplette Projekt neu generiert. Was im Test selbst mehrere hundert Seiten umfassende Webseiten in sehr kurzer Zeit „auf Stand“ bringt. Die Funktion ist gut für den eigenen Seelenfrieden, weil sich damit beispielsweise Änderungen in Modulen in einem Zug durchstechen lassen. Was »vorne« selten eine sichtbare Änderung nach sich zieht: Ständiges „botoxen“ einer Seite verwirrt Kunden eher, als dass es neue Interessenten gewinnt. Weshalb dieser „Minimalaufwand“ solcher Änderungen umso bedeutsamer ist.

Meine Bearbeitungsgeschwindigkeit hat mit OffSiteEdit signifikant zugenommen. Seit dem Umstieg hatte ich keine „Totalausfälle“ mehr. Kunden freut's: Wartungs- und Bearbeitungsaufwand wird von mir „nach Zeit“ abgerechnet. Aus betriebswirtschaftlicher Sicht „suboptimal“, doch gewonnene Freizeit, sowie andere Effekte wiegen das vielfach auf.