Using ggplotbattles to support learning data visualisation

Teaching ggplot2 through competitive, browser-based practice

Michael Lydeamore

Department of Econometrics and Business Statistics, Monash University

The teaching problem

Data visualisation is not just syntax.

Students need to connect:

• data structure
• ggplot2 grammar
• graphical judgement
• debugging and iteration

Start with the problem rather than the tool. The thing we are trying to teach is not “remember geom_bar”. It is a coordinated practice: what does each row represent, which aesthetic mapping expresses the comparison, what does the plot communicate, and how do I revise code when the image is wrong? That is hard to teach in a tutorial because demonstration makes sense while it is happening, but the student still has to develop their own loop of prediction, code, output, comparison, and revision.

A typical tutorial problem

Students can watch an expert build a plot and still be unsure how to start the next one.

The missing skill is often translation:

target visualisation -> code choices

This is where I frame the gap. Students are not necessarily disengaged or incapable. The format often asks them to recognise a solution rather than generate one. Data visualisation is especially vulnerable to this because a final plot can look obvious in hindsight. The activity I wanted was one where students had the target in front of them, had to make local code decisions, and got fast enough feedback that revision felt natural rather than punitive.

The design idea

Make the invisible expert loop visible, social, and fast.

ggplotbattles turns plot recreation into a short competitive activity:

• students write ggplot2 code in the browser
• a target plot stays visible
• their output is scored visually
• repeated attempts are expected

The pedagogical idea is active learning with a game mechanic attached to the core learning task. The competition is not separate from the statistics. The score is not for attendance or speed alone. It rewards matching the intended visual output. That means the game element points students back to the grammar of graphics decisions we want them to practise.

ggplotbattles.dev

This is a good point to show the site. I would briefly say that the name is a nod to code golf and CSS battle style exercises, but the goal here is teaching visualisation rather than minimising characters. The student experience is deliberately low setup: open the site, open a battle, write R code, run it, compare the image.

What students see

What students see

The interface matters because students need the task goal, the code, and the feedback in one place. I would walk through the quadrants: task description and data, target plot, code editor, output and comparison. The important part is that the feedback is visual and immediate. It lowers the cost of trying a mapping, changing a scale, or fixing a facet.

Under the hood

📄🤺

Battle file R plus quarto-like metadata

🌐

Browser R webR runs code without local setup

🖼️

Render target and attempt become images

🔍

Compare pixel-by-pixel similarity

🔁

Revise students iterate in place

This is the system slide. I would keep it high level unless the audience is especially technical. A battle is a self-contained R file with metadata for the site. webR means the student does not need RStudio, packages installed locally, or a server-side R session for every student. The comparison is image based rather than code based, which is important because there are many legitimate ways to write the same plot. The tool can reward the visual result, not a single canonical solution.

A battle is just a file

#| title: "Penguin Distributions"
#| dataset-name: "palmerpenguins::penguins"
#| colours: "`c('darkorange', 'purple', 'cyan4')`"
#| description: "Recreate the target plot using the data provided."
library(ggplot2)
library(dplyr)
ggplot(penguins, aes(x = bill_length_mm, fill = species)) +
  geom_density(alpha = 0.6) +
  scale_fill_manual(values = c("darkorange", "purple", "cyan4"))

The open-source design is useful for teaching. I can write a battle as an R file, put the data requirements and description in the header, and focus on a specific visualisation concept. That makes it possible to create battles that align directly with a week of teaching, rather than asking students to use a generic game that happens to involve code.

The study

134 consenting students in the class list

92 / 42 undergraduate / postgraduate

2 mini-tasks with pre/post quizzes

ETC1010/ETC5510 Introduction to Data Analysis, Monash University.

Now move from the tool to the evaluation. This was not a lab study. It was run in a real, large introductory statistics teaching context, across the undergraduate and postgraduate versions of the unit. The unit is data-first and code-first: students meet R early and use it as part of how they learn statistics. The study used consenting student data and was approved by Monash HREC, project ID 50873.

Experimental structure

Tutorial activity

• tutorial groups allocated to a version
• one version used ggplotbattles
• the other used a traditional activity
• allocation alternated across the two tasks

Measurement

• pre-quiz before the activity
• post-quiz after the activity
• scores scaled from 0 to 1
• outcome: post minus pre

The design was pragmatic. Tutorial-level allocation made the activity deliverable with real tutors and real timetables. In Task 1, the red group used ggplotbattles; in Task 2, the blue group used it. That alternation helps avoid simply comparing two fixed groups of students. The analysis outcome is deliberately simple: improvement in quiz score from before to after the activity.

The two tasks

Task 1

Introductory ggplot2 concepts:

• bar charts
• grouped summaries
• column geometry
• faceting

Task 2

More connected visualisation choices:

• factor ordering
• flipped coordinates
• tile geometry
• fixed coordinates
• continuous colour scale

The two tasks were designed to differ in the amount of coordination required. Task 1 is closer to introductory grammar-of-graphics vocabulary. Task 2 asks students to coordinate factor manipulation, coordinates, geoms, and colour scales. That distinction becomes important when interpreting the results: an activity based on iterative feedback should be most useful when there is actually something to iterate on.

The prequiz was too easy

79% mean pre-quiz score, Task 1

94% mean pre-quiz score, Task 2

37 task attempts with room to improve

The full-sample analysis mostly measures what the quiz could detect.

This is the honest measurement slide. The pre-quiz scores were high, so there was a ceiling effect. Students who already scored perfectly may still have learned something or consolidated understanding, but a short code-completion quiz could not observe that gain. This is why the paper treats the students with non-perfect pre-quiz scores as an important secondary analysis rather than pretending the measurement was ideal.

What changed for students with room to improve?

This plot shows the restricted analysis: only students who did not start with a perfect pre-quiz score. Each line is a student, going from pre to post. The visual story is that the clearest improvement pattern appears in Task 2 for the ggplotbattles group. Task 1 is messier and has very small cells after restriction, which is exactly why I would not overclaim it.

Estimated ggplotbattles effect

This is the regression version of the same message. Among students with room to improve, the estimated ggplotbattles effect in Task 2 is about 0.54 for undergraduate students and about 0.50 for postgraduate students, on a score scaled from 0 to 1. The intervals are still wide because the eligible sample is small, but both cohorts show the same direction. Task 1 does not show a meaningful difference.

The interpretation

ggplotbattles seems most useful when the task requires several connected ggplot2 decisions.

That is the setting where immediate visual feedback can help students:

• test a hypothesis about code
• compare output against intent
• revise without waiting for a tutor
• learn from nearby attempts

This is the main take-home message. I would phrase it carefully: the study supports ggplotbattles as a targeted formative activity, not as a universal replacement for tutorial teaching. It is especially plausible for tasks that involve multiple connected decisions. That is also consistent with the design of the tool: the value is in fast feedback on visual consequences.

What I would change next time

• use harder and more discriminating pre-quiz items
• add open-ended plotting tasks
• use trace data from battle attempts
• assess delayed retention
• balance tutorial allocation more tightly

The limitations are not just caveats; they are a design agenda for the next evaluation. The quiz was too blunt, especially for students who came in prepared. I would want an outcome that can detect debugging, reasoning, and transfer, not just choosing a missing line of code. The tool itself also creates rich trace data: attempts, scores, timing, and revision paths. That is probably the most interesting next measurement layer.

Where the system goes next

Teaching use

• build battles aligned to weekly learning goals
• use them as formative tutorial activities
• let tutors discuss common wrong turns

Development

• More battles
• Improved scoring system reducing false positives
• More choices around dataset and styling choies

This is where I would return to the system. The nice thing about the platform is that new battles are the curriculum surface. More battles means more targeted practice. The future system work is making the IDE feel more familiar, improving categorisation, and potentially adding accounts or scoring histories. But the teaching point remains: the software should make practice and feedback easier, not distract from the visualisation objective.

Takeaway

Students learn data visualisation by making code choices, seeing the visual consequences, and trying again.

ggplotbattles gives that loop a classroom shape.

ggplotbattles.dev

Close by bringing the talk back to the loop. The result is promising but measured: there is a signal when students have room to improve and the task is complex enough for feedback to matter. The broader claim is that we can design statistics teaching tools around the actual practice we want students to develop. For data visualisation, that practice is iterative, visual, and social.