Shiny Seminar Case Study: Your Own App in 2 Days

Two days, one participant, one finished Shiny app: In December 2025 I ran the seminar "Shiny for interactive data visualization" for GFU Cyrus AG as a one-on-one format. This case study shows how the seminar was structured, which exercises really made a difference and what a one-on-one format changes compared to a group. All details about the participant are anonymized.

Starting point: R skills yes, apps not yet

The participant knew R from daily analysis but had never built a web application. The goal was clear: analyses should no longer be sent around as static charts by email but as an interactive app where colleagues can filter, pick time ranges and upload data themselves. Shiny is built for exactly that: a framework from RStudio (now Posit) that turns R code into a web app and allows HTML, CSS and JavaScript where needed.

As a framework I prepared a script with example apps that the participant kept after the seminar. We worked on his own machine with screen sharing throughout, and I posted code snippets in the chat in parallel.

Day 1: From the first app to modules

UI and server, reactive and observeEvent

The first morning belonged to the skeleton: ui and server, a dataset input, a table and a line graph as output. The first stumbles were typical for beginners: missing commas between UI elements, curly and round brackets that did not match, a plot output without a matching render call. This is exactly where the one-on-one format helps, because I can show on screen which bracket goes where instead of waiting for the slowest error in a group.

Then came the concept that separates Shiny from an R script: reactive(). Only once data is defined reactively does the app update itself on every input. With observeEvent() we then wired up buttons that rebuild a plot only on click.

Plotly, tabs and buttons

In the afternoon the app visibly improved: layout with sidebarPanel and tabsetPanel, Plotly instead of base R graphics, a second tab with its own output. One exercise that stuck: two buttons controlled two plots, and the participant had to rewrite the script so that a single button updates both charts. That was less about syntax and more about understanding which code hangs in which reactive chain.

The block ended with colors and markers in Plotly. Small thing, big effect: once the bars are colored by category, the app looks like a product instead of an exercise.

Project structure, modules and upload

The second part of day 1 built the structure of a real Shiny app: a folder for data, a folder for modules with reusable functions for inputs and plots, a www folder for static files. Modules were the hardest part of the day. How is a module server loaded in app.R, where do you call the function, why does a helper function have to be sourced before it is available in the module? Here we deliberately worked slowly and went through every line step by step.

The finale was a CSV upload with tryCatch and a debugging technique I show in every seminar: put browser() into the server function and stop the app at exactly that point. Once you have seen that, you stop hunting bugs by guessing.

Day 2: Real data, real problems

tidyverse on an employment statistic

Day 2 started with the mtcars dataset and tidyverse: filter, group_by, summarise, new metrics per group. The real work began when the participant opened a table from his own daily work: an employment statistic with multi-level column headers, total rows, text values like "20 and more" between numbers. The question "How do such data even come about?" was the most honest moment of the seminar. Tables like these are the reason why Excel analyses eventually stop being reproducible.

pivot_longer and Excel export

With pivot_longer we turned a revenue table with months as columns into a long format that Shiny and Plotly can process directly. Plus openxlsx for the export back to Excel, because colleagues still expect Excel. Here too the typical errors appeared: quotes around column names, the dataset that had not even been read before the pivot, upper and lower case in variable names. Along the way we agreed on a naming convention for variables that the participant now uses in his scripts.

Wiring inputs: slider, checkbox, button

The last block went through the inputs from the Shiny gallery: slider, text input, checkbox with TRUE/FALSE logic in the server, an action button with observeEvent. Two small final exercises sent UI and server separately so the participant had to make the connection himself. Both exercises ran without help in the end.

What the one-on-one format changes

In a group the pace follows the average. In a one-on-one it follows the error currently on screen. That has three consequences:

1. Own data from day 2. The employment statistic would not have had room in a group. In the one-on-one it was the most important part.
2. Debugging as a core skill. About a third of the time went into troubleshooting. That part carries the most after the seminar.
3. Exercises instead of lecture. I ended every block with a task the participant solves alone. Where that failed, the material was not solid yet.

Learnings for your Shiny seminar

• Understand reactive first, then layout. Going into tabs and colors too early produces apps that do not update.
• Modules at the end of day 1, not at the start. They only pay off once the second chart needs the same code.
• browser() belongs in hour three. As soon as the first app runs, debugging is the next topic.
• Excel stays. An export with openxlsx matters more for team acceptance than any further Plotly feature.
• Real data is messy. Plan time for pivot_longer, total rows and text values in numeric columns.

Conclusion

After two days there was a Shiny app with tabs, Plotly charts, CSV upload and a modular structure, built by the participant himself. More important than the app was the ability to find his own errors and to turn a messy Excel table into a format an app can process. If you are planning a Shiny seminar for your team, reserve the second day for your own data. That is where the value is created.

More reports from workshops and seminars are in my workshop case studies.