Kurz gesagt: Die kollaborative Bearbeitung erfordert nicht unbedingt ein umfassendes Content-Management-System oder eine neue Infrastruktur. Auch bei einer statischen Website lässt sich eine über den Browser bedienbare Bearbeitungsoberfläche hinzufügen, wobei die Inhalte weiterhin in der Datenquelle des Projekts in einer versionierbaren Form verbleiben. Das ist der Kern der schrittweisen Entwicklung: Wir integrieren nur die Funktionen, die das Team benötigt, und bewahren dabei die Funktionsfähigkeit und Portabilität der bestehenden Website.
Warum entsteht der Bedarf an kollaborativer Bearbeitung?
Statische Websites sind in vielen Projekten deshalb attraktiv, weil sie aus wenigen beweglichen Teilen bestehen. Der Inhalt wird im Voraus erstellt, und die Website stellt fertige Dateien bereit. Dies kann die Komplexität der Infrastruktur während des Betriebs verringern und die Installation vereinfachen. Die statische Struktur löst jedoch nicht alle Bearbeitungsaufgaben.
Wenn ein Redaktionsteam häufig Überschriften, Beschreibungen oder Seitenabschnitte aktualisiert, kann der Entwicklungsworkflow leicht zu einem Engpass werden. Die Redakteure möchten nicht unbedingt Markdown-Dateien bearbeiten, Git-Operationen durchführen oder für jede noch so kleine Änderung die Hilfe von Entwicklern in Anspruch nehmen. Die Entwickler wiederum möchten nicht wegen eines einzigen Bearbeitungsbedarfs ein völlig neues, schwer zu wartendes System einführen.
Hier zeigt sich der Bedarf an kollaborativer Bearbeitung. Es geht nicht nur darum, wie man Text auf einer Seite umschreiben kann. Es muss auch geklärt werden, wo die Änderung gespeichert wird, wie sie in das Projekt übernommen wird und was passiert, wenn die Bearbeitungsoberfläche später nicht mehr benötigt wird.
Vorteile und Grenzen der statischen Architektur
Ein wichtiger Vorteil statischer Websites besteht darin, dass zur Bedienung der Besucher nicht bei jeder Anfrage zwangsläufig Anwendungscode ausgeführt werden muss. Dies kann zu einem einfacheren Betrieb führen und die Abhängigkeiten der Website während des Betriebs verringern. Die konkreten Ergebnisse in Bezug auf Sicherheit und Leistung hängen jedoch immer von der Umsetzung, dem Hosting und den verwendeten Diensten ab.
Das Hinzufügen dynamischer Funktionen kann neue Komponenten in das System einbringen. Dazu können beispielsweise ein serverloser Endpunkt, eine externe Datenbank oder ein JavaScript-basierter Dienst gehören. Diese können nützlich sein, erfordern jedoch möglicherweise Konfiguration, Wartung und Kostenüberwachung. Auch die Zusammensetzung des Datenverkehrs spielt eine Rolle: So kann beispielsweise Bot-Verkehr die Auslastung von nutzungsbasierten Infrastrukturen beeinflussen.
Das bedeutet nicht, dass alle dynamischen Funktionen vermieden werden sollten. Es bedeutet vielmehr, dass es sinnvoll ist, die erforderliche Funktionalität als möglichst kleine, klar abgegrenzte Schicht einzuführen. Kollaboratives Bearbeiten passt gut zu einem statischen Projekt, wenn es das Team nicht dazu zwingt, die gesamte Architektur zu ersetzen.
Was bedeutet „progressive Entwicklung“ im Bereich der Redaktion?
„Progressive Entwicklung“ bedeutet in diesem Zusammenhang, dass die Grundfunktionalität der Website auch eigenständig erhalten bleibt, während die Bearbeitungsoberfläche als zusätzliche Funktion daran gekoppelt ist. Der Inhalt stammt weiterhin aus der Datenquelle des Projekts. Die Bearbeitungsoberfläche ermöglicht nur die Bearbeitung der zuvor festgelegten Daten.
Dieser Ansatz kann besonders in Teams nützlich sein, in denen die Entwickler für die Vorlagen und die Infrastruktur zuständig sind, während andere Mitarbeiter die Inhalte aktualisieren. So können beide Rollengruppen am selben Projekt arbeiten, ohne dass alle dieselben Tools verwenden müssen.
- Der Entwickler legt fest, welche Datenfelder bearbeitet werden können.
- Der Redakteur ändert die angezeigten Inhalte im Browser.
- Das Projekt Die Änderung wird in der ursprünglichen Datenquelle und im Versionsverwaltungsprozess gespeichert.
Die genaue Funktionsweise hängt vom verwendeten Tool und den Projekteinstellungen ab. Ein wichtiger Gestaltungsgrundsatz ist, dass die Bearbeitungsschicht nicht zur einzigen Funktionsgrundlage der Website wird.
Ein einfaches Beispiel: bearbeitbare Überschrift
Nehmen wir an, eine Markdown-Datei enthält den Titel einer Seite. Die Vorlage zeigt diesen Wert den Besuchern an. Eine Bearbeitungsschicht kann es einem berechtigten Teammitglied ermöglichen, den Titel im Browser zu ändern, während die Änderung in der Datenkaskade des Projekts erhalten bleibt.
Beispielsweise verwendet die Seite zunächst den Wert „Welt”. Die Vorlage zeigt diesen Wert in der Kopfzeile an. Der Bearbeiter ändert den Wert in „Mond”. Wenn das Projekt diese Angabe an mehreren Stellen verwendet, wird die Änderung an allen Stellen wirksam, an denen auf denselben Wert verwiesen wird.
Dieses Beispiel veranschaulicht ein mögliches Funktionsmodell, stellt jedoch keine allgemeine Garantie dar. Der tatsächliche Bearbeitungsprozess hängt von der API des Tools, den Berechtigungen und der Art und Weise ab, wie das Projekt Änderungen verwaltet. Vor der Einführung sollte daher überprüft werden, aus welchen Schritten das Speichern, die Versionierung und die Veröffentlichung genau bestehen.
Warum ist es wichtig, dass die Änderung in der ursprünglichen Datenquelle verbleibt?
Wenn die Bearbeitungsschicht die Datenquelle des Projekts direkt ändert, gelangt der Inhalt nicht unbedingt in ein separates, schwer zu exportierendes System. Die Änderungen können in den bestehenden Versionsverwaltungsprozess des Projekts eingebunden werden. Dies kann mehr Transparenz darüber schaffen, was sich geändert hat, und die Übersicht über die Änderungen erleichtern.
Die Versionsverwaltung allein ist kein Ersatz für eine angemessene Berechtigungsverwaltung oder die Kontrolle der Veröffentlichung. Das Team muss festlegen, wer Änderungen vornehmen darf, wer diese genehmigen darf und auf welche Weise neue Inhalte auf die Live-Website gelangen. Diese Regeln müssen an die Funktionen des Tools und die Arbeitsabläufe der Organisation angepasst werden.
Die Nähe zur Datenquelle ist auch im Hinblick auf die Portabilität wichtig. Sollte die Bearbeitungsoberfläche später nicht mehr benötigt werden, kann das Projekt weiterhin mit Open-Source-Tools zur Erstellung statischer Webseiten betrieben werden, sofern der Projektcode und seine Abhängigkeiten dies zulassen. Vor der Auswahl sollte geprüft werden, ob die Bearbeitungsschicht so entfernt werden kann, dass der Inhalt und die Vorlagen erhalten bleiben.
Build Awesome Pro: Bearbeitungslayer für bestehende Projekte
In der ursprünglichen Beschreibung wird Build Awesome Pro als Website-Baukasten vorgestellt, der statische Ausgaben mit einer browserbasierten kollaborativen Bearbeitung kombiniert. Das dargestellte Ziel besteht darin, dem Team Bearbeitungsmöglichkeiten für das Projekt zu bieten, ohne dessen grundlegende Struktur zwangsläufig zu verändern.
Der Beschreibung zufolge kann die statische Ausgabe des Projekts in Git versioniert und an verschiedenen Orten installiert werden. Der Benutzer kann auch ein bestehendes Projekt einbinden oder aus den verfügbaren Startvorlagen auswählen. In der Anleitung wird die Kompatibilität mit Eleventy-Projekten und dem Eleventy-Ökosystem besonders hervorgehoben. Diese Funktionen sollten anhand des jeweiligen Projekts und der aktuellen Produktdokumentation überprüft werden.
In dem vorgestellten Modell bindet die Bearbeitungsfunktion die Website nicht zwangsläufig an einen einzigen Hosting-Anbieter. Das Projekt kann auf der eigenen Infrastruktur bearbeitet und die Website anschließend in der gewählten Umgebung betrieben werden. Laut Produktbeschreibung kann der Betrieb optional auch auf der Infrastruktur des Dienstanbieters erfolgen. Für eine praxisnahe Entscheidung empfiehlt es sich, die Exportierbarkeit, die Abhängigkeiten, das Berechtigungsmodell und die bestehenden Arbeitsabläufe des Teams zu prüfen.
Vor der Einführung zu klärende Entscheidungskriterien
Die Einführung der kollaborativen Bearbeitung ist dann sinnvoll, wenn dadurch ein echtes Problem im Arbeitsablauf gelöst wird. Nicht jede statische Website benötigt einen im Browser nutzbaren Editor. Wenn sich die Inhalte nur selten ändern und der derzeitige Prozess gut funktioniert, kann eine neue Ebene nur zusätzlichen Wartungsaufwand bedeuten.
Bevor man eine Entscheidung trifft, sollte man sich einige konkrete Fragen stellen:
- Welche Daten müssen bearbeitet werden? Legt die genauen Felder und Seitenbereiche fest.
- Wer darf Beiträge bearbeiten? Klären Sie die Rollen und Zugriffsebenen.
- Wie genehmigt ihr die Änderungen? Entscheidet bitte, ob die Änderung sofort veröffentlicht werden kann oder noch geprüft werden muss.
- Wo werden die Inhalte gespeichert? Bitte überprüft, ob die Änderungen in der vorgesehenen Datenquelle und im Versionsverwaltungsprozess berücksichtigt wurden.
- Was passiert, wenn das Gerät entfernt wird? Prüft bitte, ob das Projekt auch ohne die Bearbeitungsschicht weiterhin kompiliert und installiert werden kann.
Diese Fragen helfen dabei, den tatsächlichen Bearbeitungsbedarf von unnötigen Infrastrukturerweiterungen zu unterscheiden. Eine gute Lösung bietet nicht unbedingt die meisten Funktionen. Die richtige Lösung ist die, die zur Arbeitsweise des Teams passt und spätere Änderungen am Projekt nicht unnötig erschwert.
Wie passt das alles zur Zusammenarbeit der Entwickler?
Die gemeinsame Bearbeitung ist nicht nur eine Komfortfunktion. Sie kann auch die Aufgabenteilung zwischen den Entwicklern und den für die Inhalte zuständigen Mitarbeitern neu gestalten. Die Entwickler können sich auf die Vorlagen, das Datenmodell und die funktionalen Rahmenbedingungen konzentrieren. Die Redakteure hingegen können die Inhaltselemente, die ihnen im Rahmen des Projekts zur Verfügung stehen, eigenständiger bearbeiten.
Dazu sind klare Grenzen erforderlich. Die Kennzeichnung bearbeitbarer Felder bedeutet nicht, dass jeder Teil der Seite veränderbar sein muss. Vorlagen, die Navigation, technische Metadaten und geschäftlich sensible Inhalte erfordern möglicherweise unterschiedliche Kontrollmechanismen. Das Team muss daher im Voraus festlegen, für welche Änderungen die Genehmigung durch Entwickler oder Redakteure erforderlich ist.
Sind diese Grenzen klar definiert, kann die Bearbeitung im Browser den technischen Aufwand für kleinere inhaltliche Änderungen verringern. Sind hingegen die Berechtigungen und der Veröffentlichungsprozess unklar, kann die Bearbeitungsoberfläche neue Unsicherheiten mit sich bringen. Der Erfolg der Einführung hängt daher nicht nur von der API ab. Auch der Arbeitsablauf muss geplant werden.
Was passiert, wenn der Bearbeitungsbedarf später entfällt?
Ein wichtiger Maßstab für progressive Entwicklung ist die Entfernbarkeit. Wenn das Projekt später keine kollaborative Bearbeitung mehr erfordert, sollte die Website nach Möglichkeit weiterhin mit den zugrunde liegenden Tools erstellt werden können. Inhalte und Vorlagen dürfen nicht unnötig an eine einzige Oberfläche gebunden sein.
In der Beschreibung von „Build Awesome Pro“ heißt es, dass das Projekt nach dem Entfernen der Bearbeitungsschicht mit der Open-Source-Engine an einem Ort nach Wahl weiterentwickelt werden kann. Dies ist das in der Produktbeschreibung genannte Ziel. Vor der Einführung muss das Team jedoch anhand seines eigenen Projekts überprüfen, welcher Code, welche Konfiguration oder welche Abhängigkeiten im System verbleiben.
Es lohnt sich, den gesamten Lebenszyklus auf einer kleinen Testseite zu testen: die Bearbeitung, die Freigabe, die Versionsverwaltung, die Installation und schließlich das Entfernen der Bearbeitungsschicht. So lässt sich bereits vor einer breiteren Einführung feststellen, ob die Lösung den Anforderungen an die Portabilität entspricht.
Zusammenfassung: Die Bearbeitung sollte eine Ergänzung sein, keine erzwungene Neugestaltung.
Die kollaborative Bearbeitung lässt sich auch auf einer statischen Website umsetzen, wobei das Projekt seine bestehende Datenquelle, seinen Versionsverwaltungsprozess und seine Installationsfreiheit beibehält. Entscheidend ist, dass die Bearbeitungsoberfläche gezielt neue Funktionen hinzufügt, anstatt das gesamte System unnötig zu ersetzen.
Die Beschreibung von Build Awesome Pro bietet folgenden Ansatz: statische Ausgabe, Unterstützung bestehender Projekte und Bearbeitungsmöglichkeiten direkt im Browser. Prüfen Sie vor Ihrer Entscheidung die Kompatibilität, die Berechtigungen, die Versionsverwaltung der Änderungen und ob das Projekt auch ohne die Bearbeitungsschicht funktionsfähig bleibt.
Nächster Schritt: Wählen Sie eine kleine Seite oder einen Inhaltsbereich mit geringem Risiko aus und testen Sie dort den gesamten Prozess der Bearbeitung, Freigabe und Veröffentlichung.