Ein modernes Frontend zu bauen, ist nicht das Schwierige. Anspruchsvoll wird es, wenn es in ein System muss, das seit Jahren produktiv läuft und parallel weiterentwickelt wird. Genau das ist die Aufgabe beim Relaunch von Campus Events, der Veranstaltungsplattform von Academic Hero, den ich als freiberuflicher Berater und Entwickler seit über sechs Monaten konzipiere und umsetze. Nach außen geht es um ein neues Erscheinungsbild und mehr Gestaltungsfreiheit für Kunden. Die eigentliche Arbeit steckt im Weg dorthin.
Woher das Projekt kommt
Campus Events ist ein etabliertes Produkt mit gewachsener Codebasis, vielen Kundeninstallationen und laufendem Betrieb, technisch auf Basis von PHP mit Symfony und TypeScript. Stabil und bewährt, aber Gestaltung und Technik sind in die Jahre gekommen. Alle Kunden teilen sich im Kern dasselbe Layout. Individualisieren ließ es sich nur über wenige Einstellungen wie zwei Farben, eine Schriftart und ein Logo. Dazu kamen eine eingeschränkte mobile Nutzbarkeit und Lücken bei der Barrierefreiheit.
Gerade der letzte Punkt wiegt schwer: Die Plattform wird überwiegend von Hochschulen eingesetzt, und für öffentliche Stellen ist Barrierefreiheit keine Kür, sondern rechtlich vorgegeben. Die technische Grundlage dafür bilden die WCAG.
Zur Einordnung: Die Richtlinie (EU) 2016/2102 verpflichtet öffentliche Stellen zur Barrierefreiheit ihrer Websites; die Umsetzung in nationales Recht unterscheidet sich je nach Zuständigkeit, etwa im Bund über die BITV 2.0 und bei Hochschulen über das jeweilige Landesrecht. Als technischer Maßstab verweist die europäische Norm EN 301 549 für Webinhalte auf die WCAG 2.1 auf Niveau AA.
Wohin es gehen soll
Zu Beginn stand die Frage, woran sich der Projekterfolg erkennen lässt. Die Antwort war ein Satz:
„Ein Frontend, das Nutzer begeistert, Kunden befähigt und das Produkt skalierbar macht.“
Daraus habe ich gemeinsam mit dem Auftraggeber abgeleitet, was zum Projekt gehört und was bewusst nicht, etwa neue Features oder Sonderentwicklungen pro Kunde.
Eine Zielsetzung braucht konkrete Kriterien, an denen sich ihr Erfolg überprüfen lässt. Manche davon lassen sich messen. Die automatisierten Tests erwarten bei Lighthouse, dem Prüfwerkzeug von Google für Webseiten, 100 Punkte in den Kategorien SEO, Barrierefreiheit und Best Practices. Bei der Performance liegt die Schwelle bei 90 Punkten, weil dieser Wert von Messung zu Messung schwanken kann. Hinzu kommen Barrierefreiheit nach WCAG 2.1 auf Niveau AA und fehlende Regressionen. Beim visuellen Design entscheiden dagegen Menschen. Dafür braucht es enge Zusammenarbeit, Iterationen und Kundenfeedback.
Der Weg
Ein Ansatz mit Balance. Für das Ziel gab es mehrere Wege, vom reinen Facelift bis zum freien Baukasten für Kunden. Nach einer Abwägung von Nutzen, Risiko und Aufwand fiel die Wahl auf feste Templates für den Aufbau der Seiten und ein frei konfigurierbares Design für Farben, Schriften und Details. Das gibt den Kunden Spielraum, ohne dass Pflege und Tests unbeherrschbar werden.
Schrittweise statt Big Bang. Ein harter Wechsel an einem Stichtag kam für ein produktives System nicht infrage. Das neue Frontend entsteht deshalb als eigenes Layout neben dem bisherigen, und zwischen beiden lässt sich per Konfiguration umschalten. Die Fachlogik dahinter bleibt unangetastet: Formulare, Buchungs- und Bestellprozesse, das serverseitige Rendering und die Einbettung von Veranstaltungslisten auf Kundenwebseiten funktionieren wie bisher. Eine Datenmigration ist nicht nötig, und der Weg zurück zum bestehenden Frontend bleibt jederzeit offen.
Ein entkoppeltes Headless-Frontend wäre die naheliegende Alternative gewesen. Es hätte aber einen deutlich größeren Umbau im Backend, einen vollständigen API-Ausbau und neue Anforderungen an die Infrastruktur der Kunden bedeutet, ohne für diesen Umfang einen entsprechenden Mehrwert zu bringen.
Inkrementell und agil. Das Ergebnis wächst in kleinen, regelmäßig geprüften Schritten, statt am Anfang in einem umfangreichen Lasten- und Pflichtenheft festgelegt zu werden. Das setzt gegenseitiges Vertrauen voraus, erlaubt aber, jederzeit nachzusteuern, wenn sich Anforderungen ändern oder neue Erkenntnisse dazukommen.
KI-Agenten mit Leitplanken. Im Projekt arbeite ich mit KI-Agenten. Sie übernehmen vor allem Analyse und Validierung. Wo neue, fest definierte Strukturen entstanden sind, setzen sie auch um. Entscheidend ist dabei weniger das Werkzeug als der Rahmen: Klare Projektregeln und beschriebene, wiederkehrende Arbeitsabläufe geben vor, wie gearbeitet wird. Die abschließende Prüfung und die fachliche Entscheidung bleiben beim Menschen. Das Sicherheitsnetz dahinter ist eine automatisierte Testabdeckung, die es vorher nicht gab und die erst im Projekt eingeführt wurde. End-to-End-Tests durchlaufen zentrale Abläufe wie Registrierung, Checkout oder Stornierung im Browser, und zwar im bisherigen wie im neuen Layout. Für die Barrierefreiheit kommen reine Tastaturdurchläufe und automatisierte Prüfungen gegen WCAG 2.1 A/AA hinzu.
Die Hürden unterwegs
Zwei Frontends gleichzeitig. Der schrittweise Weg hat seinen Preis: Zwei Frontends nebeneinander zu betreiben, erzeugt Pflegeaufwand, und das System wird parallel weiterentwickelt. Was dagegen hilft, sind eine klare Trennung von Alt und Neu und automatisierte Tests, die dieselben Abläufe gegen beide Layouts prüfen und unbeabsichtigte Fehler früh sichtbar machen.
Mehr Freiheit, ohne Chaos. Mehr Stellschrauben bedeuten schnell mehr Komplexität für die Administration. Allein das neue Layout erlaubt rechnerisch mehrere Milliarden Kombinationen von Einstellungen. Die Antwort darauf ist ein zentral gepflegtes Design in zwei Ebenen: Ein Grundwert wie die Markenfarbe wird einmal gesetzt und wirkt automatisch an allen davon abhängigen Stellen. Wo es nötig ist, lässt sich ein abgeleiteter Wert bewusst überschreiben. Änderungen werden zunächst als Entwurf gespeichert und lassen sich in einer Vorschau prüfen, bevor Besucher sie sehen.
Barrierefreiheit trotz freier Gestaltung. Wenn Kunden eigene Farben hinterlegen können, wird Barrierefreiheit schwerer. Regeln für Struktur, Fokus und Bedienbarkeit lassen sich einmal in den Komponenten verankern und automatisiert prüfen. Eine Grenze bleibt: Die automatisierten Prüfungen laufen gegen die Standardgestaltung. Ob die Farben, die ein Kunde konkret wählt, genug Kontrast haben, bleibt eine manuelle Prüfung und liegt aktuell in der Verantwortung der Pflegenden. Eine automatische Kontrastwarnung im Admin-Bereich gibt es bewusst noch nicht: Weil eine Farbe an vielen Stellen und in unterschiedlichen Kombinationen wirkt, wäre eine verlässliche Prüfung derzeit fehleranfällig.
Erwartungen im Blick behalten. Bei Usability und Design zählt das Feedback der Nutzer. Deshalb war von Beginn an eine Pilotierungsphase eingeplant: Ausgewählte Kunden testen den Zwischenstand auf eigenen Testsystemen, bevor er für alle erscheint. Wichtig ist dabei, Erwartungen klar zu setzen: Die Pilotierung zeigt einen gereiften Zwischenstand und kein Endprodukt, und nicht jeder Wunsch wird automatisch umgesetzt.
Was die Pilotierung zeigt
Aktuell befinden wir uns in der Pilotphase, und die ersten Ergebnisse werden ausgewertet. Zwei Rückmeldungen von Pilotkunden sind mir dabei besonders positiv aufgefallen:
„Wir haben uns ohne Dokumentation zurechtgefunden.“
„Man möchte gar nicht mehr auf das alte Layout wechseln.“
Beide passen zu dem, was das Projekt erreichen sollte: ein Frontend, das Kunden selbst einrichten können und das Nutzer gerne verwenden. Ein abschließendes Urteil ist das noch nicht. Aus der Pilotierung kommen ebenso Fragen und Verbesserungsvorschläge. Sie werden eingeordnet, als Fehler, Wunsch oder Thema für später, priorisiert und fließen gezielt in die weitere Arbeit am Release ein.
Warum sich der Weg lohnt
Ein solcher Relaunch ist anspruchsvoller als ein Neubau auf der grünen Wiese: Altsystem, neue Architektur und Qualitätssicherung müssen gleichzeitig im Blick bleiben. Dafür steht am Ende mehr als ein neues Erscheinungsbild. Der Umstieg kommt ohne Datenmigration aus, der Weg zurück zum bisherigen Layout bleibt offen, und die Testabdeckung, die im Projekt entstanden ist, bleibt dem Produkt über den Relaunch hinaus erhalten.
Das moderne Frontend ist der sichtbare Teil. Die eigentliche Aufgabe ist, es im laufenden Betrieb zu integrieren.
Solche Modernisierungen gewachsener Systeme im laufenden Betrieb sind ein wesentlicher Teil meiner Arbeit.
Quellen:
- Eigene Projektdokumentation zum Relaunch von Campus Events, einschließlich der Rückmeldungen der Pilotkunden, Stand November 2026.
- Academic Hero: Website des Herstellers von Campus Events – Produktkontext.
- Europäisches Parlament und Rat: Richtlinie (EU) 2016/2102 über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen, 26. Oktober 2016.
- Bundesrepublik Deutschland: Barrierefreie-Informationstechnik-Verordnung (BITV 2.0).
- Google: Einführung in Lighthouse, Chrome for Developers.
- CEN/CENELEC/ETSI: EN 301 549 V3.2.1 (2021-03), Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen.
- W3C: Web Content Accessibility Guidelines (WCAG) 2.1, W3C-Empfehlung vom 5. Juni 2018.
