Skip to main content

What a Dashboard Is, and Three Pathways

Goal

Last week you produced an audited Table 1. This week turns one descriptive finding from that table into a small audience-facing artifact — a dashboard-style KT product. Before you build, get clear on what a dashboard is, what it is not, and which pathway you will use in this course.

A dashboard is not a report

A short way to remember the difference:

  • A report tells a fixed story to a known audience. It loads, renders, and stays the same.
  • A dashboard lets a defined audience answer one question with one or two controls. The audience moves through the artifact and pulls out the slice that matters to them.
  • A data warehouse is neither. It stores everything for someone else to query.

You are building the middle one. The audience is real (an analyst, a project team, a briefing group). The control is small (one dropdown, one filter, or one editable value). The interpretation and the limitation stay attached to whatever the audience sees.

A dashboard is not a free pass to be sloppy. It can mislead just as easily as a single figure can. Everything you learned in Weeks 6 and 7 about scale, captioning, missingness, and stewardship still applies.

Three pathways, three roles in this course

Pathway What it is When it makes sense Role in this course
Quarto dashboard-style page A rerunnable .qmd with one or two editable values, a visualization, a table, an interpretation, and a limitation Default; works in every Codespace; no server Required core for A7
Shiny app exemplar A live R server with reactive UI controls When real-time interactivity matters and you can host or run a server Demonstration only — your instructor will run this in class
Static HTML/JS dashboard AI-generated self-contained files When a public-facing portfolio piece must run without a server Optional demo in Week 11

The required A7 deliverable is built on the Quarto pathway. Shiny and static HTML/JS are shown so you know they exist; they are not required of any student.

Decision rule for your term project

When you choose a dashboard pathway for your team’s final portfolio, use the simplest pathway that serves your audience:

  • If a .qmd page with one editable value answers the audience question, that is the right choice.
  • If real-time interactivity is essential and your team can run/host a server, the Shiny pathway is open — with instructor approval, since it is not a default course pathway.
  • If a static, public-facing artifact is required, the Week 11 static HTML/JS demo path is the option to explore.

There is no rubric bonus for using a more complex pathway. The grading rubric measures audience fit, audit quality, and reproducibility — not technical flash.

What “dashboard-style” means for Quarto

You will see this phrase throughout Week 8. It means a Quarto page that:

  • loads the cached classroom dataset with a relative path,
  • declares one control value as an editable R variable near the top of the file,
  • shows one table and one visualization that update when the control changes,
  • ends with one interpretation sentence and one limitation sentence.

That is what the starter dashboard does, and that is what your A7 adaptation will continue.

What “demonstration only” means for Shiny

You will see the Shiny exemplar run live in class. You will be invited to open the URL the instructor shares and click around. You will not be required to:

  • install or load Shiny in your own Codespace,
  • run shiny::runApp(...) yourself,
  • modify the Shiny app code,
  • produce any A7 deliverable from the Shiny app.

If you find Shiny interesting and want to explore it for your term project, talk with your instructor before committing — Shiny is not a default approved A7 pathway and not a default approved final-portfolio pathway.

Where this goes next

dash02 shows the “1-1-1-1-1 rule” that lets you translate one Week 7 finding into a dashboard sketch.