Plugin-Test: Ankündigungen für Veranstaltungen mit vorläufiger Anmeldung (PreliminaryParticipantsNewsPlugin)

Vorläufige Anmeldungen für Veranstaltungen wurden in Stud.IP eingeführt, um Plätze in Veranstaltungen zu verteilen, die endgültige Zulassung zur Veranstaltung aber noch offen zu lassen. Ein Anwendungsfall in Osnabrück sind die Sprachkurse: Bis zu 20 Plätze sollen über Stud.IP vergeben werden, um tatsächlich teilnehmen zu dürfen, muss aber noch der Teilnahmebeitrag bezahlt werden.

Vorläufig Angemeldete belegen einen Platz im Anmeldekontingent, haben aber noch keinen Zugriff auf die Veranstaltung und deren Inhalte. Das war damals einfach zu implementieren und hat sich auch grundsätzlich bewährt.

Aber… Häufig möchte man auch den vorläufig Angemeldeten schon bestimmte Informationen zukommen lassen, zum Beispiel in Form der für diesen Zweck beliebten Stud.IP-Ankündigungen (in der in Stud.IP verbotenen Internet-Fachsprache auch ‚News‘ genannt). Die Ankündigungen können die Vorläufigen aber nicht sehen.

Genau an dieser Stelle setzt das PreliminaryParticipantsNewsPlugin von André Noack an. Es rüstet an zwei Stellen die Anzeige der Veranstaltungsnews nach:

In der Übersichtsliste „Meine Veranstaltungen“, wo ein News-Icon auf Klick die Veranstaltungsnews in einem Pop-Up-Dialog direkt auf der Seite anzeigt.

Auf der öffentlichen Detailseite der Veranstaltung werden nun für vorläufig Angemeldete die Veranstaltungsnews mit eingeblendet.

Das ganze funktioniert mit Stud.IP 3.1 komplett schmerz- und nebenwirkungsfrei. Einfach das Plugin installieren, aktivieren und die Funktionalität ist da. Es muss und kann nichts konfiguriert werden, da immer und einfach alle News den vorläufig Angemeldeten zugänglich gemacht werden.

Kurzbewertung PreliminaryParticipantsNewsPlugin

Getestete VersionVersion 5 mit Stud.IP 3.1 (PreliminaryParticipantsNewsPlugin im Stud.IP-Plugin-Marktplatz)
FazitUniversalnützliches EssentialBraucht jede Installation, die vorläufige Anmeldeverfahren einsetzt.
Installation und Konfiguration5 Stars (5 / 5)Einfacher geht's nicht.
Rundheit und Bedienung4 Stars (4 / 5)Das Plugin macht das beste aus der Situation, es wirkt aber letztendlich immer noch ein bisschen drangeklebt.
Generizität5 Stars (5 / 5)Funktioniert mit allen vorläufigen Anmeldeverfahren
Technik4 Stars (4 / 5)Kein Trails, PHP und Javascript in einer Datei, aber das alles so kompakt und übersichtlich, dass es nicht stört.

Stud.IP, Dokumentmanagement und Dokumentenrepositories

Wie schon beklagt, lahmt der Stud.IP-Dateibereich infolge von Altersschwäche und Renovierungsstau heftig. Ideen und Konzeptteile, wie eine Verbesserung aussehen könnte, existieren bereits, werden aber häufig übersehen. Daher hier einfach nochmal meine inzwischen vier Jahre alten Ansätze zur Erweiterung des Dateibereichs um zusätzliche Quellen:

Download: StudIP-DMS-2.0.0 (1 MByte, RTF)

Adieu, Verona (nur echt mit Doppelpunkt)

:verona, das Zusatzqualifikationsprogramm für Studierende aller Fächer an der Universität Osnabrück, gibt es schon einige Jahre nicht mehr. Zusatzqualifikationen, Soft Skills und so weiter sind jetzt fest in vielen Studienprogrammen verankert und brauchen keine freiwilligen Zusatzangebote mehr.

Ende letzter Woche haben wir :veronas letzte Spuren auch im Stud.IP der Uni Osnabrück gelöscht. Schade, denn die Unterstützung dieses Programms hat immer sehr schön gezeigt, wie flexibel und vielseitig Stud.IP in der Lehre genutzt werden kann. Anstelle eines trauernden Nachrufs hier einfach nochmal kurz die Fakten:

:verona wurde in Stud.IP als Studiengang abgebildet und die Selbstzuordnung deaktiviert. Eigentlich haben wir das Feature, das vor allem bei Zugangsbeschränkungen von Veranstaltungen eine Rolle spielt, gar nicht genutzt, denn die regulären Studiengangsinformationen standen in der Regel am Semesteranfang, wenn die Veranstaltungsanmeldungen laufen, noch nicht mit hinreichender Sicherheit fest. Die Studierenden wurden auf Zuruf manuell dem Studiengang zugeordnet. Bei maximal 100 Teilnehmenden insgesamt war das kein großes Problem.

Es gab spezielle :verona-Veranstaltungen und für :verona geöffnete reguläre Lehrveranstaltungen. Beides konnte durch Kontingentierung von Anmeldeverfahren abgebildet werden. So konnte sichergestellt werden, dass sich nur zugeordnete Studierende in spezielle Veranstaltungen eintragen konnten und darüber hinaus die zugesagten Kontingente nicht überschritten wurden.

Für Zusatzauswertungen wie Auslastung der Kontingente, personenbezogene Belegungslisten usw. für die :verona-Administratorin haben wir mit geringem Aufwand ein separates Tools entwickelt, das auf die Stud.IP-Datenbank zugreift. Damals gab es noch keine Plugins, heute würde das natürlich ein kleines Plugin erledigen.

Für den Erfolg von Stud.IP an der Uni Osnabrück war die Unterstützung des :verona-Programms sehr wichtig, denn an diesem Beispiel konnte das Tool zeigen, dass es auch zu exotischeren Anforderungen gut passen kann und eine echte Arbeitserleichterung darstellt.

 

Weshalb chronologische Anmeldeverfahren mit Stud.IP gar nicht funktionieren können

Die Behauptung, man könne die Last-Probleme bei gleichzeitig startenden Anmeldeverfahren nicht technisch lösen, sorgt regelmäßig für Verwunderung. Wenn ein Server (oder zwei oder drei oder vier) es nicht schaffen, den Ansturm der Anmeldewilligen auszuhalten, weshalb nimmt man dann nicht einfach zwei (oder vier oder acht oder sechzehn)?

Problem 1: Flaschenhals Datenbank. Bei den Anmeldeverfahren geht es ja darum, eine begrenzte Menge Plätze der Reihe nach auf anmeldewillige Personen zu verteilen. Auch wenn es ein Dutzend Server gibt, die diese Anfragen abarbeiten, muss es genau eine Stelle geben, an der die derzeit gültige Anmeldeliste verwaltet wird. Diese Stelle ist eine so genannte Datenbanktabelle, die auch genau einem Datenbankserver liegt und nicht verfielfacht werden kann. Alle Anmeldungen müssen also auf diese eine Tabelle zugreifen.

Problem 2: Ungeeignete Datenbank. In den 60er und 70er Jahren hat die Informatik-Forschung sich intensiv mit der Frage beschäftigt, wie große Datenmengen effizient gespeichert werden können. Als besonders erfolgreich haben sich die Relationen Datenbankmodelle herausgestellt, bei denen Daten in zweidimensionalen Tabellen gespeichert werden, die Querverweise enthalten und miteinander verknüpft werden können. Problem dabei: Aktionen müssen dabei häufig auf mehrere Datenbankoperationen verteilt werden, die nicht getrennt werden dürfen. Zum Beispiel: Wenn 100 Euro von Konto A auf Konto B überwiesen werden sollen, müssen von Konto A 100 Euro abgezogen und bei Konto B 100 Euro hinzugerechnet werden. Wenn das Programm nach der ersten Operation abbricht, befindet sich die Datenbank in einem fehlerhaften Zustand.

Um das zu verhinden, werden so genannte Transaktionen verwendet, die mehrere Operationen untrennbar zusammenfassen. In der Stud.IP-Datenbank gibt es keine Transaktionen. Das sorgt dafür, dass die Datenbank einfacher ist, bei Leseoperationen schneller ist und etwas einfacher zu programmieren ist. Das heißt aber auch, dass solche Dinge wie Banküberweisungen mit dem verwendeten Datenbanksystem besser nicht abgebildet werden sollten. Oder solche Dinge wie Kursanmeldungen nach dem Windhundverfahren.

Dabei tritt nämlich das paradoxe Problem auf, dass es um so mehr Überbuchungen gibt, je mehr Server für die Anmeldung bereitgestellt werden. Eine Kursanmeldung läuft nämlich so ab:

  1. Nutzer ruft Kursseite auf, eine Datenbankabfrage (1) liefert die Information, wie viele Plätze noch frei sind.
  2. Nutzer klickt auf Anmelden, Server nimmt Anfrage entgegen und eine Datenbankabfrage (2) ermittelt erneut, ob es noch freie Plätze gibt (seit Datenbankabfrage (1) können mehrere Sekunden oder gar Minuten vergangen sein).
  3. Wenn ja, wird in einer separaten Datenbankoperation (3) der Nutzer eingetragen.

Die Datenbankabfragen (2) und (3) passieren im Stud.IP-Code ziemlich direkt hinereinander. Trotzdem kann zwischendurch allerlei passieren. Der Datenbankserver muss nämlich alle Eintrage-Operationen in eine Warteschlange stellen, weil für alle Veranstaltungen insgesamt immer nur eine Eintrage-Operation gleichzeitig passieren kann („table lock“). Die Abfrage, ob noch Plätze frei sind, kann diese Warteschlange aber nicht mitberücksichtigen.

Daher kommt es bei überlaufenen gleichzeitigen Anmeldeverfahren fast zwangsläufig zu Überbuchungen der Veranstaltungen. Genau das möchte man aber in der Regel nicht. Das Problem lässt sich – in Stud.IP und seiner dafür ungeeigneten Datenbank – nur durch Verwendung geeigneter Verfahren lösen: Einem Losverfahren, bei dem zunächst alle Anmeldewünsche gesammelt werden. Nach Ablauf dieser Sammelphase, sei sie 2 Stunden oder Tage oder Wochen lang, wird automatisch gelost, wer einen Platz bekommt und wer auf welchem Platz der Warteliste landet.

Windhunde aller Länder, trollt Euch

Erster März, acht Uhr in Osnabrück: Seit Jahren bietet sich immer wieder das gleiche Bild, an diesem Tag genau wie sechs Monate später am ersten September. Junge Menschen klicken gähnend gelangweilt, routiniert rasend und fürchterlich frustriert auf ihre Maustasten, hastig zwischen einem guten Dutzend geöffneter Browserfenster wechselnd. Weshalb? Sie wollen Plätze in Lehramtsveranstaltungen ergattern und quälen ein vom Ansturm überfordertes Stud.IP-System mit einer Flut von Requests.

Der spezielle Witz an dieser Variante: Die Anmeldungen sind größtenteils sinnlos und überflüssig. Da die Studis zu diesem Zeitpunkt ihren Stundenplan noch nicht kennen und die Veranstaltungen, um die es geht für viele hinter den Hauptfachveranstaltungen zurückstehen, melden sich alle für alles an. Wenn die Veranstaltung dann irgendwann beginnt, kommen von den 40, die einen Platz haben, nur 10 und außerdem 50 andere, die vielleicht irgendwo auf der Warteliste stehen.  Eigentlich ist also jedem klar: Anmelden ist egal. Aber weil’s alle machen, muss es doch irgendwie wichtig sein.

Das technische Überlastungs-Problem hat zwei Ursachen: Zum einen möchte und kann die Uni Osnabrück ihre Serverlandschaft nicht deutlich ausbauen, um genau diese beiden sehr sepziellen Lastspitzen abzufangen. Zum anderen ist das so genannte Windhundverfahren schuld – wer zuerst kommt mahlt zuerst. Und so gibt es Seminare, deren 40 Plätze schon um 8:02 Uhr deutlich überbucht sind, auch wenn viele Interessierten Ihren Eintragungswunsch dem lahmenden Server noch gar nicht übermitteln konnten.

Mit diesem Problemen steht die Uni Osnabrück nicht alleine da und deshalb gibt es seit der Version 3.0 die neuen Passauer Anmeldesets, die deutlich flexiblere und interessantere Optionen für Losverfahren, Prioritätswahlen etc. bietet. Heute nachmittag starten wir den erneuten Versuch, für das Osnabrück Problem eine organisatorische Lösung zu finden, die alle Seiten zufriedenstellen kann.

Am 1. März 2015, diesmal sinnvollerweise ein Sonntag, wird allerdings alles noch beim Alten bleiben: Lahmende Seiten, frustrierte Studierende und am Ende renkt sich alles doch irgendwie wieder ein.

Aufgaben, Lösungen und Bewertungen in Stud.IP

Es gibt sie beinahe wie Sand am Meer: Tools, mit denen sich in Stud.IP Aufgaben stellen oder Fragen beantworten lassen. Ohne den Anspruch auf Vollständigkeit seien hier genannt:

Umfragen und Tests – Mit diesem Kernfeature lassen sich in Veranstaltungen, auf der persönlichen Profilseite und auf der Startseite für alle Nutzer sichtbar kleine Umfragen oder Tests platzieren. Klein heißt: Nur eine Frage und nur Multiple-Choice. Die Tests werden kaum benutzt, die Umfragen – entweder anonym oder nicht – sind aber eine außerordentlich praktische Sache: Welchen Ausweichtermin sollen wir nehmen? Wann soll die Kursparty stattfinden? Wer ist für welches Spezialisierungsthema in der Vorlesung?

Evaluationen und Fragebögen – Die großen Brüder der Umfragen, auch ein Kernfeature, das ursprünglich gedacht war, offizielle Lehrveranstaltungsevaluationen über Stud.IP durchführen zu können. Dazu wird das Feature meines Wissens an keiner größeren Hochschule genutzt, ein mächtiges Fragebogentool bleiben die Evaluationen aber trotzdem.

Vips – Das »virtuelle Prüfungssystem«, das auf eine fünfzehnfährige Geschichte zurückblicken kann und seit langem als Stud.IP-Plugin an der Uni Osnabrück entwickelt wird. Mit Vips lassen sich Multiple-Choice-Fragen, Lückentexte, Zuordnungsaufgaben, kleine und große Freitextaufgaben und einige exotische Sonderformen wie Prolog-Programmieraufgaben erstellen und zu Übungsblättern, Online-Klausuren oder Selbsttests zusammenschnüren. Daraus lassen sich dann auch Noten berechnen, Punktelisten exportieren usw.

Cliqr – Ein softwarebasiertes Audience-Response-System als Stud.IP-Plugin, mit dem sich im Hörsaal, Seminar- und Klassenraum kurze Befragungen durchführen lassen. Stud.IP generiert dazu eine Kurz-URL und einen QR-Code für die Umfrage, die per Smartphone, Tablet oder Laptop ohne Login schnell aufgerufen werden kann. In einem späteren Beitrag mehr zu diesem spannenden Tool, das ich in meiner Vorlesung Web-Technologien im nächsten Semester auch wieder einsetze.

Elmo – Das kleine E-Learning-Modul, ein Stud.IP-Plugin, dessen Name suggeriert, als gäbe es ansonsten in Stud.IP keine E-Learning-Tools. Elmo hat auch schon eine lange Tradition und sollte damals eine Lücke schließen: Thematisch gegliederte Freitextaufgaben, die eine Lehrveranstaltung begleiten. Grundsätzlich ist das auch mit Vips möglich, Elmo legt den Fokus aber stärker auf die Aufgabentexte, textuelles Feedback und enthält keine Noten-Bewertungen oder ähnliches. An der Uni Bremen wird außerdem eine Elmo-Ableger namens DoIT entwickelt.

Die Osnabrücker Aufgaben- und ePortfolio-Plugins, die aufeinander aufbauen und ähnlich wie Elmo Freitextaufgaben mit Feedback ermöglichen. Sei werden derzeit in einem Pilotprojekt für Kompetenzentwicklungsportfolios in den Lehramtsstudiengängen eingesetzt.

Die E-Learning-Schnittstelle, eine im Stud.IP-Kern enthaltene Möglichkeit, externe Tools wie ILIAS, PmWiki oder LON-Capa anzubinden. In diesen Tools lassen sich Aufgaben stellen und bearbeiten – die Anbindung ist aber sehr schmal: Es ist kein erneutes Login nötig und einige Angaben werden übergeben, einen Rückkanal gibt es aber nicht.

Mit dem SCORM-Plugin lassen sich fertige Lernmodule in Stud.IP einbinden, die auch Aufgaben und Tests enthalten können.

(M)OOC.IP, das Plugin für MOOC-artige Kurse für Stud.IP kann Aufgaben und Tests bereitstellen, die wie bei SCORM-Modulen und den derzeit so verbreiteten wie beliebten xMOOCs in den Inhalt eingebettet werden. Testerstellung und -auswertung werden dabei von Vips übernommen.

Der Hausaufgabenordner ist eine Möglichkeit, einzelne Ordner im Dateibereich einer Veranstaltung so zu konfigurieren, dass sie wie ein Briefkasten funktionieren: Studierende können dort Dateien hochladen, aber nicht sehen oder herunterladen. Bestens geeignet für die Abgabe von Seminararbeiten, Hausaufgaben und ähnlichem.

Das FSZ-Notenverwaltungs-Plugin stellt selbst keine Aufgaben, sondern nur eine manuelle Notenverwaltung bereit, die allerdings recht detailliert auf die Belange des Sprachenzentrum des Uni Hannover zugeschnitten ist.

Wie gesagt: Beinah wie Sand am Meer. Grundsätzlich gilt: Vielfalt ist etwas Positives, Konkurrenz belebt das Geschäft und wenn informierte Lehrende aus verschiedenen Möglichkeiten das für sie und ihre Studierenden Geeigneteste heraussuchen können, haben alle Seiten gewonnen. Anders sieht es allerdings aus, wenn Dinge doppelt entwickelt werden, Weiterentwicklungen unmöglich sind und stattdessen das Rad immer wieder neu erfunden wird.

Fragt man sich aus technischer Sicht, was all die verschiedenen Aufgabe- und Fragentools miteinander zu tun haben, so ist die Antwort:  Nichts. Es gibt keinerlei gemeinsame technische Basis und daher sind Neu- und Doppelentwicklungen an der Tagesordnung. Da wir im eCult-Projekt den Komplex der Aufgaben etwas systematischer angehen wollen, ist die technische Idee einfach:

Daten wie Aufgaben, Lösungen und Bewertungen sollten in technisch einheitlicher Weise in Stud.IP abgelegt werden können, damit verschiedene Tools darauf aufbauen können.

Wenn es im Stud.IP-Kern solche Datenstrukturen gäbe, ließen sich viele nützliche Funktionen umsetzen: Aufgaben, die mit einem Tool erstellt wurden, können in einem anderen weiterverwendet werden und nicht jedes Tool muss Funktionen mitbringen, mit denen Aufgaben erstellt werden können. Es könnte gemeinsame Import- und Exportfunktionen geben sowie Fragenpools aufgebaut werden, die vielfältig Verwendung finden können. Studierende können eine Übersicht aller anstehenden Aufgaben abrufen, auch wenn sie an verschiedener Stelle und mit verschiedenen Tools eingereicht werden müssen.

Ganz so einfach, wie es klingt, ist es freilich nicht: Ein gemeinsames Aufgabenformat kann nicht alle Spezialitäten und Besonderheiten abdecken, die nötig sind. Daher ist die Einigung auf gemeinesame Datenstrukturen eine komplizierte Aufgabe.

Diese Aufgabe gehen wir jetzt an: Heute haben sich ein halbes Dutzend Aufgaben-Tool-Entwickler in Osnabrück getroffen, um sich darüber zu verständigen, welche Vereinheitlichungen möglich sind und welche Schritte Stud.IP und möglichst viele der vorhandenen Tools dorthin führen können.

 

Vergabe von Prüfungsterminen im Wiki

Ende der Woche stehen mündliche Prüfungen für mein Modul »E-Learning« an. Die Termine für die Prüfungen darf ich mit den direkt Prüflingen aushandlen und der einfachste Weg dazu, ist eine kleine Wiki-Seite in meiner Stud.IP-Veranstaltung, auf der die Termine nach dem Windhund-Prinzip vergeben werden.

Im Wiki wird eine einfache Tabelle angelegt: Pro verfügbarem Zeitslot eine Zeile und insgesamt zwei Spalten: Zeitpunkt und Prüfling. Da im Wiki jeder nach Herzenslust editieren kann, können sich ab sofort die Prüflingsteilnehmer in einen freien Slot eintragen.

Screenshot: Prüfungsterminvergabe im Wiki
Wiki-Seite mit der Prüfungstermintabelle

Zugegeben, Sie könnten sich auch in einen nicht-freien Slot eintragen und jemand anders rauswerfen oder auf einen anderen Termin verschieben. Dank Wiki-Versionierung bliebe so eine Aktion aber nicht unsichtbar, so dass auch hier das alte Prinzip gilt: Destruktives Verhalten kommt praktisch nicht vor, wenn die Aktionen für alle sichtbar und mit dem echten eigenen Namen verknüpft sind.

Da im Wiki keine gleichzeitige Bearbeitung von Seiten möglich ist, funktioniert das Verfahren nur, wenn nicht mehrere Personen gleichzeitig versuchen, sich einzutragen, d.h. auf besonders begehrte Zeiten großer Andrang herrscht. Im meinem Fall gibt es nur wenige Prüfungsteilnehmer, so dass das Verfahren reibungslos funktioniert hat.

Ach ja, wie legt man im Wiki eine Tabelle an? In Stud.IP-Versionen, die noch keinen Wysiwyg-Editor nutzen, geht das relativ einfach mit dem Tabellen-Markup, d.h. senkrechten Strichen:

|Uhrzeit  |Prüfling |
|13.00-13.30 | noch frei |
|13.30-14.00 | noch frei |