Eine Kursvorschau muss zeigen, was Lernende später sehen

Wenn die Vorschau etwas anderes verspricht als der fertige Kurs

Eine LMS-Vorschau beginnt oft als praktische Hilfe, mit der Autoren Texte, Bilder und Seitenreihenfolge prüfen. Nutzt sie jedoch einen vereinfachten Renderer, während die Live-Akademie mit anderen Komponenten, CSS-Regeln oder Theme-Einstellungen arbeitet, wird sie unzuverlässig. Autoren geben dann einen Kurs frei, der für Lernende anders aussieht oder funktioniert.

Im regulierten Finanz- oder Kryptoumfeld kann das erhebliche Folgen haben. Eine defekte Interaktion, ein abgeschnittener Risikohinweis oder ein unlesbares Layout verursacht Nacharbeit und verzögert Veröffentlichungen. Auch das Vertrauen in die Kontrollen für Pflichtschulungen leidet. Die Vorschau sollte deshalb dieselbe technische Grundlage wie die Live-Akademie nutzen.

Ein gemeinsames Rendering-Regelwerk für zwei Modi

Das verlässliche Modell ist ein Renderer mit zwei Modi: Vorschau während der Erstellung und Auslieferung in der Live-Umgebung. Beide Modi sollten dieselben strukturierten Kursdaten erhalten, dieselben Lernkomponenten nutzen und dieselbe Mandantenkonfiguration berücksichtigen. Im Erstellungsmodus können Bearbeitungsfunktionen, Entwurfskennzeichnungen und Tools für Testdaten um das Lernerlebnis ergänzt werden. Er sollte das Lernerlebnis jedoch nicht durch eine parallele Umsetzung ersetzen.

Besonders wichtig ist diese Unterscheidung bei einem WYSIWYG-Kurseditor. WYSIWYG verspricht, was Autoren prüfen können – nicht nur, was sie anordnen können. Die Leitlinien des W3C für Authoring-Tools machen das Grundprinzip deutlich: Vorschauen sollten mindestens genauso barrierefrei sein wie die Programme, über die Inhalte genutzt werden. Eine Vorschau, die das Verhalten der Live-Umgebung auslässt, kann das nicht gewährleisten.

Marken-Tokens müssen vor der Veröffentlichung aufgelöst werden

In einem White-Label-LMS muss die Vorschau zusätzlich unterschiedliche Marken korrekt abbilden: Schriften, Farben, Logos, Abstände und Navigation. Ein nur angenähertes Design kann entscheidende Fehler verdecken. Nach Anwendung der Kundenfarben fehlt womöglich der Kontrast, eine andere Schrift verändert Zeilenumbrüche, eine Button-Beschriftung passt nicht mehr oder ein Abstand verändert die Gewichtung eines Compliance-Hinweises.

Die Theme-Konfiguration sollte als Daten vorliegen, nicht als kopiertes Stylesheet. Das Design Tokens Format Module beschreibt Tokens als Möglichkeit, Designentscheidungen über Tools und Technologien hinweg auszudrücken. In der Praxis sollte die Vorschau dieselben Tokens und mandantenspezifischen Anpassungen auflösen wie die veröffentlichte Akademie. Wird bei der Erstellung ein Kunden-Theme ausgewählt, muss es die Vorschau nach denselben Regeln verändern, die später auch für die Auslieferung gelten.

Auch responsives Verhalten gehört zu diesem Regelwerk. Autoren müssen den Kurs an den Breakpoints prüfen können, die ihre Lernenden nutzen – einschließlich schmaler mobiler Bildschirme. Die WCAG-Technik zum Reflow behandelt Layouts, die in 320 CSS-Pixel ohne Scrollen in zwei Richtungen passen. Eine reine Desktop-Vorschau zeigt nicht, ob ein Hinweisfeld überläuft, eine Tabelle unbrauchbar wird oder eine feste Aktionsleiste den Weiter-Button verdeckt.

Bei Interaktionen scheitern vereinfachte Vorschauen

Statische Inhalte können in einer vereinfachten Vorschau richtig aussehen. Ob der Kurs funktioniert, zeigt sich aber auch an seinen Zuständen: Fragen brauchen die tatsächliche Antwortprüfung, Rückmeldungen, Wiederholungsregeln und Abschlussbedingungen. Videos, Akkordeons, verzweigte Szenarien, Timer und Wissenstests müssen ihre Lade- und Fehlerzustände abbilden. Regeln, die in der Live-Akademie das Fortfahren verhindern, müssen deshalb auch in der Vorschau greifen.

Das heißt nicht, dass Autoren Zugriff auf echte Lerndaten brauchen. Die Vorschau kann mit isolierten Testdurchläufen und einer Entwurfsumgebung arbeiten. Das Verhalten der Komponenten, die Semantik für Barrierefreiheit und die Zustandsübergänge sollten jedoch identisch bleiben. Je stärker sich eine Komponente zwischen Vorschau und Live-Umgebung verändert, desto weniger aussagekräftig ist die Freigabe durch Autoren.

Eigenständiges Veröffentlichen braucht eine verlässliche Freigabeprüfung

Veröffentlichen Content-Teams selbst, wird eine originalgetreue Vorschau zur wichtigen Kontrolle. Zentrale Learning-Teams können nicht nach jeder Änderung alle Mandanten, Sprachen und Gerätegrößen manuell prüfen. Die Plattform muss Autoren deshalb die richtige Ansicht zeigen und festhalten, welche Konfiguration sie freigegeben haben. Das entlastet die Entwicklung und hält die Veröffentlichung nachvollziehbar.

Eine praktische Freigabeprüfung sollte den exakten Entwurf vor der Veröffentlichung gegen die ausgewählte Akademie-Konfiguration prüfen:

• Jede Komponente mit dem ausgewählten Mandanten-Theme und der Sprache rendern.
• Definierte Viewport-Profile für Desktop, Tablet und Mobilgeräte testen.
• Interaktive Komponenten mit Tastatur, Fokus und Screenreader prüfen.
• Pflichtfelder, Antwortregeln, Wiederholungswege und Abschlusslogik validieren.
• Die Veröffentlichung bei fehlenden Dateien, ungültigen Links oder nicht unterstützten Komponenteneinstellungen blockieren.
• Kursversion, Theme-Version und Prüfergebnis im Freigabeprotokoll speichern.

Die Übereinstimmung von Vorschau und Live-Version macht Freigaben belegbar

Für HR- und L&D-Teams erleichtert das die Arbeit: Kursverantwortliche können schneller prüfen, ohne dass Entwickler markenspezifische Seiten nachbauen müssen. Compliance sieht das tatsächliche Lernerlebnis. Und aus dem Freigabeprotokoll geht hervor, welche Kursversion für welche Akademie geprüft wurde.

App-Learning kann das zum Plattformstandard machen statt zu einer manuellen Testgewohnheit: ein Komponentensystem, ein Theme-Modell und ein gemeinsames Rendering-Regelwerk für Erstellungsvorschau und Live-Akademie. So lassen sich visuelle Abweichungen und Interaktionsfehler erkennen, bevor sie Lernende erreichen. Noch wichtiger: Die Freigabe durch Autoren wird belastbar. In einem gebrandeten Lernsystem sollte die Erfahrung vor der Veröffentlichung genau der entsprechen, die danach ausgeliefert wird.