Interactive Dashboards
Self-contained HTML dashboards for the sample datasets
statistical dashboard, meta-analysis forest plot, ANCOVA, retail uptime, S-value, surprisal, OpenAlex, bibliometrics, Chart.js, reproducible analysis
Five single-file HTML dashboards. Three are built on top of the sample datasets and embed their own data; the other two query live APIs — the OpenAlex bibliometric API and the Google PageSpeed Insights (Lighthouse) API. Each one runs entirely in the browser — no Python, no R, no backend. Filters, sorting, and chart updates are all client-side. Refreshing one of the static dashboards with new data means editing the const DATA = {...} blob near the top of one <script> tag. Results: a two-arm BP trial of 39 subjects (between-group mean difference −10.46 mmHg, 95% CI −12.23 to −8.69), a six-trial PUFA meta-analysis (pooled RR 0.875, 95% CI 0.764 to 1.001, I² = 16%), seven days of operational data across 70 stores (aggregate uptime 88.2%), a live count of papers citing and reporting the S-value / surprisal transform, and a live Lighthouse audit of the site itself — Core Web Vitals, category scores, and field data on demand.
At a glance
| Dashboard | Method | n | Headline result | Open |
|---|---|---|---|---|
| BP trial | Paired pre/post + Welch + ANCOVA | 39 subjects | Mean diff −10.46 mmHg [95% CI −12.23, −8.69], p < 0.0001 | ↗ |
| PUFA meta-analysis | DerSimonian–Laird random-effects | 6 trials | Pooled RR 0.875 [0.764, 1.001], I² = 16% | ↗ |
| Atlantis store uptime | Online ÷ (Online + Offline) minutes | 70 stores × 7 days | Aggregate uptime 88.2% across 5 regions | ↗ |
| S-value adoption | Live OpenAlex citation + full-text query | 3 seed papers | Cited and reported counts updated on page load | ↗ |
| PageSpeed / Lighthouse | Live Google PageSpeed Insights (Lighthouse) audit | 8 site pages | Category scores, lab Core Web Vitals & field data on demand | ↗ |
The three static dashboards together total ~140 KB of HTML+JS plus one shared CDN load of Chart.js v4; the S-value and PageSpeed trackers each add another self-contained file that fetches its data live (from OpenAlex and the Google PageSpeed Insights API, respectively). All five embed cleanly into this page with sandboxed iframes; nothing here loads from your origin until you scroll to it.
Diastolic blood pressure trial
A two-arm trial of n = 39 subjects (Group A n = 20, Group B n = 19) with paired baseline and post-treatment diastolic blood pressure (DBP), age, and sex.
What’s in the dashboard
- Six KPI cards (sample size, per-group mean change, between-group difference, effect size, p-value)
- Paired pre → post chart, one line per subject
- Distribution of DBP change by group
- Subgroup forest plot by group × sex
- Hypothesis-test panel with paired t-test, Welch’s t-test on changes, and ANCOVA-adjusted effect — all with 95% CIs and Cohen’s dz / Hedges’ g
- Sortable subject-level table
The between-group effect size (Hedges’ g ≈ −3.75) is implausibly large for a real antihypertensive trial — within-group variance is unusually compressed. Useful as a worked teaching example, but worth flagging if cited as evidence of effect magnitude.
PUFA meta-analysis — forest plot
Pooled risk ratios from six classic trials of polyunsaturated fatty acid replacement vs. control diet for cardiovascular events: DARTS, LA Veterans, Minnesota Coronary Survey, MRC Soy, Oslo Diet Heart, STARS.
What’s in the dashboard
- Per-study risk ratio with 95% CI and weight (random-effects)
- Pooled diamond at the bottom of the forest, model toggle (random-effects ↔︎ fixed-effect), scale toggle (log ↔︎ linear)
- Heterogeneity panel: Cochran’s Q, df, p, I², τ²
- Event-rate bar chart by arm and study
- Study-weight bar chart
The pooled random-effects estimate sits right at the conventional significance threshold (RR 0.875, 95% CI 0.764 to 1.001, p ≈ 0.052) — heterogeneity is low (I² = 16%), so fixed-effect and random-effects estimates barely diverge.
Atlantis Fresh Market — store uptime
Operational data from 70 c-store / fresh-market locations across five regions (Connecticut, Western MA, NYC Suburbs, New Jersey, New York City) over a seven-day window in April 2022. Records minutes Online, Offline, and Menu Available per store-day.
What’s in the dashboard
- KPI cards for store count, aggregate uptime, total online/offline time, and date range
- Daily uptime line chart by region (with a network-average overlay)
- Bottom-15 stores by uptime, color-coded by health band
- Store × day uptime heatmap (real per-day variation, hover for cell-level detail)
- Region rollup table and full store-level table, both sortable
S-value adoption tracker
A live bibliometric view of who is actually using the S-value (Shannon-information / surprisal) transform of p-values. The dashboard queries the OpenAlex API on page load and counts works that cite at least one of three seed papers:
- Greenland, Valid P-values behave exactly as they should (Am. Statistician, 2019)
- Rafi & Greenland, Semantic and cognitive tools to aid statistical science (BMC MRM, 2020)
- Cole, Edwards & Greenland, Surprise! (AJE, 2021)
What’s in the dashboard
- Two tabs — Cited (deduplicated union of works citing any seed) and Reported in text (the subset that also mentions
"s-value"orsurprisalin OpenAlex-indexed full text) - KPI cards for total cites, all-time reporters, and the most recent year on file
- Per-year, cumulative, and per-seed views of citation counts
- Cited-vs-reported comparison and a reporting-rate trend
- Recent papers list with year, title, venue, and DOI link
- Light/dark theme with a
?theme=darkoverride
The reported-in-text count is a lower bound — OpenAlex only indexes full text for a subset of works, so a paper that uses S-values in the Methods may still not match. Trust the trend, not the absolute integer; the strict Methods-only count from the Europe PMC open-access corpus is single digits and too sparse to chart. See the related post S-values for the underlying transform.
PageSpeed / Lighthouse tracker
A live performance audit of the site itself. Pick any of eight representative pages and a device profile, and the dashboard calls the Google PageSpeed Insights API — which runs a full Lighthouse audit on Google’s servers — then renders the result. It is the only dashboard here that measures this website rather than a teaching dataset.
What’s in the dashboard
- Four Lighthouse category gauges — Performance, Accessibility, Best Practices, SEO — colored by Lighthouse’s own 0–100 bands (green ≥ 90, amber 50–89, red < 50)
- Lab Core Web Vitals and loading metrics as KPI cards: LCP, CLS, TBT, FCP, Speed Index, and Time to Interactive, each with its per-metric pass/fail band
- A Mobile ↔︎ Desktop toggle (the two strategies Lighthouse scores separately) and a page selector
- An Opportunities tab: the audits with the largest estimated load-time savings, as a ranked bar chart and table
- A Field data tab: real-user Core Web Vitals from the Chrome UX Report (28-day, 75th-percentile), switchable between this page and the whole origin — shown when CrUX has enough traffic for the URL
The API is queried keyless by default, which shares a rate-limited anonymous quota — if an audit fails with a quota error, wait a moment and re-run, or append ?key=YOUR_PSI_KEY to the dashboard URL to use a referrer-restricted PageSpeed Insights API key. Lab scores vary run-to-run (Lighthouse simulates a throttled network), so treat a single number as a snapshot, not a constant. Field data is absent for low-traffic pages — CrUX only reports URLs with enough real Chrome traffic.
Implementation notes
Each dashboard is a single self-contained HTML file. The chart library (Chart.js v4) loads from a CDN; everything else — data, layout, interactivity — is inline. To customize:
- Update the data — replace the
const DATA = {...}blob near the top of the<script>tag. - Restyle — the
:rootCSS variables at the top of each file control the color palette and spacing. - Add a chart — Chart.js v4 is already loaded; new canvases can be appended without touching anything else.
The source CSVs live in datasets/ and are downloadable directly.
Three reasons. First, each dashboard ships its own <script> block with global variable names (DATA, charts, etc.) — inlining all four on one page would collide. Second, iframes give us a clean security boundary (sandbox="allow-scripts allow-same-origin allow-popups" blocks the embed from navigating the parent or accessing storage outside its own origin). Third, loading="lazy" defers the iframe payload until you scroll near it, so this page’s Largest Contentful Paint stays fast even with four embeds. The cost is a fixed-height container per embed; the aspect-ratio CSS reservation prevents any layout shift (CLS) once they load.
Comments