Interactive Data Visualisation, A Shiny Exploration Surface
Static visualisations make a claim. Interactive visualisations make the audience do the work of interrogating the claim. The shift matters more than it sounds, because the moment you hand the user a filter and a slider, you have changed the rhetorical contract: the picture is no longer "what I want you to see" but "what you can find." This project is the smallest defensible artefact for that shift, built as an R Shiny app.
The problem
A well-built static plot is an opinionated argument. The author chose the variables, the axes, the colour scale, the annotation. The reader gets one viewpoint. For many analytical use cases that is exactly right. The author should curate the message, the audience should receive the curated form. Editorial responsibility belongs somewhere.
But there is a category of work where the curated viewpoint is the wrong tool. When the audience knows more than the author about the data's domain, or when the question the audience wants to ask was not the question the author anticipated, the static plot becomes a wall. The reader cannot drill in. They cannot ask a follow-up question. They cannot stress-test the claim against a slice the author did not think to make.
The exploratory dashboard is the answer to that, and Shiny is the lightest-weight way of building one in the R ecosystem. The project sets out to demonstrate that pattern in a small, embeddable form.
The approach
A Shiny app, built around the reactive programming model that the framework expects, hosted publicly so anyone can use it without standing up an R environment of their own.
Inputs as the contract. The app's UI gives the user a small, deliberate set of controls. Each control names a question the user might be asking. Resist the temptation to add a slider for every variable: the cost of a generous UI is that the user is exhausted before they ask the first question.
Reactive recomputation. The Shiny reactivity model means that downstream plots and tables update only when their upstream inputs change. The mental model is clean: declare what depends on what, let the framework handle the rendering. The discipline this enforces (no side-effects in the plotting layer, no shared mutable state between user actions) is the discipline that distinguishes a Shiny app that scales gracefully from one that does not.
Output composition. The interactive plots and tables are composed of ggplot2 layers and tidyverse pipelines. The underlying analytical code is the same code that would render a static plot in a report. The Shiny scaffolding wraps that code without rewriting it. When the analysis evolves, the app inherits the evolution.
Embedding. The app is hosted on shinyapps.io and embedded into this portfolio via iframe. The hosting decision is deliberate. Self-hosting Shiny means running R as a service, which is a larger operational commitment than this artefact justifies. A hosted demo lets the work speak for itself without dragging infrastructure along behind it.
What the app earns
The interactive form lets a reader test a claim by selecting their own slice. That is the analytical move the static version could not make. It also lets the reader see the structure of the data, the rough shape of how variables relate, before the author's interpretation arrives. Both moves matter when the audience includes domain specialists who are going to second-guess the author's curation anyway.
Evidence
- R Shiny app deployed publicly at shinyapps.io
- ggplot2 plotting layer driven by reactive user inputs
- tidyverse data manipulation pipeline shared between exploratory and static outputs
- Embedded directly into this portfolio surface for direct interaction
- Lightweight enough to host on the free shinyapps.io tier, demonstrating the right operational scope for an interactive academic artefact
- Code architecture is the same code that would back a static analysis, demonstrating the Shiny pattern as a wrapper rather than a rewrite
← kipjordan.com