Der Ausgangspunkt war eine ungewöhnlich gute Idee eines Professors: eine Oberfläche unter realistischen Bedingungen evaluieren – nämlich beim Autofahren. Das Testen komplexer Interaktionskonzepte hinter dem Steuer ist weder sicher noch legal, weshalb sich die Frage stellte, wie man die Belastbarkeit einer Oberfläche unter Ablenkung messen kann, ohne jemanden auf die Straße zu schicken.
Die Geburt von Blinky
Unser erster Plan war, die Methode auf dem Universitätsgelände für eine authentische Testumgebung zu demonstrieren. Als die Versicherung die nötige Deckung ablehnte, haben wir von Grund auf neu gedacht. Das Ergebnis war Blinky, eine Webanwendung, die genau das leistet, was früheren Testkonzepten fehlte: Sie beansprucht die Aufmerksamkeit der Nutzer:innen gezielt und zeichnet dabei jeden relevanten Datenpunkt auf. Die Nutzung macht echten Spaß – und liefert echte Erkenntnisse darüber, wie bedienbar eine Oberfläche unter Druck bleibt.
Wie funktioniert Blinky?
Man konfiguriert einen individuellen Stresstest, indem man Parameter wie Testdauer und Anzahl der auszulösenden Ereignisse festlegt. Nach der Konfiguration generiert die App einen QR-Code; scannt man ihn, beginnt der Test. Alle verbundenen Geräte fangen dann an, in einem vordefinierten Muster zu blinken, und lösen ein akustisches Signal aus, das jeweils bestätigt werden muss. So erhalten wir eine präzise Reaktionszeiterfassung und einen reichhaltigen Datensatz zur späteren Analyse.
Über diese Kernfunktionen hinaus bietet Blinky eine vollständige Benutzerverwaltung: Administrator:innen verwalten Konten, steuern Zugriffsrechte und speichern vergangene Tests, um sie erneut auszuführen oder zu ändern.
Die technische Roadmap: Was steckt dahinter?
Echtzeit-Kommunikation mit WebSockets
Das Rückgrat von Blinky sind WebSockets, die eine dauerhafte, bidirektionale Verbindung zwischen Server und Clients öffnen – anders als konventionelle HTTP-Anfragen.
Learning 1: Der WebSocket
• Warum WebSockets? Sie ermöglichen kontinuierliche Echtzeit-Kommunikation – ideal für Stresstests, bei denen schnelle Reaktionszeiten und sofortige Synchronisierung aller verbundenen Geräte entscheidend sind.
• Systemarchitektur: Unsere Clients (sowohl Hosts als auch Teilnehmer:innen) verbinden sich über dedizierte URLs – Hosts direkt, während Teilnehmer:innen der Sitzung über einen angehängten Gruppenparameter beitreten. Nachrichten fließen in einem standardisierten Format, {type: "typeOfMessage", data: "objectWithData"}. Typische Nachrichten sind socket_opened (Verbindung bestätigt), new_client (ein:e neue:r Teilnehmer:in), trigger (Aktion auslösen, z. B. blinken) und stop (Sitzung für alle Clients beenden).
Diese Architektur ermöglicht es uns, jedes Gerät in perfekter Synchronizität zu steuern – ein entscheidender Faktor für koordinierte Stresstests.
Wechsel zu Svelte
Learning 2: Svelte war die richtige Entscheidung
Ursprünglich war Vue.js für das Frontend geplant. Nach einigen Evaluierungsstunden – größtenteils beim Kämpfen mit Reibung zwischen TypeScript und Vue – wechselten wir zu Svelte. Es stellte sich als die richtige Entscheidung heraus: Es fügte sich nahtlos in das Projekt ein und machte das gesamte Entwicklungserlebnis erheblich angenehmer.
Styling und UI – Svelte, Tailwind & Skeleton/Flowbite
Learning 3: Svelte mit Tailwind & Skeleton/Flowbite macht Spaß
Für das Styling kombinierten wir Tailwind CSS mit UI-Komponenten von Skeleton und Flowbite. Die Kombination ermöglichte schnelles, flexibles Styling – Stile direkt im Markup definieren, statt lange CSS-Dateien zu schreiben – und eine responsive, polierte Oberfläche, die auf jedem Gerät gut aussieht und sofort reagiert.
Datenverwaltung mit PocketBase
Learning 4: PocketBase für die Datenverwaltung
Um Konten, Testergebnisse und andere relevante Informationen effizient zu verwalten, entschieden wir uns für PocketBase. Es ist leichtgewichtig und schnell bei Datenbankoperationen, bietet eine leistungsfähige Infrastruktur für den Echtzeit-Datenaustausch, und seine dokumentenorientierte Struktur skaliert gut mit einem wachsenden Projekt – und, offen gesagt, das niedliche Maskottchen hat auch nicht geschadet.
Ein Blick auf die Frontend-Architektur
Unser Frontend basiert auf Svelte und ist modular aufgebaut: Ein dediziertes WebSocket-Modul richtet die Verbindung ein und verwaltet sie; Sitzungsfunktionen wie startSession, triggerDevice und stopSession steuern die Echtzeit-Interaktionen; Komponenten ermöglichen es Nutzer:innen, Tests zu starten, Geräte auszulösen und Ergebnisse live zu visualisieren; und Svelte Stores halten die gesamte UI reaktiv auf dem neuesten Stand, sodass Ergebnisse stets aktuell sind.
Fazit: Stressen, analysieren, verbessern
Blinky ist mehr als eine App – es ist ein Tool, das Interface-Stresstests in einer kontrollierten Umgebung ermöglicht. Durch die Kombination moderner Technologien wie WebSockets, Svelte und PocketBase wurde es zu einer Plattform, die technisch überzeugend sowie benutzerfreundlich und effizient ist. Es gibt Entwickler:innen und Designer:innen die Möglichkeit, die Belastbarkeit ihrer Oberflächen unter realen Bedingungen zu testen und wertvolle Daten zu sammeln, die direkt in die Gestaltung von Interfaces einfließen, die auch unter Druck intuitiv bleiben.
Neugierig? Besucht blinky.bandy-app.com und seht selbst, wie man eine Oberfläche mit moderner Technologie richtig 'stresst'. Blinky zu bauen war eine aufregende Reise voller Herausforderungen und echtem Lernen – genau die Art von Projekt, die mir am meisten Freude macht.