Theme & UI Standards
Wartbare Theme-/UI-Anpassungen im Corporate Design ohne unnötige Sonderwege.
Kurz erklärt
Diese Seite beschreibt den Arbeitsstandard für Theme & UI Standards – 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 Theme & UI Standards 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 Theme & UI Standards 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 Theme & UI Standards 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
Theme & UI Standards ist gut dokumentiert, wenn Regeln, Grenzfälle und Nachweise so konkret sind, dass Teams damit ohne Zusatzabsprachen arbeiten können.
Geltung
Für Theme & UI Standards zuerst den Anwendungsbereich konkret machen: Theme-Standards, Tokens und Designregeln.
Prioritäten
Entscheidungen zu welche anpassungen im theme erlaubt sind und wie ui-abweichungen freigegeben werden nicht implizit lassen, sondern Rollen und Freigaben explizit benennen.
Ausnahmen
Ausnahmen nur zulassen, wenn sie den Standard nicht aufweichen; besonders relevant sind hier custom css/js und pflegegrenzen.
Nachweislogik
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 Theme & UI Standards 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.
Scope & Begriffe
Begriffe, Scope und Grenzen zu Theme & UI Standards konkretisieren – inklusive theme-standards, tokens und designregeln.
Verbindliche Regeln
Den Standard so notieren, dass welche anpassungen im theme erlaubt sind und wo branding vs. standard priorisiert wird eindeutig entschieden sind.
Nachweise & Ablage
Artefakte direkt nennen und verlinken: Design-Entscheidungen, Screenshots / Review-Nachweise, Änderungshistorie Theme/CSS.
Ausnahmen & Historie
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 Theme & UI Standards; 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 Theme & UI Standards. So bleibt diese Seite AFANDI-spezifisch und vermeidet doppelte Grundlagen.
Offizielle Referenzen
Dokumentationsfokus
- UI-Standards immer mit Beispielscreenshots je Rolle und Gerät 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 Theme & UI Standards – 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 „Theme & UI Standards“: 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 „Theme & UI Standards“ 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 „Theme & UI Standards“ als Nächstes besonders klar machen: welche theme-standards, tokens und designregeln im Standardfall gelten und welche Ausnahmen befristet sind.