Theme & UI Standards

Wartbare Theme-/UI-adaptations in the Corporate Design without unnecessary Sonderwege.

Moodle AFANDI standard Handover-ready documentation reviewed on a regular cycle

Quick overview

This page describes the working standard for Theme & UI Standards – with a focus on concrete decisions rather than general guidance.

The main focus here is which anpassungen in the theme erlaubt are and such as ui-abweichungen freigegeben be so that teams apply the same standard.

The standard only becomes traceable through linked evidence such as design-decisions and through documented edge cases/exceptions.

Practical focusTopic-specificVerifiable

When this page helps

Typical situations in which this page adds value as a working document, and where another document is more appropriate.

Typical use cases

when Theme & UI Standards as a reusable Moodle standard with clear requirements for theme-standards, tokens and designregeln should serve
when authors or trainers work inconsistently on which anpassungen in the theme erlaubt are
when Quality assurance and approvals with design-decisions should be documented in a traceable way
when Support- or course feedback points to a typical pitfall (e.g. einzelfall-css without governance grows an)

Less suitable when

when Theme & UI Standards only about a one-off individual case without need for standardization applies
when a detailed project ticket or a technical step-by-step guide is the better fit

Recommended process

A pragmatic sequence that works in practice, from scope to review.

Briefly describe the use case and target audience for Theme & UI Standards briefly describe; from that scope and expected learning outcome derive the scope and expected learning outcome.
standard setup/configuration define, especially which anpassungen in the theme erlaubt are and such as ui-abweichungen freigegeben be.
Use test users or a reference course to check whether theme-standards, tokens and designregeln work in practice.
Quality assurance/approval carry out and link evidence such as design-decisions link.
After Livegang feedback auswerten and error patterns such as „individual case-CSS without Governance grows an“ as pitfall add.

Decision rules

Note: Central standards remain ausgelagert. Here be only the for Theme & UI Standards relevant decisions, Evidence and Exceptions maintained. Central guideline.

Theme & UI Standards is well documented, when rules, Edge cases and Evidence so clearly are, dass teams so that without additional coordination work can.

scope

For Theme & UI Standards first define the scope clearly: Theme-Standards, Tokens and Designregeln.

Priorities

decisions about which anpassungen in the theme erlaubt are and such as ui-abweichungen freigegeben be not implizit lassen, sondern roles and approvals explicitly benennen.

Exceptions

Allow exceptions only if they do not dilute the standard; especially relevant here are custom css/js and maintenance boundaries.

Evidence logic

Verifiable is the rule only, when design-decisions and screenshots / review-evidence cleanly verlinkt are.

What should be documented

Here only the spezifischen Inhalte about Theme & UI Standards maintain; general documentation rules remain in the centraln guideline. Central guideline.

The page is good when a substitute can apply or review the standard without first collecting tribal knowledge.

scope & terms

terms, scope and boundaries about Theme & UI Standards specify in concrete terms, including theme-standards, tokens and designregeln.

Binding rules

Den standard so record, dass which anpassungen in the theme erlaubt are and where branding vs. standard priorisiert becomes eindeutig entschieden are.

Evidence & filing

Name and link evidence directly: Design-decisions, Screenshots / review-Evidence, changeshistorie Theme/CSS.

Exceptions & Historie

Aktive Exceptions, the latest change and the next review belong on the page—especially for topics with custom css/js and maintenance boundaries.

Common pitfalls

This section captures real-world pitfalls from Theme & UI Standards; general guidance belongs in the central guideline. Central guideline.

scope driftet: individual case-CSS without Governance grows an.
the rule is too abstract: Branding overwrites Usability-rules.
evidence is missing: Theme-adaptations brechen after Upgrade.
the exception gets out of control: Coursestruktur becomes aus Altcourse kopiert without Bereinigung.

Tip: It is better to document three concrete observations from real cases than to keep a long generic list.

Moodle reference (official docs 5.1)

Kurze Verweise on the offizielle Moodle documentation for Theme & UI Standards. So remains this Page AFANDI-spezifisch and vermeidet doppelte Grundlagen.

Official references

Documentation focus

UI-Standards immer with Beispielscreenshots je role and Gerät document.
UI path, role and test case record explicitly (not only the desired target state).
Mark deviations from AFANDI standards separatelyely so that updates remain easier to review.

Note: Moodle interfaces, paths, and options can vary depending on the version, theme, and enabled plugins. Therefore always include the version, role, and test context on the page.

Review & maintenance

Check this Page gegen reale processes about Theme & UI Standards – not only gegen the Wortlaut. Entscheidend is, ob standard, Exceptions and Evidence in the Alltag contribute.

Are Customizations still upgrade-ready?
Passen UI-Elemente to the standard?
Were Sonderlösungen reduziert?
Passt the Structure to the aktuellen Use case?

Review focus for „Theme & UI Standards“: Theme / UI; check especially theme-standards, tokens and designregeln.

Useful metrics

A few metrics are enough – what matters is that they trigger decisions or improvements.

For „Theme & UI Standards“ Kennzahlen directly an which anpassungen in the theme erlaubt are and the most frequent Praxisrisiken koppeln.

UI-deviations

Anzahl freigegebener Theme-Exceptions

Interval: monthly

Upgrade-Afterarbeit Theme

Aufwand after Moodle-Upgrade for Theme-Fixes

Interval: pro Release

Design-review-Quote

Anteil UI-changes with review-evidence

Interval: monthly

Next steps

Add jetzt the concrete Entscheidung about which anpassungen in the theme erlaubt are incl. Verantwortlichen, Datum and Verweis on design-decisions.

On „Theme & UI Standards“ make especially clear as the next step: which theme-standards, tokens and designregeln apply in the standard case and which exceptions are time-limited.