Die Webwissenschaftler

Was machen Menschen mit dem Web, was macht das Web mit den Menschen?

Menü Schließen

What about #noLMS technology?

Vorsicht, Edunerd-Content! Tut mir leid, aber dieser Tweet von Anja Lorenz hat die Diskussion um Learn Management Systeme (LMS) mal wieder gut zusammengefasst und mich wieder mal zum Nachdenken gebracht:

ILIAS und Moodle sind beides LMS. Die große Kritik an ihnen ist meist, dass diese eine Vielzahl von (interaktiven) Funktionen bieten, aber eben meist nur für den Upload von PDF-Folien durch Lehrende genutzt werden. Die Gründe hierfür können vielfältig sein, aber LMS bleiben somit eben hauptsächlich PDF-Schleudern.

In diesem Beitrag versuche ich anhand der Entwicklung von #noSQL-Datenbanken, die als Alternative für die jahrzehntelang gebräuchliche SQL-Datenbanken populär wurden, eine erste Idee von #noLMS als Alternative für klassische LMS zu entwerfen.

Großer Wohnblock grau in grau mit vielen Fenster

Foto: Pixabay/CC0

Foto eines Gartenhäuschens mit bunten Blumen davor

Foto: Schueler-Design, CC0/Pixabay

Für die Freunde von Metaphern:

Derzeit sind LMS eher große Wohnblocksiedlungen, in denen alles meist grau und gleich aussieht. Ich finde, dass Kurs-Lernangebote an Hochschulen in Zukunft aber eher wie deutsche Kleingartensiedlungen sein sollten – es gibt zwar viele Vorschriften und eine Vereinsordnung, aber(!) man kann selber etwas anbauen und den Garten innerhalb dieser Rahmenbedingungen bunt und kreativ gestalten sowie auch experimentieren. Und man ist gerne dort.

Wie komme ich darauf? Jetzt wird es wirklich nerdy, sorry:

SQL vs. noSQL?

Screenshot einer klassischen SQL-Datenbanktabelle mit id und einen vorgefertigten Feldern

Eine klassische Tabellenstruktur in MySQL

Im entfernten Sinne erinnert mich die Diskussion ein bisschen an die relationale Datenbanktechnologie SQL. Mit dieser können Daten ganz ordentlich zeilenweise in Datenbankentabellen abgelegt werden, ähnlich wie in einem Exceldokument. Voraussetzung ist, dass vorher alle Spalten ordentlich vordefiniert werden – also z.B. bei einer Benutzerprofil-Tabelle wie lang der Vorname maximal sein darf, welches Datumsformat für das Datum genutzt werden soll, ob ein Feld ein Pflichtfeld ist usw.. Es können logischerweise nur Daten gespeichert werden, wenn eine Spalte existiert. Möchte man etwas zusätzlich erfassen, muss zuerst die Datenbankstruktur angepasst werden. Also wenn zum Beispiel noch das Lieblingsgericht erfasst werden soll.
Alles sehr ordentlich, aber eben auch sehr unflexibel und teilweise performancehungrig bei großen und komplexen Webanwendungen wie Sozialen Netzwerken, die viele Datenbanktabellen nutzen und miteinander verbinden bzw. joinen musste, was eine hohe Rechenleistung verbraucht hat bei jedem Zugriff.
Das wurde jahrelang so gemacht und war quasi das dahinter liegende Paradigma: Erst definiere ich mein Datenbankschema, dann kann ich erst Daten darin ablegen. Heißt: Ich muss vorher wissen, was ich später alles brauche.

Aber Zack, haben Entwickler*innen einfach mit der Tradition der SQL-Datenbanken gebrochen und NoSQL (not SQL) Datenbanksysteme eingesetzt, die wohl schon seit den 1960er Jahren existierten, aber vorher nicht wirklich jemanden interessiert haben. Diese NoSQL-Datenbanken haben kein vorgefertigtes Schema, welches in der Datenbank angelegt werden muss. Das Schema wird viel mehr „frei“ in der Applikation selber definiert und dann einfach als ein „Dokument“ in der Datenbank abgelegt, ohne dass die Datenbank selbst etwas von der Struktur der Daten weiß. Die Verantwortung hierfür übernimmt komplett die Applikationslogik. Orientiert wird sich dabei oft am JSON-Format, das sieht dann ungefähr so aus:

Screenshot von JSON-Quelltext (Github Gist), Link ist in der Bildunterschrift für Textversion

Mögliche Struktur für einen Kurs in einer noSQL-Datenbank (Quelltext auf Github)

 

Somit können neue Spalten bzw. Felder einfach nachträglich bzw. flexibler angelegt werden in der Applikationslogik, wenn z.B. noch Kommentare angefügt werden sollen durch Benutzer*innen oder ein Lizenzfeld für den Kurs hinzugefügt werden soll.

Ein klassisches Beispiel für die Flexibilität ist das Hinterlegen von Kontaktdaten. Bei klassischen SQL-Datenbanken müsste man erst überlegen, welche Felder man hierfür braucht. Zum Beispiel Telefonnummer, E-Mailadresse, Twitter-Account? Was aber wenn jemand noch Snapchat hinterlegen möchte? Oder den nächsten neuen tollen Dienst? NoSQL macht es hier einfacher, diese flexiblen Daten abzuspeichern (geht aucht mit SQL, aber etwas umständlicher):

 

Neben dem Performancegewinn gibt es auch Nachteile wie eine geringere Verlässlichkeit, da die Datenbank keine Struktur hat, wonach sie die Daten kontrollieren kann. Es kommt letztendlich auf den Anwendungsfall an, wann eine NoSQL Datenbank Sinn macht – das Paradigma dahinter ist ungefähr: Daten können flexibler abgelegt werden und Applikationen können schneller angepasst werden. Es ist für Projekte von Vorteil, wo noch nicht klar absehbar ist, welchen Daten und Anforderungen in Zukunft relevant sind.

#noLMS wären also die flexiblere Alternative zu klassischen LMS.

Was macht ein #noLMS aus?

Ich gebe zu, dass das jetzt eventuell etwas weit hergeholt ist, aber für mich stellt sich die Frage, wodurch sich ein #noLMS auszeichnen könnte – inhatlich/didaktisch wie technisch.

Die These hierbei wäre, dass bei klassischen LMS sehr viel Wert auf Ordnung und Planung gelegt wird – alles wird im Vorab definiert und Features so umgesetzt, wie die Entwickler*innen hoffen, dass es eingesetzt wird oder wie die Auftraggeber*innen es sich erhoffen. Es ist ein striktes Top-Down-Prinzip und die Nutzer*innen müssen letztendlich damit leben, was Admins ihnen bereitstellen an der Hochschule. Es wird sozusagen nach einem Kompromiss für alle gesucht, der dann eben ein Kompromiss ist und nicht auf die individuellen Bedürfnisse zugeschnitten ist.
Wenn ein Feld fehlt, wie z.B. für einen Snapchat-Link, dann müssen alle warten, bis diese Änderung den Top-Down-Planungsprozess durchlaufen hat und die Admins das LMS aktualisiert haben.
Von Agilität ist in diesem Entwicklungsprozess keine Spur – für externe Entwickler*innen ist es zudem schwer kreative Lösungen beizusteuern, weil man sich erst komplett in das große LMS wie Moodle oder ILIAS reinfuchsen muss.

Hier einige Ideen für ein #noLMS als Alternative:

  • Der Upload von PDF-Folien ist nicht möglich – Inhalte müssen als HTML5 eingearbeitet werden. 😉 😉
  • Didaktisch: Kurse können flexibler erstellt werden, es gibt keine starr vorgegebene Struktur, wie ein Kurs aufgeteilt oder organisiert ist (mehrere Arten denkbar: pfadförmig, klassisch linear oder andere Formen?)
  • Vielfältige Kurstypen sind möglich, da die Applikationslogik auf die Kursebene wandert. Es gibt keine allgemeine Logik für Kurse, sondern es gibt Kurs-Typen, die die noSQL-Daten selbstständig in der Datenbank verwalten.
  • Die Kurslogik dieser Kurs-Typen wird über Javascript gesteuert und über Schnittstellen (APIs) wird mit dem Basissystem kommuniziert. (siehe unten)
  • Die Kurstypen sind importierbar und exportierbar vom Lehrenden und können vom Lehrenden weiterhin bearbeitet werden, falls er oder sie programmiertechnische Vorerfahrungen hat. Dies bietet einen Anreiz für externe Entwicklerinnen, neue Kurstypen zu entwickeln, ohne warten zu müssen, dass diese im gesamten großen LMS implementiert werden.
  • Kurs werden als eigenständige, losgelöste Einheit statt als fünfter Unterpunkt in der LMS-Menüführung, welcher einem globalen Design und der globalen Funktionsweise des Hauptssystems unterworfen ist, verstanden. Ankoppelung besteht nur zur Benutzerdatenbank und zu globalen, wichtigen Funktionen wie Notifications.
  • Erweiterungen bzw. Add-Ons sind leichter auf Kurs-Ebene implementierbar und können von Lehrenden aktiviert werden, da keine globale Datenbankstruktur angepasst werden muss sondern das Plugin die Daten einfach an das Kurs-Dokument in der noSQL Datenbank „anhängt“. Wird der Kurs gelöscht, verschwindet auch das eingesetzte Plugin wieder, weil es nie global installiert wurde.
  • Felder für Inputs/Rückmeldungen von Lernenden können flexibler festgelegt werden und gespeichert werden.
  • Kurse wären insgesamt leichter zu erweitern, auch für technisch-affine Lehrende, die einzelne Komponenten einfach anpassen könnten (hackability)
  • Die alleinige Macht der Admins über das LMS wird gebrochen.

Herausforderung I: Das Ganze ist natürlich nicht einfach mal von heute auf morgen umzusetzen, da natürlich auf Sicherheit der Benutzerdaten geachtet werden muss und einige technische Herausforderungen gelöst werden müssen.

Vorbild für meine Überlegungen aber war die Funktionsweise von h5p, bei welchem Content-Typen ganz einfach selbst programmiert werden können mit Hilfe von Javascript/JSON-Dateien und einem vorgefertigten Funktionsrahmen, auf den Programmierer*innen zugreifen können (h5p Tutorial „Hello World“). Auch hier können die Content-Typen mitsamt ihrer Logik exportiert und importiert werden durch Benutzer*innen (statt nur durch Admins). Das CMS wie WordPress oder Drupal stellt bei h5p nur die Grundfunktionen bereit. Im Rahmen der vorgegeben Funktion kann mit Javascript ziemlich kreativ gearbeitet werden an der Logik, ohne dass die PHP-Dateien des CMS bzw. von h5p angepasst werden müssen.
Kurz gesagt: Es ist also möglich, so etwas zu implementieren.

Herausforderung II: Es wäre ein großer Spaß, aber eben auch fehleranfälliger. Bugs würden evtl. öfter auftreten, wenn selbst am Kurs gehackt wird – dafür gewinnen aber Lehrende wieder die Freiheit über ihre Kurse, wenn sie an der Kurslogik herumschrauben könnten oder selbst kleine Plugins wie Kommentare, Abfragen oder interaktive Anwendungen aktivieren könnten.

Was meint ihr? Was könnte ein #noLMS ausmachen?

Weiterführende Links:

Creative Commons Lizenzvertrag Dieser Artikel (Text) ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz. Der Name der Urheber soll bei einer Weiterverwendung wie folgt genannt werden: Matthias Andrasch für studieren.digital. Urheberrechtliche Angaben zu Grafiken, Videos oder anderen verwendeten Inhalten finden sich direkt bei den jeweiligen Inhalten. Titelbild des Beitrags: Foto von Schueler-Design (Pixabay, CC0).

© 2018 Die Webwissenschaftler. Alle Rechte vorbehalten.

Thema von Anders Norén.