Shiny-Seminar Case Study: In 2 Tagen zur eigenen App

Zwei Tage, ein Teilnehmer, eine fertige Shiny-App: Im Dezember 2025 habe ich für die GFU Cyrus AG das Seminar "Shiny für interaktive Datenvisualisierung" als 1:1-Format gehalten. Diese Case Study zeigt, wie das Seminar aufgebaut war, welche Übungen wirklich gezogen haben und was ein Einzelformat gegenüber einer Gruppe verändert. Alle Angaben zum Teilnehmer sind anonymisiert.

Ausgangslage: R-Kenntnisse vorhanden, Apps noch nicht

Der Teilnehmer kannte R aus der täglichen Auswertung, hatte aber noch keine Web-Anwendung gebaut. Das Ziel war klar: Auswertungen sollen nicht mehr als statische Grafiken per Mail verschickt werden, sondern als interaktive App, in der Kolleginnen und Kollegen selbst filtern, Zeiträume wählen und Daten hochladen können. Shiny ist genau dafür gebaut: ein Framework von RStudio (heute Posit), das aus R-Code eine Web-App macht und bei Bedarf HTML, CSS und JavaScript zulässt.

Als Rahmen habe ich ein Skript mit Beispiel-Apps vorbereitet, das der Teilnehmer nach dem Seminar behalten hat. Gearbeitet wurde durchgehend am eigenen Rechner mit Bildschirmfreigabe, ich habe Code-Bausteine parallel in den Chat gestellt.

Tag 1: Von der ersten App zu Modulen

UI und Server, reactive und observeEvent

Der erste Vormittag gehörte dem Grundgerüst: ui und server, ein Dataset-Input, eine Tabelle und ein Line-Graph als Output. Die ersten Stolperer waren typisch für den Einstieg: fehlende Kommas zwischen UI-Elementen, geschweifte und runde Klammern, die nicht zusammenpassen, ein Plot-Output ohne passenden Render-Befehl. Genau an diesen Stellen hilft das 1:1-Format, weil ich direkt am Bildschirm zeigen kann, welche Klammer wohin gehört, statt in einer Gruppe auf den langsamsten Fehler zu warten.

Danach kam das Konzept, das Shiny von einem R-Skript unterscheidet: reactive(). Erst wenn Daten reaktiv definiert sind, aktualisiert sich die App bei jeder Eingabe von selbst. Mit observeEvent() haben wir anschließend Buttons verdrahtet, die einen Plot erst auf Klick neu bauen.

Plotly, Tabs und Buttons

Am Nachmittag wurde die App sichtbar besser: Layout mit sidebarPanel und tabsetPanel, Plotly statt Base-R-Grafik, ein zweiter Tab mit eigenem Output. Eine Übung, die im Kopf geblieben ist: Zwei Buttons steuerten zwei Plots, und der Teilnehmer sollte das Skript so umschreiben, dass ein einziger Button beide Grafiken aktualisiert. Dabei ging es weniger um Syntax als um das Verständnis, welcher Code in welcher Reaktionskette hängt.

Zum Schluss des Blocks kamen Farben und Marker in Plotly. Kleine Sache, großer Effekt: Sobald die Balken nach Kategorie eingefärbt sind, sieht die App nach Produkt aus statt nach Übung.

Projektstruktur, Module und Upload

Der zweite Teil von Tag 1 hat die Struktur einer echten Shiny-App aufgebaut: ein Ordner für Daten, ein Ordner für Module mit wiederverwendbaren Funktionen für Inputs und Plots, ein www-Ordner für statische Dateien. Module waren der schwerste Teil des Tages. Wie wird ein Modul-Server in app.R geladen, wo ruft man die Funktion auf, warum muss eine Hilfsfunktion erst gesourct werden, bevor sie im Modul verfügbar ist? Hier haben wir bewusst langsam gearbeitet und jede Zeile Stück für Stück durchgesprochen.

Als Abschluss kam der CSV-Upload mit tryCatch und eine Debugging-Technik, die ich in jedem Seminar zeige: browser() in die Server-Funktion setzen und die App an genau dieser Stelle anhalten. Wer das einmal gesehen hat, sucht Fehler nicht mehr durch Raten.

Tag 2: Echte Daten, echte Probleme

tidyverse an einer Beschäftigtenstatistik

Tag 2 startete mit dem mtcars-Datensatz und tidyverse: filter, group_by, summarise, neue Kennzahlen je Gruppe. Die eigentliche Arbeit begann, als der Teilnehmer eine Tabelle aus dem eigenen Alltag geöffnet hat: eine Beschäftigtenstatistik mit mehrstufigen Spaltenköpfen, Summenzeilen, Textwerten wie "20 und mehr" zwischen Zahlen. Die Frage "Wie entstehen eigentlich solche Daten?" war der ehrlichste Moment des Seminars. Genau diese Tabellen sind der Grund, warum Auswertungen in Excel irgendwann nicht mehr reproduzierbar sind.

pivot_longer und Excel-Export

Mit pivot_longer haben wir eine Umsatztabelle mit Monaten als Spalten in ein langes Format gebracht, das Shiny und Plotly direkt verarbeiten können. Dazu openxlsx für den Export zurück nach Excel, weil die Kolleginnen und Kollegen weiterhin Excel erwarten. Auch hier gab es die typischen Fehler: Anführungszeichen bei Spaltennamen, der Datensatz, der vor dem Pivot noch gar nicht eingelesen war, Groß- und Kleinschreibung in Variablennamen. Wir haben dabei eine Konvention für Variablennamen festgelegt, die der Teilnehmer in seinen Skripten weiterführt.

Inputs verdrahten: Slider, Checkbox, Button

Der letzte Block hat die Inputs aus der Shiny-Galerie durchgespielt: Slider, Text-Input, Checkbox mit TRUE/FALSE-Logik im Server, ein Action-Button mit observeEvent. Zwei kleine Abschlussübungen haben UI und Server jeweils getrennt verschickt, damit der Teilnehmer die Verbindung selbst herstellt. Beide Übungen liefen am Ende ohne Hilfe.

Was das 1:1-Format anders macht

In einer Gruppe richtet sich das Tempo nach dem Durchschnitt. Im Einzelformat richtet es sich nach dem Fehler, der gerade auf dem Bildschirm steht. Das hat drei Konsequenzen:

1. Eigene Daten ab Tag 2. Die Beschäftigtenstatistik hätte in einer Gruppe keinen Platz gehabt. Im 1:1 war sie der wichtigste Teil.
2. Debugging als Kernkompetenz. Etwa ein Drittel der Zeit ging in Fehlersuche. Dieser Teil trägt nach dem Seminar am meisten.
3. Übungen statt Vortrag. Ich habe jeden Block mit einer Aufgabe beendet, die der Teilnehmer allein löst. Wo das nicht klappte, war der Stoff noch nicht sicher.

Learnings für dein Shiny-Seminar

• Erst reactive verstehen, dann Layout. Wer zu früh in Tabs und Farben geht, baut Apps, die sich nicht aktualisieren.
• Module am Ende von Tag 1, nicht am Anfang. Sie lohnen sich erst, wenn die zweite Grafik den gleichen Code braucht.
• browser() gehört in Stunde drei. Sobald die erste App läuft, ist Debugging das nächste Thema.
• Excel bleibt. Ein Export mit openxlsx ist für die Akzeptanz im Team wichtiger als jedes weitere Plotly-Feature.
• Echte Daten sind unordentlich. Plane Zeit für pivot_longer, Summenzeilen und Textwerte in Zahlenspalten ein.

Fazit

Nach zwei Tagen stand eine Shiny-App mit Tabs, Plotly-Grafiken, CSV-Upload und modularer Struktur, gebaut vom Teilnehmer selbst. Wichtiger als die App war die Fähigkeit, eigene Fehler zu finden und eine unordentliche Excel-Tabelle in ein Format zu bringen, das eine App verarbeiten kann. Wer für sein Team ein Shiny-Seminar plant, sollte den zweiten Tag für eigene Daten reservieren. Dort entsteht der Wert.

Weitere Berichte aus Workshops und Seminaren findest du in meinen Workshop Case Studies.