Bei Liip arbeiten wir oft mit Kund*innen zusammen, die komplexe Anforderungen im Bereich Content Management haben. Ein aktuelles Projekt war die neue Website für das museum-gestaltung.ch/de, das führende Schweizer Designmuseum mit einem vielfältigen und aktiven öffentlichen Programm. Eine zentrale Anforderung war ein flexibles Event-Management-System, das eine breite Palette von Event-Typen unterstützen kann.
Anforderungen verstehen
Neben seinen permanenten und temporären Ausstellungen veranstaltet das Museum ein breites Spektrum an Events: von Führungen und Schulbesuchen über mehrtägige Workshops bis hin zu Konzerten oder Filmvorführungen.
Diese Events finden an drei verschiedenen Standorten statt und richten sich an unterschiedliche Zielgruppen: Einzelbesucher*innen, Familien, Freundeskreise und Schulklassen. Manche Events sind kostenlos, andere erfordern eine kostenpflichtige Anmeldung. Viele werden in mehreren Sprachen angeboten.
Um diese Komplexität zu bewältigen, brauchte es ein System, das folgende Punkte unterstützt:
- Wiederkehrende Events mit komplexen Zeitplänen
- Unterschiedliche Dauern (von 2-stündigen Besuchen bis zu mehrtägigen Workshops)
- Mehrere Standorte
- Zielgruppen-Segmentierung und -Ansprache
- Teilnehmer*innen-Limits (Minimum und Maximum)
- Automatisierte Kommunikation mit Besucher*innen (z. B. Erinnerungen)
Kurz gesagt: Das Museum brauchte mehr als nur eine einfache Event-Liste und einen Kalender.
Drupal-Lösungen evaluieren
Mit Drupal gilt das Motto: «Es gibt ein Modul dafür.» Bei über 53'000 verfügbaren Modulen lag es nahe, unsere Suche dort zu beginnen.
Nach der Evaluation mehrerer Optionen identifizierten wir das Modul Recurring Events als vielversprechendsten Ausgangspunkt.
Warum Recurring Events?
Vorteile:
- Es ist das umfassendste Modul zur Verwaltung von Events in Drupal
- Es bietet bereits out of the box starke Funktionalitäten, die in einigen Bereichen sogar unsere Anforderungen übertrafen
Nachteile:
- Nicht alle Anforderungen des Museums waren abgedeckt
- Einige bestehende Features passten nicht zu den Anwendungsfällen des Museums und mussten angepasst werden
Identifizierte Funktionslücken
Das Modul Recurring Events deckte viele unserer Bedürfnisse ab, aber nicht alle. Das ist eine typische Herausforderung in der Softwareentwicklung: Bestehende Lösungen bringen einen oft weit, aber selten ans Ziel.
Hier sind einige zentrale Features, die das Museum für Gestaltung zusätzlich benötigte und die zum damaligen Zeitpunkt nicht verfügbar waren:
Mehrsprachigkeit
Neben den drei Landessprachen der Schweiz bietet das Museum regelmässig auch Events auf Englisch für internationale Besucher*innen an. Eine vollständige mehrsprachige Handhabung von Event-Inhalten und Anmeldeprozessen war unerlässlich.
Gruppenanmeldungen
Die meisten Besuche finden in Gruppen statt, von Familien und Freundeskreisen bis hin zu Schulklassen und Führungsgruppen. Das System musste die Anmeldung ganzer Gruppen ermöglichen. Wenn nicht genügend Plätze für die gesamte Gruppe frei waren, sollte die Gruppe auf eine Warteliste gesetzt werden.
Standardkapazität pro Event-Typ
Die meisten Besuche finden in Gruppen statt, von Familien und Freundeskreisen bis hin zu Schulklassen und Führungsgruppen. Das System musste die Anmeldung ganzer Gruppen ermöglichen. Wenn nicht genügend Plätze für die gesamte Gruppe frei waren, sollte die Gruppe auf eine Warteliste gesetzt werden.
Fixierte Event-Daten
In unserem Anwendungsfall dürfen Event-Daten nach der Veröffentlichung nicht mehr geändert werden. Das Modul erlaubte jedoch zu diesem Zeitpunkt Änderungen oder Löschungen. Um Verwirrung oder Unzufriedenheit bei Besucher*innen zu vermeiden, sollten die Daten nach der Veröffentlichung fixiert sein.
Zielgruppenspezifische E-Mail-Kommunikation
Abhängig davon, ob es sich um eine private Gruppe oder eine Schulklasse handelt, sind unterschiedliche Teams für die Event-Betreuung zuständig, weshalb unterschiedliche E-Mail-Vorlagen notwendig waren.
Die richtige Herangehensweise finden
Die Frage lautete nun: Vorhandenes erweitern oder eine eigene Lösung von Grund auf entwickeln? Hier die Optionen:
Option 1: Eine Eigenentwicklung
Dies würde uns vollständige Kontrolle und Flexibilität verschaffen.
Vorteile:
- Exakt auf die Anforderungen des Museums zugeschnitten, ohne Kompromisse
Nachteile:
- Hohe Entwicklungskosten
- Funktionen müssten neu gebaut werden, die bereits in Modulen existieren
Option 2: Das Modul Recurring Events forken
Dies ist ein pragmatischer Ansatz, insbesondere kurzfristig, aber langfristig ist er schwer aufrechtzuerhalten.
Vorteile:
- Anpassung des Moduls an alle spezifischen Bedürfnisse
- Schnellste Umsetzung in der initialen Phase
Nachteile:
- Hoher Wartungsaufwand, da kontinuierlich Upstream-Änderungen integriert werden müssten
- Risiko von Konflikten mit zukünftigen Weiterentwicklungen
- Verbesserungen kämen nicht der Community zugute und erhielten keine Community-Weiterentwicklungen zurück
Option 3: Override mit Custom Code
Das Modul wird in seiner bestehenden Form genutzt, während die fehlenden Funktionen ergänzend über die Drupal-APIs entwickelt werden. Diese sind darauf ausgelegt, bestehende Features gezielt an die spezifischen Anforderungen eines Projekts anzupassen.
Vorteile:
- Nutzung bestehender Features des Moduls
- Klare Trennung zwischen Community-Code und projektspezifischer Logik
Nachteile:
- Fortlaufender Wartungsaufwand für den Custom Code
- Risiko von Konflikten, wenn sich das Modul weiterentwickelt
- Unsere Erweiterungen könnten für andere nützlich sein, würden aber nicht zurückfliessen
Option 4: Beitrag zum Modul Recurring Events
Gemeinsam mit den Modul-Maintainer*innen neue Funktionen entwickeln und unmittelbar ins Modul einbringen.
Vorteile:
- Im Einklang mit der Open-Source-Philosophie von Drupal
- Langfristige Kompatibilität und Community-Support
- Features werden von erfahrenen Entwickler*innen geprüft und verbessert
- Reduzierter Wartungsaufwand auf lange Sicht
Nachteile:
- Beiträge müssen hohen Qualitätsstandards entsprechen
- Community-Reviews können abgelehnt werden oder lange dauern
- Mehr Kommunikations- und Koordinationsaufwand während der Entwicklung
Ein gemeinsamer Erfolg
Wir entschieden uns für Option 4: eine enge Zusammenarbeit mit den Maintainer*innen des Moduls Recurring Events, um die fehlenden Features direkt ins Modul einzubringen. Über mehrere Monate hinweg arbeiteten wir aktiv über die Issue Queue, steuerten Code bei und reviewten Patches. Dadurch wurde einer unserer Entwickler als Co-Maintainer ins Projekt aufgenommen.
Das Resultat war ein Erfolg: Wir konnten ein leistungsstarkes, flexibles Event-Management-System liefern, das die Anforderungen des Museums erfüllte. Es basiert vollständig auf Open-Source-Prinzipien. Mehrere unserer Beiträge sind bereits in den neuesten Versionen des Moduls enthalten, weitere Verbesserungen sind in Arbeit.
Bei Liip glauben wir fest daran, die Werkzeuge, die wir nutzen, gemeinsam zu stärken – nicht nur für uns und unsere Kund*innen, sondern für die gesamte Drupal-Community. Wenn du Interesse daran hast, Event-Management in Drupal zu verbessern, laden wir dich ein, dich mit uns in der Recurring Events issue queue auszutauschen.