GEOM90007 Chap.12 Shiny and Reactive Visualisation

Shiny and Reactive Visualisation

Define reactive programming

Shiny and Reactive Visualisation connects reactive programming, Shiny application and interaction state along an information-visualisation pipeline: data type, visual encoding, perception, task fit and evaluation.

The practical aim is to design a minimal reactive path and make defaults, loading states and selected data visible; the display is defensible only when each encoding choice can be traced back to the analytical question and the structure of the data.

Place reactive programming at its correct stage: question, data specification, transformation, encoding, perception, tool or evaluation.

For reactive programming, record the variables, measurement levels, granularity, missingness and comparison task wherever they apply before choosing or judging a chart.

Use Shiny application to make the next transformation, encoding, layout, interaction or evaluation step explicit.

When Shiny application involves marks and channels, state which values they represent and check whether scale, ordering, aggregation or filtering changes the apparent pattern.

Use interaction state to test perceptual and task fit.

In Shiny and Reactive Visualisation, ask whether viewers can make the required comparison accurately, whether uncertainty and exceptions remain visible, and whether colour, position, motion or interaction creates an avoidable accessibility or interpretation cost.

Trace Shiny application

For the application — design a minimal reactive path and make defaults, loading states and selected data visible — compare at least one alternative encoding against the same data and task.

Retain the design only if the interaction state evaluation shows that it reveals the intended relationship without introducing a stronger distortion or hiding the evidence needed to challenge it.

Make a compact pipeline audit for reactive programming: question or data field; transformation; mark and visual channel where applicable; intended task; evaluation evidence; and likely failure.

Locate Shiny application and interaction state at their actual stages so a technically valid implementation is not mistaken for an effective display.

Test a changed Shiny application view. Hold the data and question stable, replace the channel most closely tied to Shiny application, and predict which comparison becomes easier or harder.

Evaluate the result with interaction state, including uncertainty, accessibility and the possibility that an apparent pattern is produced by scale, binning, projection or interaction state.

Critique Shiny and Reactive Visualisation in task order: state the question around reactive programming, classify the data, describe the role of Shiny application, predict the perceptual judgement and report the interaction state evaluation evidence.

Revise the first stage where interaction state shows that the visual no longer supports the task instead of adding decoration to a structurally unsuitable chart.

Test with interaction state

A complete response should make the task visible before the detail: identify what must be decided, define the relevant terms, connect the evidence to Shiny application, and use interaction state to test the result.

The final sentence about interaction state should answer the question actually asked rather than merely repeat the topic.

The controlling limit is specific: Interactivity should not make an analysis non-auditable or allow incompatible filter combinations without feedback.

Keep that interaction state limit beside the worked example, because it separates a careful GEOM90007 answer from one that sounds confident but claims more than the task or evidence supports.

For revision, retrieve reactive programming, Shiny application and interaction state without notes, explain their relationship aloud, then complete a changed version of the application: design a minimal reactive path and make defaults, loading states and selected data visible.

Record the first failed Shiny application reasoning move and repair it before attempting another case.

What this chapter covers

• 01

  reactive programming

• 02

  Shiny application

• 03

  interaction state

• 04

  Applying reactive programming

• 05

  Limits of Shiny application and interaction state

Worked example: Shiny and Reactive Visualisation

Key terms

reactive programming

A programming model in which outputs automatically update when the input values or dependencies they use change. Use this definition when the task is to design a minimal reactive path and make defaults, loading states and selected data visible.

Shiny application

An R-based interactive web application connecting user-interface inputs to reactive data, analysis and visual outputs. Use this definition when the task is to design a minimal reactive path and make defaults, loading states and selected data visible.

interaction state

The current values of filters, selections and controls that determine what an interactive visualisation displays. Use this definition when the task is to design a minimal reactive path and make defaults, loading states and selected data visible.

Shiny and Reactive Visualisation FAQ

Assessment move

Reconstruct the relationship among reactive programming, Shiny application and interaction state; complete the chapter application without notes; then test the result against this limit: Interactivity should not make an analysis non-auditable or allow incompatible filter combinations without feedback.

Working through Shiny and Reactive Visualisation in GEOM90007? Sia is AskSia’s AI Data Science tutor — ask any GEOM90007 Shiny and Reactive Visualisation question and get a clear, step-by-step explanation grounded in how GEOM90007 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.