Custom CSS / SCSS Governance
Regeln für Custom CSS: Scope, Kommentare, Testpfade und Review.
Kurz erklärt
Diese Seite beschreibt den Arbeitsstandard für Custom CSS / SCSS Governance – mit Fokus auf konkrete Entscheidungen statt allgemeiner Leitlinien.
Zentral sind hier vor allem welche anpassungen im theme erlaubt sind und wie ui-abweichungen freigegeben werden, damit Teams denselben Maßstab anwenden.
Nachvollziehbar wird der Standard erst durch verlinkte Nachweise wie design-entscheidungen und durch dokumentierte Grenzfälle/Ausnahmen.
Wann diese Seite hilft
Typische Situationen, in denen diese Seite als Arbeitsdokument Mehrwert bringt – und wo eine andere Doku passender ist.
Typische Einsätze
- wenn Custom CSS / SCSS Governance als wiederverwendbarer Moodle-Standard mit klaren Vorgaben zu theme-standards, tokens und designregeln dienen soll
- wenn Autor:innen/Trainer:innen bei welche anpassungen im theme erlaubt sind uneinheitlich arbeiten
- wenn Qualitätssicherung und Freigaben mit design-entscheidungen nachvollziehbar dokumentiert werden sollen
- wenn Support- oder Kursfeedback auf einen typischen Stolperpunkt hindeutet (z. B. einzelfall-css ohne governance wächst an)
Eher nicht passend bei
- wenn es bei Custom CSS / SCSS Governance nur um einen einmaligen Einzelfall ohne Standardisierungsbedarf geht
- wenn ein detailliertes Projektticket oder eine technische Schritt-für-Schritt-Anleitung gepflegt werden soll
Empfohlener Ablauf
Pragmatische Reihenfolge, die in der Praxis funktioniert – vom Scope bis zum Review.
- Use Case und Zielgruppe von Custom CSS / SCSS Governance kurz beschreiben; daraus Scope und erwartetes Lernergebnis ableiten.
- Standardaufbau/-konfiguration festlegen, insbesondere welche anpassungen im theme erlaubt sind und wie ui-abweichungen freigegeben werden.
- Mit Testnutzer oder Referenzkurs prüfen, ob theme-standards, tokens und designregeln in der Praxis funktionieren.
- Qualitätssicherung/Freigabe durchführen und Artefakte wie design-entscheidungen verlinken.
- Nach Livegang Rückmeldungen auswerten und Fehlerbilder wie „Einzelfall-CSS ohne Governance wächst an“ als Stolperfalle ergänzen.
Entscheidungsregeln
Custom CSS / SCSS Governance ist gut dokumentiert, wenn Regeln, Grenzfälle und Nachweise so konkret sind, dass Teams damit ohne Zusatzabsprachen arbeiten können.
Scope & Wirkung
Für Custom CSS / SCSS Governance zuerst den Anwendungsbereich konkret machen: Theme-Standards, Tokens und Designregeln.
Freigaberegel
Entscheidungen zu welche anpassungen im theme erlaubt sind und wie ui-abweichungen freigegeben werden nicht implizit lassen, sondern Rollen und Freigaben explizit benennen.
Ausnahmen sauber halten
Ausnahmen nur zulassen, wenn sie den Standard nicht aufweichen; besonders relevant sind hier custom css/js und pflegegrenzen.
Prüfbarkeit
Prüfbar ist die Regel erst, wenn design-entscheidungen und screenshots / review-nachweise sauber verlinkt sind.
Was dokumentiert werden soll
Hier nur die spezifischen Inhalte zu Custom CSS / SCSS Governance pflegen; allgemeine Doku-Regeln bleiben in der zentralen Leitlinie. Zentrale Leitlinie.
Die Seite ist dann gut, wenn eine Vertretung den Standard anwenden oder prüfen kann, ohne erst Personenwissen einsammeln zu müssen.
Anwendungsbereich
Begriffe, Scope und Grenzen zu Custom CSS / SCSS Governance konkretisieren – inklusive theme-standards, tokens und designregeln.
Konkrete Parameter/Regeln
Den Standard so notieren, dass welche anpassungen im theme erlaubt sind und wo branding vs. standard priorisiert wird eindeutig entschieden sind.
Artefakte
Artefakte direkt nennen und verlinken: Design-Entscheidungen, Screenshots / Review-Nachweise, Änderungshistorie Theme/CSS.
Versionierung
Aktive Ausnahmen, letzte Änderung und nächster Review gehören auf die Seite – besonders bei Themen mit custom css/js und pflegegrenzen.
Typische Stolperfallen
Pflege hier echte Fallstricke aus der Praxis von Custom CSS / SCSS Governance; allgemeine Hinweise gehören in die zentrale Leitlinie. Zentrale Leitlinie.
- Umfang driftet: Einzelfall-CSS ohne Governance wächst an.
- Regel bleibt abstrakt: Branding überschreibt Usability-Regeln.
- Nachweis fehlt: Theme-Anpassungen brechen nach Upgrade.
- Ausnahme entgleist: Kursstruktur wird aus Altkurs kopiert ohne Bereinigung.
Moodle-Referenz (offizielle Doku 5.1)
Kurze Verweise auf die offizielle Moodle-Dokumentation für Custom CSS / SCSS Governance. So bleibt diese Seite AFANDI-spezifisch und vermeidet doppelte Grundlagen.
Offizielle Referenzen
Dokumentationsfokus
- Custom CSS mit Scope, Owner und Regressionstest nach Theme-/Moodle-Updates dokumentieren.
- UI-Pfad, Rolle und Testfall explizit notieren (nicht nur den gewünschten Endzustand).
- Abweichungen von AFANDI-Standards separat markieren, damit Updates leichter reviewbar bleiben.
Prüfung & Pflege
Prüfe diese Seite gegen reale Vorgänge zu Custom CSS / SCSS Governance – nicht nur gegen den Wortlaut. Entscheidend ist, ob Standard, Ausnahmen und Nachweise im Alltag tragen.
- Sind Customizations noch upgrade-fähig?
- Passen UI-Elemente zum Standard?
- Wurden Sonderlösungen reduziert?
- Passt die Struktur zum aktuellen Use Case?
Prüf-Fokus für „Custom CSS / SCSS Governance“: Theme / UI; prüfe dabei insbesondere theme-standards, tokens und designregeln.
Sinnvolle Kennzahlen
Wenige Kennzahlen genügen – wichtig ist, dass sie Entscheidungen oder Verbesserungen auslösen.
Für „Custom CSS / SCSS Governance“ Kennzahlen direkt an welche anpassungen im theme erlaubt sind und die häufigsten Praxisrisiken koppeln.
UI-Abweichungen
Anzahl freigegebener Theme-Ausnahmen
Intervall: monatlich
Upgrade-Nacharbeit Theme
Aufwand nach Moodle-Upgrade für Theme-Fixes
Intervall: pro Release
Design-Review-Quote
Anteil UI-Änderungen mit Review-Nachweis
Intervall: monatlich
Nächste Schritte
Ergänze jetzt die konkrete Entscheidung zu welche anpassungen im theme erlaubt sind inkl. Verantwortlichen, Datum und Verweis auf design-entscheidungen.
Auf „Custom CSS / SCSS Governance“ als Nächstes besonders klar machen: welche theme-standards, tokens und designregeln im Standardfall gelten und welche Ausnahmen befristet sind.