-
Event-Plattform mit Online-Shop
-
- Produkt
- Das «Remake» der grössten Schweizer Event-Plattform
Zur Website -
- Aufgaben
- Konzept (Produktentwicklung und Requirements Engineering), Gestaltung, Umsetzung, Support und Weiterentwicklung
-
- Technologien
- Backend: Node.js mit eigenem API-first und Microservice-basiertem Framework, PostgreSQL, Amazon AWS Frontend: AngularJS, Polymer, HTML5, CSS3
Über Eventbooster
Eventbooster ist mit 30'000 zukünftigen Anlässen – von Konzert über Ausstellung bis Markt – die wichtigste Event-Datenbank der Schweiz. Erfasst werden die Anlässe durch Veranstalter (über eventbooster.ch) und durch eine Berliner Redaktion, ausgegeben werden sie über verschiedenste Schweizer Medien in Form von Werbebuchungen, Eventkalender und vorgefertigten Layouts für die Presse.
2013 entschied sich die Eventbooster AG für ein komplettes «Remake» der Plattform: Neue Technologie, neue Funktionen, neues Design. Während fünf Jahren haben wir Eventbooster Stück um Stück erneuert, erweitert und letztlich ersetzt.
Aus alt mach Zukunft
Es ist deutlich aufwändiger, ein bestehendes System zu ersetzen, als etwas Neues zu erschaffen: Die Software muss nicht nur alle Funktionen der bisherigen Lösung aufweisen, Kunden erwarten zusätzlichen Mehrwert. Und: Man kann dabei nicht klein starten und schrittweise erweitern – es braucht ein «Big Bang»-Release.
Das bedingt vorausschauende Planung und unablässige Koordination. Bei Eventbooster
- erschafften wir ein gemeinsames Verständnis der Anforderungen. Wir erarbeiteten sie anhand von Workshops und hielten sie in einer funktionalen Spezifikation, in Diagrammen und Wireframes fest.
- testeten wir Schnittstellen und zentrale Bestandteile mittels Unit- und Integration-Tests automatisiert. Damit erhöhten wir die Qualität und reduzierten Nebenwirkungen bei Code-Anpassungen.
- setzten wir auf offene und standardisierte Schnittstellen (REST-API); dadurch konnten wir das User-Interface komplett von der serverseitigen Logik trennen. Das verbessert die Wartbarkeit.
User Interface Porn
Der frühere Eventbooster und damit seine Nutzeroberfläche waren 15-jährig, als wir den Ersatz in Angriff nahmen. Seither hat sich viel getan – viel Gutes. Wir haben die relevanten Interaktionen von Grund auf neu konzipiert, uns ganz vom Alten gelöst und das User Interface so gestaltet, wie wir es selber gerne brauchen würden.
«User Experience ist nicht die Farbe eines Buttons. Sie hat nicht hübsches Aussehen, sondern das korrekte Funktionieren zum Ziel.
Wir starten mit primitivsten grafischen Darstellungen, mit Filzstift, mit schwarzen Linien und grossen Flächen. Erst ganz spät legen wir die ‹farbige Maske› darüber. So bleibt der Fokus lange bei der Funktionsweise und den Interaktionen – und wurde nicht vom Aussehen gestört.»
Felix Steiner CEO Joinbox
Mother Ship vs Battle Ships
Eventbooster ist mehr als eine Website: Es ist eine Plattform, auf welcher diverse Applikationen laufen: events.ch, Cornèrcard Emotions, eine Schnittstelle für Datenbezüger wie Partyguide, Züritipp oder Ron Orp, eine Event-Suche für die Post, Eventbooster selber, ein Redaktionstool, Exports für Print-Layouts, ein Import von Kinodaten und einer Kulturagenda – «it’s fucking huge».
Das braucht die richtige System-Architektur. Und gute Architektur braucht einen Stararchitekten. Den haben wir. Weil 2013 die richtigen Tools fehlten, entwickelten wir für dieses Projekt das Microservice-basierte Framework «distributed» und den Datenbank-Mapper «related» (https://www.npmjs.com/package/related).
«Irgendwann kriegte Eventbooster aufgrund seiner Dimensionen den Übernamen ‹Mothership›. Das ist falsch. Es ist mehr eine Horde von kleinen, wendigen Battleships, die im Verbund mächtig sind:
Microservices mit klar definierten Zuständigkeiten, die über saubere Schnittstellen miteinander kommunizieren und damit eine skalier- und wartbare Applikation bilden.»
Lina Marieke van der Weg Joinbox
Masseneinwanderung
Bei Eventbooster mussten wir rund 12 Millionen Datensätze von der alten auf die neue Applikation übertragen. Diese Daten – Nutzer, Anlässe, Künstler, Veranstaltungsorte etc. – hatten komplexe Abhängigkeiten untereinander und eine veraltete Struktur.
Der erste Testimport dauerte deswegen sechs Tage – während dieser Zeit hätte die Plattform offline sein müssen. Ein No-Go für alle Betroffenen. Optimierungen am Importer (Multi-Threading, Asynchronität und Parallel Processing) haben die benötigte Zeit um 93% reduziert.
