Feature request: dynamically generated line charts for time-series data on hub and contributor pages

[DominicBM]

Summary

Add JavaScript-rendered line charts to hub and contributor overview pages, using data already returned by the dashboard's existing API calls. Charts would occupy the currently empty middle-column whitespace and give partners a visual sense of traffic trends over time without requiring any additional backend work.

Reference implementation

The Wikimedia metrics dashboard at https://pro.dp.la/projects/dpla-wikimedia/metrics generates charts dynamically from tabular data using JavaScript. The same approach — reading data already present in the page and rendering it client-side — would work here without any new server-side endpoints.

Where charts would appear

Hub and contributor overview pages (main data page)

The overview page currently has a layout with three cards across the top (Totals, Wikimedia Integration, Metadata Completeness) and a DPLA Website section below. The middle column between the top cards and the website section, or within the website section itself, has available whitespace that could accommodate a line chart.

Most relevant data for charting:

• Item views over time (monthly, for the selected date range)
• Click-throughs over time
• Sessions over time

A multi-line chart with toggleable series would let partners see trends across all three metrics in one view.

Wikimedia subpage (/wikimedia_preparations)

Currently shows static summary numbers (upload count, page views, files in use, etc.) with no time dimension. The Wikimedia Commons Impact Metrics API returns monthly page view data, which is already stored in the wikimedia_cache table. A line chart of Wikimedia page views over time would make meaningful use of this historical data and fill the largely empty space on that page.

Technical approach

• Use a lightweight JavaScript charting library — Chart.js is the most likely fit given the existing asset pipeline; D3.js is an option if more flexibility is needed
• Data is already present in the rendered page (or available via the existing async endpoints); no new API calls or backend endpoints should be required
• Charts render after page load, consistent with the existing async loading pattern for GA4 sections
• Monthly granularity matches how all other data is displayed in the dashboard
• Charts should respect the selected date range filter and re-render on date range change

Scope

• Hub overview page: item views / click-throughs / sessions line chart
• Contributor overview page: same, scoped to that contributor
• Wikimedia subpage (hub level): Wikimedia page views over time
• Wikimedia subpage (contributor level): same

Event sub-pages (catalog views, exhibitions, etc.) may also be candidates for charting but are a lower priority; they already have a more focused data presentation.

Notes

• This feature pairs well with Cache GA4 responses at monthly granularity to eliminate load-time latency #289 (monthly caching): once GA4 responses are cached, the data needed for chart rendering is available instantly, making chart load feel immediate rather than waiting for GA4 API calls
• The Wikimedia page view time-series data is already in PostgreSQL (wikimedia_cache) and available without any GA4 call — the Wikimedia subpage chart could be implemented independently of the caching work
• Chart colors should follow DPLA branding (#4a6fa5 blue, #d9600b orange) and be accessible (sufficient contrast, not color-only encoding)