Design System Adoption Dashboard

This is an internal dashboard. Enter the shared password to continue.

Incorrect password.

Design System Adoption Dashboard

loading —

Weekly snapshot of moodle/moodle's public GitHub main branch. Excludes Moodle's private GitLab integration branch until it merges to GitHub. A structural, static read of the source tree — not a runtime measurement of a live site.

Tokens

Token usage — total

—
across all categories
What counts as a "use"

Each line of code in Moodle LMS referencing a $mds-* / var(--mds-...) token. Not deduplicated, meaning one token used on 50 lines counts as 50 uses.

Coverage by eligible CSS attributes

—
What counts as "eligible"

Colour, spacing, radius, border-width, typography — excludes everything else (icons, breakpoints, etc.) and excludes compiled/generated theme CSS.

Token usage by category

How categories are assigned

Each token is prefix-matched into one of five tracked categories (colour, spacing, radius, border-width, typography); anything outside those — avatars, icons, breakpoints, blur, activity-icon, switch-track — lands in "other" rather than being dropped.

Coverage by category

How this is calculated

For each category, this shows what share of styling already uses design tokens, out of all styling in that category (tokens plus old hard-coded values still in use). The "Other" category is left out because we don't have a comparable count of its legacy values.

Coverage trend by category

Coverage methodology

Coverage = token usage ÷ (token usage + remaining non-tokenised literals in Boost's SCSS), combined across all five tracked categories — not colour alone.

  • Colour: a whole-file hex/rgba scan.
  • Spacing, radius, border-width, typography: a declaration-level scan (property: value;) against a fixed property list.

Both are rough proxies, not a curated catalogue — treat the figure as directional, not precise.

Components

Component usage — total

—
across all components, this scan
What counts as a "use"

Each line of code importing or using a @moodlehq/design-system component. Not deduplicated: one component used on 50 lines counts as 50 uses.

Files reached by the design system

—
files that use these components, directly or indirectly
What does this measure?

The number of distinct files that connect to a design-system component, directly or through other files that depend on them. Each file is counted once, even if several components reach it.

Coverage by screens using the design system

—
What counts as a screen "using" the design system?

Counts a screen as soon as one design-system component appears on it, however small a share of the screen that is. Tracks breadth (how many screens were touched), not depth (how converted each one is).

Component usage by component

Coverage by screens using the design system — trend

Coverage methodology

This adds up three kinds of screen:

    Measures breadth (does a surface show MDS at all), not depth (what fraction of that surface's markup is MDS) — a page that's 1% MDS and one that's 100% MDS count identically.

    Attributions

    Contributor breakdown

    What's being counted?

    Counts MDS token and component-import lines (not commits), credited via git blame to whoever last touched each line — so an edit or reformat can shift credit away from who first added it.

    New adopters this week

    Plugin-type breakdown

    Area / component breakdown

    Adoption breadth over time

    Attribution methodology
    • Contributor: git-blame on each matched line, credited to whoever last touched it.
    • Plugin / type: a best-effort guess from the file's path, using Moodle's "frankenstyle" plugin-naming convention (e.g. mod_forum, block_html) — not a curated mapping.

    Technical details

    See the technical details

    Where it's been adopted

    Every file this scan found outside the design-system package, and how many distinct templates transitively include it.

    TypeFileReach
    loading —

    How each number is counted, and where it falls short