Skip to main content

Testing, Privacy-Safe Publishing, and the Shiny Demo

Where this fits

You have the starter dashboard (dash03) and you know what kind of changes are allowed (dash04). This page covers three things you do before you submit:

  1. Test the starter dashboard in your Codespace.
  2. Apply the privacy-safe publishing checklist.
  3. Watch (but do not run) the optional Shiny exemplar your instructor will demo in class.

Part 1 — Testing the starter dashboard

The A7 deliverable list asks for a testing-log.md. Use the routine below for the entry.

A six-step test routine

  1. Render from the personal-workspace root. Copy the workspace starter to assignments/assignment07-dashboard/submission/dashboard.qmd, open that submitted copy, and render it from the Command Palette (Quarto: Render Document). Confirm there are no errors.
  2. Change the control. Edit selected_income to a different value from available_income_groups. Save the file.
  3. Render again. Confirm the title, table, and plot all updated.
  4. Verify the caption. The caption should still name the dataset, exclusions, and limitation.
  5. Open the HTML preview. If no preview opened automatically, find the rendered .html file in the Explorer (the render log’s Output created: line names it), right-click it, and choose Open Preview — or Download to open it in your browser. If Open With only offers a text editor showing raw HTML code, the render still worked — use Open Preview or Download instead. Confirm the rendered page looks correct in the browser, not just in the editor.
  6. Record the test. In testing-log.md, note the date, the command or render path used, the values you tried, and the result.
TipHow to render: the course default

  1. Open the .qmd file you want to render, then open the Command Palette (View → Command Palette, or press Ctrl+Shift+P on Windows/Linux / Cmd+Shift+P on Mac) and run Quarto: Render Document. The Quarto extension renders the file and opens a preview pane.

  2. Always-works fallback (terminal): type the render command with the file’s path as shown in the Explorer, for example:

    quarto render practice_report.qmd

    Always name the file — a bare quarto render rebuilds the whole project and takes much longer.

  3. If you see a Render (or Preview) button in the editor toolbar, it does the same thing as step 1.

Where did the output go? Watch the render log for the Output created: line — it names the exact .html file created. By default the file appears next to your .qmd; in projects that set an output directory (like this book’s docs/ folder), it appears there instead. If no preview opened automatically, find that .html file in the Explorer, right-click it, and choose Download to open it in your browser (or Open Preview if available).

HTML is the expected output for the dashboard — a PDF is not needed. Ignore TeX- or PDF-related warnings as long as the .html file was created; do not try to install TeX.

Common failure modes and quick fixes

Failure What you see Quick fix
Wrong working directory “Could not find examples/nhanes-equity/data/nhanes_equity_v6.csv” Open the Quarto file via the Explorer and confirm Codespaces is rooted at the repo root
Missing package “there is no package called ‘ggplot2’” Run library(ggplot2) once; if it still fails, raise with your TA — do not install at random
Stale _freeze cache Output reflects the old control value Delete the relevant _freeze/ subfolder and re-render; or change the chunk slightly
Preview pane blank Render succeeds but preview is empty Click the preview pane refresh icon, or open the HTML file from docs/ (if configured)
TipPackage check before you finish

The starter uses only packages in the course devcontainer. If an additional package is approved, record it in the workspace setup and your dependency note, then repeat the test in a fresh Codespace.

Part 2 — Privacy-safe publishing

Five rules apply every time you share a dashboard rendering, a screenshot, or a Quarto preview.

  1. No row-level data. Your figures and tables show aggregate summaries. Never paste a row-level NHANES record into a screenshot, a chat with an external AI, or a public README.
  2. No small-cell interpretations. If a group has very few records, do not interpret the cell. Combine, mark, or exclude the group (see eda04).
  3. State descriptive limits. Every interpretation should say the artifact is descriptive and unweighted. No causal language. No “national prevalence” language.
  4. Keep cached data separate from raw retrieval. The course uses a cached CSV intentionally. If you write code that retrieves raw NHANES from the CDC, document that as separate work — do not put a live API call in your dashboard.
  5. Do not upload row-level data to external AI tools. Aggregate first. The AI conversation can see counts and means; it should not see individual records.

Three of those terms, with examples

  • Row-level data is one person’s record. “Participant 93704: age 47, BMI 31.2, Low Income” is row-level. “n = 214, mean BMI 29.1” is an aggregate summary and is safe to show.
  • A small cell is a group with very few people behind it — for example, a table cell where n = 3. With numbers that small, a person could be identifiable and the estimate is unstable, so combine, mark, or exclude the group instead of interpreting it.
  • Causal overreach is wording that claims the data shows cause. “Low income causes higher BMI” is overreach. “Mean BMI was higher in the low-income group in this classroom dataset” stays descriptive and is fine.

What to write in privacy-check.md

A6 and A7 both expect a short privacy check. For A7, write three sentences:

  • One naming the data source and the classroom-use boundary (reuse from eda05).
  • One confirming the dashboard renders aggregate summaries only.
  • One confirming you did not share row-level records with any external AI tool.

Part 3 — The Shiny exemplar (demonstration only)

WarningDemo only — not graded

This pathway is a demonstration only. It is not graded and not required. Using it for graded work requires instructor approval first. The supported, graded pathway in this course is the Quarto workflow.

Your instructor will demo a Shiny app version of the NHANES dashboard in class. You are not required to run this app, install Shiny, or produce anything from it. Your A7 deliverable is built from the Quarto starter dashboard, not from this app.

What the demo will show you:

  • How a Shiny app turns the same kind of analysis into a live, server-backed dashboard with reactive controls.
  • The trade-offs: more interactivity, but it requires a server (or a Codespaces port forward), more packages, and more failure modes.
  • Where the app code lives (examples/nhanes-equity/app/app.R) if you want to read it.

If, after watching the demo, you decide you want to use Shiny for your term-project final dashboard, that pathway is not approved by default. Talk with your instructor before committing. The Quarto pathway is the supported default for every student.

Warning

Do not put shiny::runApp(...) in your A7 submission as your “dashboard.” A7 expects an adaptation of the Quarto starter. The Shiny app is shown to you; it is not what you build on.

Where this goes next

dash06 is the in-class studio where you produce draft versions of every A7 deliverable from the Quarto starter.