J. Waldmann, HTWK Leipzig
Schwerpunkt sind Darstellungen zu Technik und Werkzeugen, die auf eigener Erfahrung vom Einsatz in LV beruhen.
Ziel ist die aktuelle Information von Studenten und Kollegen, später evtl. eine etwas formalere Publikation auf einem E-Learning-Workshop.
Ich lade die Studenten dieser LV herzlich ein, den Text zu kommentieren (teilen Sie mir per Mail oder Issue Tracker Ihrer jeweiligen LV mit). Ich werde solche Kommentare gern in der LV diskutieren und auch ggf. hierher und in weitere Publikationen übernehmen, natürlich anonymisiert. Wenn Sie mehr zu diesem Text beitragen möchten, dann können Sie gern Ko-Autor werden.
Hier nicht oder nur sehr kurz betrachtet, obwohl wichtig: Recht, Didaktik, Datenschutz, IT-Sicherheit.
Kurzfassung Datenschutz: Die Hochschule muß immer alle Verarbeitungen von Studentendaten vollständig beherrschen, das heißt, selbst durchführen (Beispiele: BBB an ITSZ und an FIM) oder beauftragen (Beispiel: Bildungsportal Sachsen). Zoom, Youtube und ähnliche Anbieter, mit denen m.E. kein wirksamer Vertrag zur Auftragsverarbeitung nach EU-Recht geschlossen werden kann, sind unzulässig. “Freiwillige” Benutzung solcher Anbieter zur Lehre ist m.E. ebenfalls unzulässig, da der Student sich tatsächlich nicht frei entscheiden kann. (Klarstellung: “meines Erachtens” - mit meiner früheren Erfahrung als Datenschutzbeauftragter, aber hier nur als Dozent sprechend, der eine Lehrmeinung äußert.)
Dokumenten-Versionen:
Fernlehre: Studenten, Dozent an paarweise unterschiedlichen Orten (jeder einzeln bei sich zuhause oder im Büro).
synchrone Fernlehre: Echtzeit-Kommunikation zwischen Stundenten untereinander und Dozent durch Austausch flüchtiger Nachrichten über elektronische Medien (Text-Chat, Audio, Video)
asynchrone Fernlehre: zeitversetzte Kommunikation zwischen Studenten untereinander und mit Dozent durch Austausch längerlebiger Texte oder anderer Artefakte.
Nicht eingeordnet (und nicht Gegenstand dieses Textes): interaktive automatische Hausaufgaben (autotool), das ist asynchron (Arbeit allein, zu beliebiger Zeit), aber auch synchron (Bewertung erfolgt sofort).
In meinen Lehrveranstaltungen benutze ich
Hier nicht betrachtet: Projektarbeiten, Klausur.
Als Kamera habe ich https://de.jourist.com/gadgets/visualizer/jourist-dc80-dokumentenkamera/ ausprobiert.
Als elektronisches Eingabemedium für Strichzeichnungen kommen in Betracht
Zeichenfläche Wacom Intuous https://www.wacom.com/en-us/getting-started/intuos Vorteil: Preis, Nachteil: man sieht nicht auf den Stift, sondern auf den Bildschirm, man sieht den Zeichenpunkt erst kurz vor dem Aufsetzen des Stiftes
Tablet-PC mit Touch-Screen, Nachteil: Preis.
Big Blue Button (BBB) https://bigbluebutton.org/ ist ein Online-Konferenz-System. Es bietet u.a.
Bedienung komplett im Browser. Die für Inhalte nutzbare Bilschirmfläche besteht aus zwei Rechtecken (übereinander)
Das Größenverhältnis zwischen A und B kann verschoben werden. Jedes dieser beiden (A, B) kann maximiert werden, dann sind das andere under Chat unsichtbar.
Screen-Sharing und Präsentation belegen jeweils B exklusiv, sind also niemals gleichzeitig sichtbar.
Wenn man Beispiele elektronisch auf einem Tablet zeichnet und die Zeichenfläche (das Anwendungsfenster z.B. von https://github.com/xournalpp/xournalpp) durch Screen-Sharing übermittelt, sieht man die Präsentation (Skript mit Definitionen) nicht mehr.
Man kann “Beispiel an der Tafel, Definition auf Folie” nachbilden, wenn man die Entwicklung des Beispiels mit Stift auf Papier zeichnet und mit Dokumentenkamera filmt.
Man kann das Problem der starren Festlegung von A und B durch BBB ganz umgehen, indem man die gewünschte Ansicht mehrerer Element auf separater Software herstellt (siehe Abschnitt Streamen mit OBS) und dann als Screen-Share (in B) oder als virtuelle Kamera (in A) übermittelt.
soll für WebRTC wie eine Webcam erscheinen (also in BBB als A verwendbar) aber die Datenquelle ist softwarebestimmt. Das soll möglich sein mit v4l2sink https://stackoverflow.com/questions/43808560/webrtc-video-freezes-for-virtual-camera-provided-through-gstreamer-and-v4l2sink
Open Broadcaster Software (OBS) https://obsproject.com/ ist eine grafische Anwendung, um verschiedene Audio- und Video-Signalquellen (u.a. mehrere Anwendungsfenster) gleichzeitig abzumischen und anzuordnen.
Die eigentliche Ausgabe ist ein (Video-)Stream im RTMP-Format, der durch einen Streaming-Server publiziert werden kann.
Einen solchen Server haben wir derzeit nicht, ich habe es ausprobiert mit https://docs.nginx.com/nginx/admin-guide/dynamic-modules/rtmp/
Eingeschaften:
Eine Zugangsbeschränkung soll so möglich sein https://smartshitter.com/musings/2018/06/nginx-rtmp-streaming-with-slightly-improved-authentication/
Es scheint mir besser, den Stream über HTTP Live Streaming (HLS) auszuliefern, das sollte man dann leicht hinter Shibboleth setzen können.
TODO: Man kann OBS zu einem lokalen Server streamen und diesen dann als virtuelle Kamera in BBB einspeisen. Damit hat man den Rück-Kanal (u.a. Chat) und die Teilnahmebeschränkung (auf den BBB-Raum), verliert aber die Audio-Qualität. Das ist wohl akzeptabel außer bei speziellen Anlässen (wie LV und Verteidigung Computermusik)
Der Autor braucht dann dreimal Bildschirmplatz:
Man kan die OBS-Bedienfläche auch direkt als Screen-Share in BBB einspeisen:
Opal ist der von Bildungsportal Sachsen hergestellte Fork des Lern-Verwaltungssystems (LMS) Olat, dessen Instanz für die sächsischen Hochschulen zentral betrieben wird. Opal dient der Verwaltung der asynchronen Lehre. Studenten und Dozent können im System Texte austauschen (in Forum, Wiki, Ordner).
Gitlab ist ein Softwareprojektverwaltungssystem, das von Gitlab.Com entwickelt wird. F-IM betreibt eine lokale Instanz. Gitlab dient der Verwaltung, der Diskussion und dem automatisierten Test von (Quell)texten.
In meinen LV für Hauptfach Informatik benutze ich im laufenden Semester Gitlab.Imn zur Verwaltung der asynchronen Fernlehre.
Gitlab scheint deutlich besser geeignet zu Verwaltung von Projekten:
git pull alle aktuellen Artefakte, in Opal müßte man auf jedes einzeln clicken.)Das Berechtigungs-System von Opal ist detaillierter und deutlich besser angepaßt an typische Vorgänge in der Lehre:
Opal: Abgabe von Übungsaufgaben, die nur der Autor und der Dozent einsehen kann (aber nicht andere Studenten)
Opal: identifiziert und authentifiziert TN direkt über Shibboleth (IdP des ITSZ)
Opal: Beschränkung von Rechten jedes Kursbausteins auf Teilmengen (Arbeitsgruppen)?
Gitlab: jeder “Developer” darf in einem Projekt alles sehen und fast alles schreiben (außer push auf master).
Gitlab: genauer abgestufte Berechtigungen können wohl in der kostenpflichtigen Version vergeben werden
unsere Gitlab.Imn-Instanz: benutzt LDAP, keine direkte Beziehung zu den Shibboleth-Identitäten, deswegen ist es schwierig, die TN überhaupt dem Projekt zuzuordnen.
Da derzeit überhaupt keine Präsenz-Lehre möglich ist, argumentiere ich, daß die projektweite Sichtbarkeit der Dokumente in Gitlab die erwünschte Kooperation der TN der LV befördert, die sonst bei der gemeinsamen Bearbeitung von Hausaufgaben stattfindet. Ich sehe aber auch die Bedenken: es geht Studenten X nichts an, wann und wie Student Y seine Hausaufgaben macht, und den Dozenten auch nichts. Bewertet wird das zur Deadline vorliegende Dokument. Daß die Plattform die genaueren Daten aus technischen Gründen (Abwicklung des Datentransportes selbst) hat, bedeutet noch nicht, daß ihre Verarbeitung zu anderen Zwecken erlaubt ist.
Opal wird zentral betrieben (für die HS im Land Sachsen), Gitlab.Imn dezentral (an unserer Fakultät).
Für die zentrale Lösung spricht ein mglw. effizienterer Einsatz von Ressourcen (des Landes): BPS macht einmal Devops und IT-Sicherheit richtig, dafür hat er einzelne dezentrale Admin mglw. gar nicht die Ressourcen.
Für die dezentrale Lösung sprechen die dadurch entstehende Vielfalt der E-Lern-Landschaft (es können unterschiedliche Systeme ausprobiert und verglichen werden) sowie die lokal aufgebaute Kompetenz im Betrieb und ggf. Weiterentwicklung der Systeme, insbesondere an einer Fakultät für Informatik, wo E-Lerning auch Forschungsgegenstand ist.
Das Gegen-Argument ist: forschen könnt Ihr gern, aber nicht mit echten Studentendaten. Das Gegen-Argument dazu ist: nein, können wir nicht, oder nicht genug, wenn Mittel überwiegend für zentrale Systeme ausgegeben werden. Das Gegen-Argument dazu ist: es sind ja auch zentrale Mittel. Das Gegen-Argument dazu ist: ja, die vorher dezentral weggenommen wurden oder dort gar nicht erst ankommen.
Siehe https://www.opensourcelms.de/
Opal ist nicht open-source, deswegen erscheinen mir Investitionen öffentlicher Gelder darin fragwürdig. (Das zugrundeliegene Olat https://github.com/OpenOLAT/OpenOLAT ist open-source, mit Apache-Lizenz, deswegen ist BPS tatsächlich nicht verpflichtet, eigene Ergänzungen zu veröffentlichen.)
Gitlab hat eine Community Edition (CE) (mit offener MIT-Lizenz) sowie eine kostenpflichtige Enterprise Edition (EE). Gitlab.Imn betreibt die CE.
Gitlab.com möchte natürlich mit EE Geld verdienen. Die CE ist eine Werbemaßnahme (der CE-Benutzer, z.B. Student, soll später zum EE-Kunden werden) und ein Auslagern der Test-Arbeit (die CE-Benutzer schreiben Bugreports).
Entscheidend ist m.E., daß wir die Instanz der CE an der Fakultät selbst hosten. Damit fließen keine Daten nach außen ab.
(4. Nov. 2020: Die Konfiguration von gitlab.imn wurde geändert, Profilbilder von Dritten werden nicht mehr benutzt)
Die Überwachungswirtschaft will aber auch dort zugreifen. Beispiel: der (HTML) Code von Gitlab (CE) sieht Profilbilder von gravatar.com vor.
Das ermöglicht eine Benutzerverfolgung und dient der Herstellung und Verbesserung von Personenprofilen zum zielgenaueren Verkauf von Werbeflächen (nicht in Gitlab CE, aber dort, wo der Benutzer wiedererkannt wird oder jemand aus seinem “sozialen” Netz)
Die Studenten sind zu belehren, das z.B. durch umatrix zu unterbinden. Der Server benutzt zudem lokales Caching dieser Bilder oder ganz lokale Bilder, was die Datenverarbeitung verringert.
Aber selbst wenn - ich verweise darauf, daß es in Opal auf Anraten des Sächsischen Datenschutzbeauftragten überhaupt keine Benutzerbilder gibt - weder echte Fotos noch Grafiken.
Der Grund ist: das wäre eine zusätzliche Verarbeitung, die für den bestimmungsgemäßen Zweck (Hochschullehre) überhaupt nicht erforderlich ist - und somit untersagt. (Das ware jedenfalls die Lage bis vor EU-DSGVO, evtl. wurden inzwischen durch den Gesetzgeber Hintertüren geöffnet, mit dem Ziel der Förderung der europäischen Überwachungswirtschaft.)