Making App Data Tangible

Meine Masterarbeit im Studiengang Interactive Technologies an der FH St. Pölten ging einer konkreten Frage nach: Lassen sich Daten aus einer alltäglichen Smartphone-App in etwas Physisches überführen – und ändert das, wie überzeugend die App wirkt? Ich habe einen Prototyp gebaut – ein Scoreboard mit zwei motorisierten Säulen, die das Punktesystem der Haushalts-App Flatastic spiegeln – und in einer zweiwöchigen Between-Subjects-Feldstudie mit sechs Haushalten gemessen, was das auslöst.

Das Problem

Persuasive Apps – Fitness, Finanzen, Gewohnheiten, Haushalt – setzen voraus, dass die Nutzerin die App öffnet, damit die Überzeugungsarbeit landet. Die Daten sind da, die Strategie ist da, aber sie liegen hinter Sperrbildschirm und Tap. Bisherige Forschung zur Daten-Physikalisierung zeigt: Daten in physische Form zu bringen macht sie leichter wahrnehmbar, leichter teilbar, leichter umsetzbar. Allerdings nutzt die bestehende Literatur fast ausschließlich Sensordaten, die für die Physikalisierung erhoben wurden (Schritte, Pflanzenfeuchte, Luftqualität). Nur ~10 % der persönlichen Daten-Physikalisierungs-Projekte zwischen 2010 und 2020 griffen auf Daten einer bestehenden App zurück – eine offene Frage: Lassen sich die persuasiven Strategien, die bereits in Apps stecken, durch eine physische Form verstärken?

Die Arbeit beantwortet das mit zwei Forschungsfragen: RQ1 – Wie lassen sich App-Daten überhaupt in eine Daten-Physikalisierung überführen? Und RQ2 – Welchen Effekt hat das auf wahrgenommene Persuasivität und Nutzererlebnis?

Warum Flatastic

Flatastic ist eine Haushalts-App, die Aufgaben in ein Punktesystem übersetzt. Sie nutzt schon mehrere persuasive Designprinzipien – Wettbewerb, Selbstbeobachtung, Belohnungen – und ihre Daten haben eine Eigenschaft, die für eine physische Übersetzung entscheidend ist: Sie sind zwischen Mitbewohner:innen geteilt und profitieren davon, im gemeinsamen Raum sichtbar zu sein, nicht hinter individuellen Logins. Flatastic lieferte mir einen authentischen, mehrbenutzerfähigen Datensatz mit eingebauter persuasiver Struktur – ein guter Ausgangspunkt, um deren Wirkung zu verstärken.

Architektur

Das Hardware-Herz ist ein ESP32-S3 (DevKitC-1, WROOM-1-Modul). Zwei lineare motorisierte Schiebepotis (Alps RSA0N11M9A04, 10 kΩ, 100 mm Hub) bilden die Säulen, angetrieben von einem TB6612FNG-Motortreiber. Jede Säule wird von innen mit einem adressierbaren WS2812B-LED-Strip in einer Farbe pro Person beleuchtet. Ein 9 V/1 A-Netzteil versorgt die Slider; ein LM2596-Buck-Konverter setzt auf 5 V für den Mikrocontroller herunter. Ein PIR-Bewegungsmelder weckt das Gerät, wenn jemand den Raum betritt – sonst ruht es. Diese Zurückhaltung ist Absicht: ein Gerät in der Wohnung soll nicht ständig „da“ sein.

Softwareseitig läuft auf dem ESP32 C++ über PlatformIO. Das Gerät startet im Dual-Wi-Fi-Modus (Access Point + Station): Beim ersten Start öffnet es ein eigenes Netzwerk, und ein Captive-Portal-Web-UI führt durch WLAN-Anmeldedaten, Login und Zuordnung der Säulen zu Personen. Im Betrieb fragt es Flatastics API bei Bewegung ab, normalisiert die Punkte gegen einen erwarteten Halbzeit-Wert und steuert die Säulen proportional. Ein 14-Tage-Zyklus setzt das Scoreboard automatisch zurück. Überfällige Aufgaben färben eine Säule rot – und ließen sie ursprünglich auf und ab fahren, um Aufmerksamkeit zu erzeugen (dazu mehr unter Was ich anders machen würde).

Entscheidungen – und was verworfen wurde

Mikrocontroller: Raspberry Pi Pico WH → ESP32-S3. Ich begann mit dem Pico wegen Größe und Preis. Der Captive-Portal-Flow verlangt aber Access Point und Station gleichzeitig, und der Pico-Wi-Fi-Stack hielt das nicht zuverlässig durch. Der ESP32-S3 schaffte beide Modi ohne Beschwerden und brachte genug Flash und GPIOs für den Rest mit.

Motortreiber: L298N → TB6612FNG. Der L298N war der naheliegende Start – gut dokumentiert, leicht erhältlich – aber als Bipolar-Transistor-Design verheizt er Energie. Der MOSFET-basierte TB6612FNG senkte die Wärmeentwicklung, beschleunigte das Schalten und schrumpfte den Platzbedarf. Für ein Gerät, das wochenlang im Wohnzimmer steht, zählt „wird nicht warm“.

Stromversorgung: Akku → Netzteil, 5 V → 9 V. Die erste Version lief auf 5 V – derselben Schiene wie der Mikrocontroller – und ich probierte Akku-Betrieb für freie Platzierung. Zwei Probleme: Die Slider hatten bei 5 V genug Reibung, um gelegentlich mitten im Hub stehenzubleiben; und Akku-Betrieb über Wochen schafft neue Ausfallszenarien (mitten in der Studie dunkel zu werden ist schlechter als gar nicht erst da zu sein). Ich wechselte auf ein 9 V-Netzteil und reduzierte für die Logik auf 5 V. Stromverbrauch: ~130 mA im Ruhezustand, ~300 mA Spitze bei Motor- oder LED-Aktivität – bequemer Spielraum auf 1 A.

Setup-UX: Companion-App → Captive Portal. Der Default-Weg für so ein Gerät ist eine Companion-App. Habe ich verworfen, weil es schwer zu rechtfertigen ist, eine App für die Konfiguration eines einzigen Geräts zu installieren – und Apps sterben mit Telefonwechseln. Ein Captive Portal funktioniert in jedem Browser, braucht keine Installation und nutzt eine Setup-Metapher, die viele schon von Hotel-WLAN kennen. Die Teilnehmer:innen der Feldstudie bestätigten das im Nachgang: alle fanden den Flow intuitiv.

Drei Säulen mechanisch, zwei elektrisch. Der 3D-gedruckte Korpus war für drei Säulen ausgelegt, ich verdrahtete aber nur zwei. Die Studie zielte auf Zwei-Personen-Haushalte; eine dritte Säule hätte Kosten und Komplexität ohne Mehrwert für RQ2 erhöht.

Was die Feldstudie zeigte

Sechs Haushalte, zwei Wochen, Between-Subjects: drei mit Flatastic allein, drei mit Flatastic plus Physikalisierung. Abhängige Variablen: wahrgenommene Persuasivität (Drozd et al. 2012), Nutzererlebnis (UEQ-S), intrinsische Motivation (IMI), Aufgaben-Metriken.

Das deutlichste Ergebnis betraf die Persuasivität. Am Tag 7 erreichte die Physikalisierungs-Gruppe einen Mittelwert von 22,17 gegenüber 13,67 in der App-Only-Gruppe – ein Unterschied von 8,5 Punkten, statistisch signifikant mit p = 0,03. Am Tag 14 hielt sich der Vorsprung (20,50 vs. 13,33). Alle Physikalisierungs-Haushalte führten ihre höhere Motivation auf die ständige physische Präsenz zurück – sie mussten nicht daran denken, die App zu öffnen; der Stand des Haushalts war einfach sichtbar, wenn man an den Säulen vorbeiging.

Das Nutzererlebnis spaltete sich sauber entlang der UEQ-S-Dimensionen. Pragmatische Qualität – „tut es, was es soll“ – war zwischen beiden Gruppen statistisch identisch (die App selbst funktioniert). Hedonische Qualität – „macht es Spaß“ – lag bei 6,71 vs. 3,58. IMI-Enjoyment zeigte dasselbe Bild (18,67 vs. 11,50). Mitbewohner:innen beschrieben die Physikalisierung als „kompetitiv und unterhaltsam“; App-Only-Haushalte beschrieben ihre Nutzung als funktional, aber flach.

Die Aufgabenanzahl war differenzierter: Mittelwert höher bei Physikalisierung (47 vs. 30), Mediane (31 vs. 28) jedoch nah beieinander; ein Ausreißer flachte den Unterschied ab. Klarer war das Signal beim Verzug überfälliger Aufgaben: Die Physikalisierungs-Gruppe arbeitete überfällige Aufgaben im Schnitt ~18 Stunden schneller ab (74,88 vs. 93,33 h).

Das stärkste Einzelergebnis aus den Fokusgruppen: Passive Erinnerungen wirken; aktive nerven. Die konstante Sichtbarkeit der Säulen war das von allen Physikalisierungs-Haushalten am häufigsten gelobte Feature. Die Überfälligkeits-Animation – Säulen, die auf und ab fuhren, um Aufmerksamkeit zu fordern – wurde durchgängig als zu häufig und irritierend beschrieben. Sie schnitt im Prinzipien-Ranking unter den Physikalisierungs-Nutzer:innen am schlechtesten ab.

Was ich anders machen würde

Die aktive Erinnerung weglassen oder sanfter machen. Die animierte Überfälligkeits-Anzeige war das deutlichste Design-Versagen des Prototyps. Die Physikalisierung erinnert bereits dadurch, dass sie existiert – zusätzliche Bewegung kippte vom „ambient“ ins „nervt“. Eine nächste Version würde die Animation durch einen leiseren Hinweis ersetzen (z. B. einen Farbwechsel) oder die aktive Erinnerung ganz streichen.

In bestehende Objekte integrieren. Das stärkste qualitative Feedback drehte sich um Möbel. Mehrere Haushalte schlugen vor, die Säulen in eine Uhr, ein Regal oder ein Kunstobjekt einzubetten. Das passt zum Abstraktionsprinzip von Sauvé und Houben (2022): Die erfolgreichsten Physikalisierungen fügen sich in den Raum, wenn sie gerade nicht gebraucht werden. Der Standalone-Gadget-Charakter funktioniert für eine Studie, liest sich aber als „Tech-Gerät“ – das limitiert die Langzeitakzeptanz.

Früher auf Hardware testen, mit billigeren Proxies. Die Migrationen Pico→ESP32-S3 und L298N→TB6612FNG kosteten echte Zeit, weil ich mich auf einen Mikrocontroller und einen Treiber festgelegt hatte, bevor ich Dual-Wi-Fi-Mode und Thermik gestresst hatte. Ein Karton-Mockup mit einer Säule statt zwei, in Woche drei statt Monat drei validiert, hätte beide Probleme früher sichtbar gemacht.

Mehr Haushalte, längere Studie. N = 6 über 14 Tage reicht für eine Masterarbeit, aber nicht für Generalisierung. Der Persuasivitäts-Effekt hielt sich über die zwei Wochen, zeigte aber eine kleine Drift nach unten – eine vier- oder achtwöchige Studie würde zeigen, ob das Rauschen oder ein Novelty-Effekt ist. Eine Stichprobe über Freundeskreise hinaus würde außerdem die Haushaltsroutinen abdecken, die in der kleinen Studie die Aufgaben-Zahlen dominierten.

Mit dem App-Team zusammenarbeiten. Die Arbeit behandelt Flatastic als unbeteiligte Datenquelle. Der ehrliche Produktionspfad ist Co-Design mit dem App-Team – Übernahme der Bildsprache, der Feature-Prioritäten, der Daten, die ihnen am wichtigsten sind. Diese Zusammenarbeit würde auch Interaktion in die andere Richtung freischalten (App-Daten über die Physikalisierung verändern), was der nächste Forschungsschritt wäre.

Betreut von FH-Prof. Dr. Wolfgang Aigner und Dr. Victor Adriel de Jesus Oliveira, FH St. Pölten. Quellcode, 3D-Modelle und Begleitmaterial auf GitHub.