Das Experimentierfeld der HOOU bietet den beteiligten Hochschulen die Möglichkeit, Erfahrungen und Erkenntnisse in den Bereichen der Mediendidaktik und Hochschulentwicklung zu sammeln und Neues auszuprobieren (vgl. Schwalbe, Peters, Ladwig, Jackewitz, Göcks & Knutzen, 2017, in diesem Blog). An der TUHH haben wir in diesem Sinne ein technisches System entwickelt, das für die Konzeption, Entwicklung und Weiternutzung von Open Educational Resources (OER) im Rahmen der HOOU sinnvoll und begründet erscheint (vgl. Dürkop, 2016, in diesem Blog). Im folgenden Artikel wollen wir unsere Erfahrungen und Ergebnisse teilen und reflektieren. Dazu werden wir die beteiligten technischen Komponenten vorstellen und erläutern, wie wir sie im Zusammenspiel einsetzen und in unsere Arbeitsabläufe integrieren. Abschließend werden einige Ergebnisse aus dem Vorprojekt vorgestellt, die mit dem System entstanden sind. Die Reflexion unserer Erkenntnisse und Erfahrungen sowie ein Ausblick auf den Fortgang der Entwicklung beschließen den Beitrag.

Inhalt

• GitLab: Zentrale Kollaborationsplattform
• GitBook und andere Static-Site-Generatoren
• Technisches Ermöglichen von Partizipation
• Docker: schnelle und experimentierfreudige Entwicklung
• Qualitätssicherung in der OER-Entwicklung
• Projektkommunikation mit Mattermost
• Das beschriebene System im Experimentierfeld an der TUHH
• Ergebnisse aus dem beschriebenen System
• Reflexion und Ausblick

GitLab: Zentrale Kollaborationsplattform

Mit engagierter Unterstützung des Rechenzentrums der TUHH hosten wir seit 2016 eine Instanz der freien Software GitLab, die weltöffentlich ist und allen Interessierten zur Verfügung steht. Dabei war uns wichtig, die Registrierung auf der Plattform unabhängig von der Hochschulzugehörigkeit zu ermöglichen, um offene und institutionsübergreifende Lehr- und Forschungsgemeinschaften aufbauen zu können. GitLab kommt an der TUHH in Lehre und Forschung sowie in verschiedenen OER-Projekten zum Einsatz. Die Arbeitsumgebung wird an der TUHH von einer wachsenden Zahl Lehrender und Forschender eingesetzt, die den sicheren Rechtsrahmen der Hochschule sowie die Gestaltungs- und Kontrollmöglichkeiten der freien Softwarelösung proprietären Diensten wie bspw. GitHub vorziehen.

Rechtliche Rahmenbedingungen

Das Aufsetzen von GitLab an der TUHH erforderte die Aushandlung diverser, insbesondere datenschutzrechtlicher Rahmenbedingungen. Dies begründet sich besonders auf der Tatsache, dass die GitLab-Instanz der TUHH nicht nur Hochschulangehörigen zugänglich gemacht wurde. Vor dem Launch der GitLab-Instanz fanden zahlreiche Aushandlungsprozesse zu Verfahrensbeschreibung und Risikoanalyse, aber auch zu Datenschutz und Nutzungsbedingungen statt. An diesen Prozessen waren Mitarbeiter_innen des Rechenzentrums der TUHH, juristische Vertreter_innen und wir beteiligt. Die hieraus entstandenen Dokumente wurden in weiteren Feedbackschleifen mit dem Datenschutzbeauftragten diskutiert und angepasst, bevor die GitLab-Instanz am 17. November 2016 weltöffentlich zugänglich gemacht wurde.

Offener Zugang und hochschulübergreifende Kollaborationsmöglichkeiten in GitLab an der TUHH

Dass GitLab seine Stärken in der Verwaltung von Quellcode hat und angetreten ist, eine ganzheitliche Produktionsumgebung für Software zu sein, belegen die zahlreichen Industrievertreter und Communitys, die es in diesem Sinne einsetzen. Wir wollten herausfinden, was es für die Entwicklung von Artefakten leistet, die nicht vornehmlich aus Quellcode entstehen, sondern aus Text und weiteren digitalen Medien. Dafür haben wir uns zunächst den Potenzialen von Static-Site-Generatoren zugewendet, die wir zusammen mit GitLab zu einem generellen Produktionsworkflow vereint haben.

GitBook und andere Static-Site-Generatoren

Wie an anderer Stelle beschrieben, sind Static-Site-Generatoren hinsichtlich technischer und konzeptioneller Anforderungen an OER geeignet, einen Kreislauf von Produktion, Distribution, Weiterverwendung und Weiterentwicklung zu ermöglichen. Die Quelltexte und Rohmaterialien liegen zur einfachen Weiterverwendung und -entwicklung vor und können mit freier und quelloffener Software verhältnismäßig leicht verarbeitet werden.

Wir haben uns an der TUHH entschieden, den Static-Site-Generator “GitBook” genauer auf sein Potenzial zu untersuchen und für die Produktion von OER-Material in der HOOU und am ITBH zu verwenden. Dabei haben wir uns von Anfang an den Möglichkeiten der freien Software “GitBook” orientiert und auf die Benutzung des Services GitBook.com verzichtet, um größtmögliche Freiheiten bei der Umsetzung des vorgeschlagenen Systems zu haben.

Die Software GitBook ist ein vergleichsweise einfach zu handhabender Static-Site-Generator, der aus beliebig vielen Markdown-Dateien ansprechende HTML-Konstrukte PDF- und ePub-Dokumente erzeugt. Durch seine Offenheit kann die Ausgabe beliebig in Layout und Gestaltung angepasst werden, was wir u.a. im HOOU-Projekt “Hop-on – Wege zum Berufsabschluss” (s. auch Ergebnisse) ausgenutzt und ausgereizt haben.¹

GitBook und GitLab zusammen erlauben auf verschiedene Weise die Zusammenarbeit an OER-Projekten. Durch die Funktionen von GitLab ist darüber hinaus auch eine Form der Partizipation gegeben, die echte Teilhabe an allen Bestandteilen eines Projekts bedeutet.

Technisches Ermöglichen von Partizipation

Die Quelldateien der GitBooks, die wir in den vergangenen Monaten als Open Educational Resources erarbeitet haben, verwalten und teilen wir in der GitLab-Instanz an der TUHH. Die Mitarbeit und Weiternutzung im Sinne von Wileys 5R ist dabei auf unterschiedliche Weise technisch möglich:

Klonen und Forken

Wie auch von GitHub bekannt, kann der Quelltext der Projekte für eigene Zwecke geklont werden, denn die entstandenen Materialien stehen alle unter Creative-Commons-Lizenzen, die dies erlauben. Mit einer Registrierung im GitLab der TUHH können die Quelltexte auch geforkt, also in den eigenen Account kopiert werden (vgl. Screenshot).

Öffentliche Repositorien mit OER-Quelldaten können in GitLab geklont und geforkt werden.

Mitarbeiten im Projekt

Externe Interessierte können über den Button Request Access ihr Interesse an der Mitarbeit signalisieren und ggf. in das Projektteam aufgenommen werden (vgl. Screenshot).

Über einen Button auf der Startseite eines Projekts kann die Mitarbeit angeboten werden.

Vorherige Verabredung auf Zusammenarbeit

Am einfachsten und sinnvollsten ist sicherlich eine vorhergehende Verabredung zur Zusammenarbeit an einem OER-Projekt, die in der Regel über Kommunikationswege außerhalb von GitLab erfolgt.

Um die Autor_innen und Domänenexpert_innen nicht mit zuviel Technik zu verschrecken, die sie für alle diese Potenziale auf ihren Rechnern installieren und benutzen müssten, haben wir an der TUHH einen Workflow entwickelt, der einen einfacheren Einstieg ermöglicht. Zum besseren Verständnis des gesamten Systems, das dabei zum Einsatz kommt, muss zunächst noch eine weitere technische Komponente vorgestellt werden.

Docker: schnelle und experimentierfreudige Entwicklung

Docker ist eine freie Software für die schlanke Virtualisierung von Systemen und Diensten. In der Welt von Docker dienen beschreibende Skripte als Bauanleitungen für virtuelle Maschinen (images). Von diesen Abbildern können beliebig viele identische Container gestartet werden, in denen Anwendungen und Dienste laufen. So können bspw. alle Softwarekomponenten, die für einen Static-Site-Generator notwendig sind, in einem Docker-Image reproduzierbar untergebracht werden.

An der TUHH nutzen wir Docker mittlerweile in verschiedenen Zusammenhängen, weil es uns eine hohe Geschwindigkeit im Entwickeln und Experimentieren ermöglicht, auch beim Ausprobieren von Tools für Lehrlernzusammenhänge. In Kombination mit dem zuvor beschriebenen System von GitLab und GitBook ermöglicht uns Docker, schnell und unkompliziert die Generierungsprozesse der Static-Site-Generatoren serverseitig abzulaufen zu lassen und die Ergebnisse im Netz bereitzustellen. Der entsprechende Ablauf kann in Kürze wie folgt beschrieben werden:

1. Autor_innen ergänzen/verändern Inhalte in GitLab.
2. Ein dem Projekt zugeordneter GitLab-Runner reagiert auf die Veränderung und zieht sich den aktuellen Stand des Repositoriums aus GitLab (die Markdown-Dateien).
3. Auf Basis eines Docker-Images wird ein neuer Docker-Container gestartet, in dem alle Softwarekomponenten für die Generierung bspw. eines GitBooks enthalten sind, und startet ihn.
4. Das GitBook-HTML-Konstrukt sowie das GitBook-PDF werden erzeugt.
5. Die entstandenen Artefakte werden auf einen Webserver geschoben, der Container wird gelöscht.
6. Der Vorgang dauert ca. 30 Sekunden und kann anschließend von vorne begonnen werden.

GitLab als Content-Management-System

Durch die Verlagerung der fortlaufenden Generierung von Artefakten auf die Seite des Servers können auch Domänenexpert_innen und Autor_innen ohne viel “Kommandozeilenerfahrung” in der Logik von Git und GitLab mitarbeiten (vgl. dazu Dürkop, 2016, in diesem Blog). GitLab wird zu einem Content-Management-System, das einige Kenntnisse von Markdown als Auszeichnungssprache sowie das Erlernen bestimmter Workflows im Browser erfordert. Die initiale Struktur für die Static-Site-Generatoren, die wir verwenden, wird momentan noch von denjenigen angelegt, die sich am besten mit dem entwickelten System auskennen. In peer-to-peer-Lernrunden geben wir das Wissen und die Erfahrungen zu dem System momentan wöchentlich weiter, sodass Teammitglieder selbstständiger arbeiten können und in der Lage sind, auch komplexere Workflows zu verfolgen.

Ansicht eines Markdown-Dokuments im GitLab-Editor. Hier wären noch Formatierungsbuttons wünschenswert, die Einsteiger_innen das Lernen von Markdown erleichtern könnten.

Eine gewisse Lernkurve des Systems ergibt sich aus den Abläufen der Kollaboration, die im Zusammenhang mit Git und GitLab unvermeidbar ist. Jedoch haben wir in der Zusammenarbeit festgestellt, dass diese auch für “Nichtinformatiker_innen” keine unüberwindbare Hürde darstellt.

Qualitätssicherung in der OER-Entwicklung

Die vorgestellten Komponenten bieten hinsichtlich der Abstimmung und Qualitätssicherung einige Möglichkeiten, die im folgenden kurz vorgestellt werden sollen.

Diskussionen über Merge Requests

Ein wesentlicher Vorteil der Kollaboration an Softwarequellcode auf Plattformen wie GitHub und GitLab ist der Mechanismus des Code Reviews. Dabei wird mehr oder weniger streng eingefordert, dass die Community auf neue Beiträge schaut und ebenso fundiert wie konkret Kritik übt. In der Logik von GitLab heißt das, dass jemand etwas schreibt und dann mit einem Merge Request um die Integration seines Beitrags ins große Ganze des Projekts bittet. Das gilt für Text genauso wie für Code. In diesem Moment besteht die Möglichkeit, den Beitrag von mehreren Augen begutachten und kommentieren zu lassen (vgl. Screenshot).

Ansicht eines Merge Requests, hier aus dem Projekt Hop-on. Grüne Zeilen wurden ergänzt, rote entfernt. In diesem Moment können zeilenweise und/oder global Anmerkungen an den Beitragenden geschrieben werden.

Überträgt man diesen Ansatz auf die (Weiter)entwicklung von OER mit Markdown-Dateien, ist eine verlässliche Qualitätskontrolle durch einen permanenten und iterativen Reviewprozess möglich. Was oft durch Emailpingpong mit Office-Dokumenten im Korrekturmodus stattfindet, wird in die Browseroberfläche verlagert. Die Zusammenarbeit in den OER-Teams an der TUHH und die Ergebnisse haben gezeigt, dass ein Umstieg auf diese Form der transparenten und effektiven Kollaboration möglich und sinnvoll ist.

Vorschau auf Beiträge und Änderungen mit Review Apps

Der zuvor beschriebene Zusammenhang von GitLab und Docker bringt für die Qualitätssicherung in der OER-Entwicklung einen großen Vorteil, den GitLab durch die Funktion Review Apps bietet. Einmal eingerichtet, erlauben Review Apps die Generierung des OER-Materials für jeden parallelen Entwicklungsstrang (branch²) eines Projekts durch einen separaten Docker-Container. Auf diese Weise lassen sich konkurrierende und jeweils vollständige Vorschauversionen von GitBooks und anderen Generator-Artefakten erstellen, die anschließend mit dem Team in Merge Requests diskutiert werden können. Autor_innen erhalten mit Review Apps Arbeitsbereiche, in denen sie alle Freiheiten für Experimente und Vorschläge haben, die sie mit anderen diskutieren wollen.

Gerade die Funktion der Review Apps in GitLab bietet für die Entwicklung von OER-Material Vorteile und Möglichkeiten, die in anderen Systemen zur Dokumentenerfassung nicht gegeben sind (Wikis, GoogleDocs, Blogs).

Die Möglichkeiten, Projekte in GitLab zu dokumentieren und im Prozess ihrer Entwicklung zu diskutieren, sind durch Issues und Wikis zwar gegeben. Jedoch wollten wir herausfinden, was ein anderes mittlerweile viel gelobtes und verwendetes Tool für die Projektkommunikation und das Projektmanagement leistet.

Projektkommunikation mit Mattermost

Slack hat sich im Softwarebereich als wichtiges Kommunikationstool etabliert und wird zunehmend auch in Forschung und Lehre genutzt. Da wie bei allen proprietären Tools nicht klar ist, wie verlässlich und nachhaltig es ist, haben wir uns an der TUHH für die freie Alternative Mattermost entschieden. Wir koordinieren seit 2016 HOOU-Projekte damit und nutzen das Tool auch für die instituts- und institutionsübergreifende Kommunikation am ITBH. Seit dem Sommersemester 2017 setzen wir Mattermost auch in der Lehre ein. Mattermost lässt sich technisch mit GitLab koppeln, was dazu führt, dass die Webentwicklung direkt mit der Diskussion und dem Austausch um und in den Projekten verschränkt ist. Neue Issues und Kommentare tauchen direkt im Stream des entsprechenden Kanals in Mattermost auf und zeigen dort immer aktuelle Aktivitäten der beteiligten Menschen und technischen Systeme an. So sind kurze Reaktionszeiten möglich und eine Kultur des “Slack” kann sich etablieren: Wer gerade Zeit hat, kümmert sich um ein Problem (vgl. Leopold & Kaltenecker, 2013).

Im Folgenden wollen wir die vorgestellten technischen Komponenten in das Experimentierfeld der HOOU einordnen.

Das beschriebene System im Experimentierfeld an der TUHH

Die vorgestellten Komponenten ergeben zusammen ein komplexes technisches System, das kollaborative Arbeitsprozesse ermöglicht, die auf einer höheren Ebene einander ähnlich und damit generisch sind:

Gearbeitet wird gemeinsam mit Git/GitLab an offenen Code-/Textkonstrukten, die serverseitig mit Generatorsoftware in weitere Artefakte und Konstrukte überführt werden können.

Das aktuelle technische System, das wir an der TUHH ins Zentrum des Experimentierfelds für die HOOU gerückt haben, ist in der folgenden Abbildung noch einmal in seinen Kernkomponenten zusammengefasst und im Kontext des Experimentierfelds an der TUHH verortet.

Darstellung des Experimentierfelds der HOOU an der TUHH

Auch andere Tools, die unsere HOOU-Kolleg_innen an der TUHH im Experimentierfeld der HOOU einsetzen, werden mittlerweile auf Basis von Docker gehostet, so z.B. die WordPress-Instanz von Kniffelix, Humhub aus dem Projekt Ruvival sowie H5P im MikiE-Projekt. Auch das Discourse-Forum der Learning Community an der TUHH läuft als Docker-Container und wird in die GitBooks eingebunden.

Ergebnisse aus dem beschriebenen System

Während das beschriebene System im April 2016 noch im Stadium eines Vorhabens war, läuft es mittlerweile produktiv und hat innerhalb und außerhalb des HOOU-Kontextes Ergebnisse hervorgebracht. Die durchgeführten Projekte haben allesamt dazu gedient, das System weiter auszuarbeiten, Menschen zur Zusammenarbeit zu motivieren und damit Wünsche und Anforderungen zu ermitteln, die wiederum in die HOOU zurückfließen.

Hop-on – Wege zum Berufsabschluss³

Homepage der Website von “Hop-on”

Im technischen Zentrum des HOOU-Projekts Hop-on steht eine Django-Anwendung, die einen Fahrplan zur Ermittlung der Berufsbiographie von Migrant_innen und Geflüchteten bereitstellt. Die Ergebnisse, die dieser Fahrplan liefert, liegen in GitLab als eigenständiges GitBook vor. Kommt eine Nutzerin/ein Nutzer zu einem Fahrplanergebnis, lädt Django das nötige Dokument als Markdown-Datei direkt aus GitLab, wandelt es in HTML um und zeigt es innerhalb der Hop-on-Website an. Mit diesem Ansatz wollten wir herausfinden, wie man Forkability und Eigenständigkeit von OER-Materialien bewahren kann und gleichzeitig deren Teile in anderen technischen Kontexten nutzbar macht.

Darüber hinaus wurde das Hop-on-Buch entwickelt, welches ebenfalls als GitBook mit frei verfügbarem Quelltext vorliegt. Hier ging es uns darum herauszufinden, wie man das HTML-Theme von GitBook so abwandeln kann, dass es sich ohne iframe in das Design eines Webseitenkontrukts – hier Django – integrieren lässt.

Ein technischer Aspekt, der uns in diesem Projekt auch interessiert hat, war die Tauglichkeit von GitBook für die Bereitstellung von Inhalten mit Rechts-nach-links-Schrift (RTL). GitBooks können zuverlässig multilingual generiert werden, was wir im Hop-on-Projekt für die Sprachen Deutsch, Arabisch und Farsi nutzen. Für die Übersetzung verwenden wir die Plattform Crowdin und gehen hier nach einem Workflow vor, den wir uns von den Django Girls abgeschaut haben: Auch sie veröffentlichen ihr beliebtes Django-Tutorial als GitBook in zahlreichen Sprachen und haben den Übersetzungsworkflow mit Crowdin automatisiert. An anderer Stelle werden wir diesen Workflow detailliert entfalten, hier sei nur erwähnt, dass Crowdin hervorragend mit GitLab zusammenarbeitet, sodass Übersetzungsprozesse von Markdown-Dokumenten als halbautomatisches Wechselspiel zwischen GitLab und Crowdin ablaufen.

Zwischenfazit. Das Projekt Hop-on war nicht nur inhaltlich eine bereichernde Erfahrung. Es hat hinsichtlich der Technikentwicklung im Experimentierfeld der TUHH als Katalysator gedient, durch den wir viel über die Nutzung von Softwareentwicklungsparadigmen für die OER-Entwicklung herausfinden konnten.

Links

• Homepage des Projekts
• Quelldateien der Fahrplan-Ergebnisse
• Quelldateien des Hop-on-Buchs
• Crowdin-Projektwebseite

BiotechAll – Biotechnologie im Alltag

Screenshot des GitBooks von “BiotechAll”

Das Projekt BiotechAll von Prof. Dr. Andreas Liese und seinem Team ist ebenfalls als GitBook in der GitLab-Umgebung der TUHH entstanden. Die inhaltliche Arbeit haben wissenschaftliche Mitarbeiter durchgeführt, die zuvor mit dem Git-Kosmos noch nichts zu tun hatten. Nach einer kurzen Einarbeitungs- und Betreuungsphase war es ihnen möglich, selbstständig mit dem beschriebenen System zu arbeiten. Das Projekt “BiotechAll” war das erste dieser Art und verfolgte zwei Forschungsfragen hinsichtlich Technologie und Didaktik:

• Wie können statische Webseitenkonstrukte, wie sie ein Static-Site-Generator – auch hier GitBook – hervorbringt, interaktiver gestaltet werden?
• Wie können OER-Materialien schon in der Anfangsphase der Entwicklung für die Weiternutzung konzipiert und optimiert werden?

Inspiriert von den Projekten des MIT Media Lab haben wir hier zwei Ansätze kombiniert und auf die erste Frage eine Antwort gefunden: Der Course-in-a-Box, den das Lab mit dem Static-Site-Generator Jekyll baut, haben wir mit der Forumsoftware Discourse verknüpft, die auch bei Learning Creative Learning und Play With Your Music zum Einsatz kommt. Dafür betten wir vorbereitete Threads aus Discourse per iframe in eine GitBook-Seite ein und kombinieren unsere offene Learning Community an der TUHH mit der linearen Struktur des BiotechAll-Projekts.

Hinsichtlich der zweiten Frage haben wir frühzeitig mit Lehrenden allgemeinbildender Schulen versucht, die Akzeptanz und Nutzung der Materialien zu prüfen. Hierbei wurde deutlich, dass es sinnvoll ist, potenzielle Nachnutzer_innen von OER-Material an der Konzeption zu beteiligen. Bisher arbeiten die gewonnenen Lehrkräfte noch nicht konkret bei der Erstellung und Weiterentwicklung von OER-Materialien mit.

Zwischenfazit. Während die technische Lösung, externe interaktive Inhalte in statische Seiten einzubinden, relativ einfach gelingt, bedarf es eines größeren Aufwands, das Lernangebot zu bewerben und die Zielgruppe zu aktivieren, dort auch tätig zu werden.

Links

• Homepage des Projekts
• Quelldateien des Projekts

Weitere Projekte aus der HOOU

Zwei weitere GitBooks sind in den Projekten learn2compost (Team Prof. Dr. Kerstin Kuchta, TUHH) und Internationale Verhandlungen (Team NIT/Verena Fritzsche) entstanden. Das OER-Projekt “Tutorien zur Informatik” (Team Prof. Dr. Christian Kautz, TUHH) auf der Basis von LaTeX stellt ebenfalls Arbeitsblätter und Quellen unter einer freien Lizenz zur Verfügung.

Weitere OER-Projekte an der TUHH

Die HOOU hat in der TUHH für viele Entwicklungen den Impuls gegeben. So haben wir das beschriebene System auch in anderen Zusammenhängen eingesetzt und weitere OER-Materialien produziert.

• Kollaborieren in Forschung und Lehre (GitBook; Axel Dürkop)
• Veranstaltungsskript “Einführung in die Informatik I und II” (GitBook; Axel Dürkop)
• Handhabung und didaktische Einsatzszenarien zum Kompetenz-Check der Kompetenzwerkstatt – Mein Beruf (GitBook; Prof. Dr. Sönke Knutzen, Dr. Henning Klaffke, Barbara Knauf)

Reflexion und Ausblick

Die Freiheit, auf jedem Desktoprechner die HTML- und PDF-Artefakte aus den Quelldateien generieren zu können, stellt gleichzeitig verhältnismäßig hohe Anforderungen an die technische Arbeitsumgebung sowie die Medienkompetenz der Nutzer_innen. Um den Einstieg an dieser Stelle zu erleichtern, haben wir einen Produktionsworkflow entwickelt, der diese Lernkurve zum einen vermindert, zum anderen aber auch genügend Spielraum nach oben lässt, um weitere Potenziale ausloten zu können und Fortgeschrittene nicht zu langweilen.⁴ Denn GitBook ist wie gesagt nicht der einzige (Static-Site-)Generator, der sich für die Produktion von OER eignet. Das MIT Media Lab hat es mit Course-in-a-Box vorgemacht, wie Kursmaterialien “5R-gerecht” entwickelt und bereitgestellt werden können. Hier kommt ebenso wie bei der Mozilla Foundation Jekyll als Static-Site-Generator zum Einsatz. Zur Klasse der Generatoren können im weitesten Sinne auch pandoc und pdflatex gezählt werden, die Ausgangsformate in Zieldateiformate bzw. Konstrukte umwandeln können.

Die Konzeption und Umsetzung des beschriebenen Systems zur Entwicklung von OER-Materialien mit Git/GitLab und Static-Site-Generatoren hat an der TUHH verschiedene positive Effekte gezeitigt. Die Kooperation zwischen den Autor_innen dieses Artikels mit dem Rechenzentrum und der Bibliothek der TUHH, dem Datenschutzbeauftragten der Hochschulen sowie den Early-Bird-Teams hat technische und soziale Aspekte rund um offene Bildungsmaterialien sehr konkret in den Fokus gerückt. Im Rückblick schätzen wir besonders den Vorgang der Installation und Anpassung komplexer offener technischer Systeme in der Hochschule als wesentlich ein für eine Entwicklung towards openness. Akteur_innen aus verschiedenen Einheiten der Organisation können somit am Thema Offenheit beteiligt werden – anders, als wenn proprietäre oder eingekaufte Tools zum Einsatz kommen.

So erscheint auch die Entscheidung für freie und offene Software im Rückblick sinnvoll und richtig, da wir im Vergleich zu den paid plans von GitBook.com und GitLab.com/GitHub.com in der Lage sind, unsere Installationen und Workflows an unsere Bedürfnisse anzupassen.

Schließlich sind wir davon überzeugt, dass die Kulturtechnik des Teilens mittels Git und GitLab für die Partizipation in der Open-Education- und Open-Science-Bewegung lernenswert und wichtig ist. Nachgelagert wichtig erscheinen hingegen Kenntnis und Können konkreter Produkte, denn deren Abwechslungsfrequenz ist höher, als es das Lernen in der Medienbildung zulässt.

Weitere Ausbaustufen

Usability verbessern. Im vergangenen Jahr wurde deutlich, dass die Arbeit in dem beschriebenen System besonders den Beitragenden innerhalb des Systems viel abverlangt. In diesem Prozess haben wir sehen können, was wir noch beisteuern müssen, damit Kollaboration an OER-Materialien einfacher wird. Wir konnten aber auch feststellen, dass die Open-Source-Community – und dazu gehören wir ja prinzipiell auch – hinsichtlich der Usability noch Arbeit hat, wenngleich gerade GitLab in diesem Punkt wirklich vorbildlich ist und für UI/UX einen eigenen Forschungsansatz hat. Sichtbarkeit von OER steigern. Mittelfristig werden wir daran arbeiten, die Sichtbarkeit des Systems, seiner Potenziale sowie der Ergebnisse innerhalb und außerhalb der TUHH zu erhöhen. Auffindbarkeit von OER verbessern. Damit die Potenziale von OER sich einlösen können, ist es wichtig, OER-Materialien auffindbar zu machen. Entsprechend ist ein Arbeitspaket, welches wir zeitnah angehen werden, die Definition geeigneter Metadaten für OER-Materialien.

Wir freuen uns über Feedback in den Kommentaren unten und laden alle Interessierten ein, sich in GitLab an der TUHH zu registrieren und gemeinsam in neue Projekte zu starten!

Veranstaltungshinweis

Das beschriebene System zur (Weiter)entwicklung von OER-Material stellen Axel Dürkop, Andreas Böttger und Dr. Tina Ladwig am 24.06.2017 in der Zeit von 15:30 bis 17:30 Uhr unter dem Titel Static Site Generators für die Entwicklung von OER nutzen auf dem OERcamp Nord in Hamburg vor.

Anmeldungen sind auf der Website möglich.

Lizenzhinweis

Der Beitrag “Ein technisches System für die kollaborative OER-Entwicklung im Experimentierfeld der TUHH” von Axel Dürkop, Andreas Böttger, Tina Ladwig und Sönke Knutzen steht unter CC-BY 4.0 und darf unter den Bedingungen dieser freien Lizenz genutzt werden.

Referenzen

Leopold, K. & Kaltenecker, S. (2013). Kanban in der IT: eine Kultur der kontinuierlichen Verbesserung schaffen (2., überarb. Aufl.). München: Hanser.

Übergeordnetes Ziel der Hamburg Open Online University (HOOU) ist es, eine Öffnung der Hochschulen zu erreichen und zeitgemäße, webbasierte Lehr- und Lernangebote für unterschiedliche Zielgruppen zur Verfügung zu stellen. Das gesamte Projekt wurde sowohl inhaltlich als auch aus einer Organisationsentwicklungsperspektive als Entwicklungs- und Innovationsprojekt gestartet. Im Rahmen eines Vorprojektes, das 2015 gestartet wurde, werden aktuell konzeptionelle und organisatorische Grundlagen geschaffen für eine nachhaltige Umsetzung der Zielstellungen in der Projektphase ab 2017. In diesem Beitrag wird ein Schlaglicht auf die Produkt- und Projektentwicklung aus der Perspektive der Operativen Koordination (OK) der HOOU geworfen.

Der Markenkern der HOOU als leitende Handlungsmaxime

Konzeptionell dient der Markenkern der HOOU als handlungsleitender Rahmen für das gesamte Projekt. Konkret werden in diesem Rahmen folgende Ziele verfolgt:

• Lehr-/Lernangebote auf akademischem Niveau sollen didaktisch innovativ gestaltet und lernendenzentriert umgesetzt werden. Diese werden in derzeit über 60 sogenannten Early-Bird-Projekten in den Hochschulen entwickelt. Zeitgemäße Kommunikationsmöglichkeiten, sollen die Grundlage für die kommunikative Durchführung der Lehr-/Lernangebote darstellen. Für die Implementierung der Angebote soll vorhandene Open-Source-Software genutzt werden.
• Die Angebote sollen sowohl für neue Zielgruppen zugänglich sein als auch im Rahmen der universitären Lehre zum Einsatz kommen, um eine aktuelle Hochschuldidaktik zu fördern. Neben der Öffnung der Hochschulen geht es also auch um eine nach innen gerichtete Hochschulentwicklung.
• Eine zentrale Webapplikation für die HOOU wird entwickelt, die einerseits einen offenen Zugang zu Lernangeboten schafft und andererseits im weiteren Verlauf des Projektes die Möglichkeit bietet, im Rahmen der Early-Bird-Projekte entstandene mediendidaktische Innovationen abzubilden. Langfristig bildet damit die öffentlich frei zugängliche und nutzbare HOOU-Applikation das Kernstück des Projektes.
• Support- und Qualifizierungsangebote für Lehrende dienen der Förderung einer Lehr- und Lernkultur entsprechend der im Markenkern formulierten Leitlinien.

Agile Entwicklung in zwei parallelen Handlungsfeldern

Ziel des Vorprojektes ist es, einen Prototyp bereitzustellen, der als Minimal Viable Solution (Patton 2014, S. 34) erste Einblicke ermöglicht, wie sich die Handlungsmaximen des Markenkerns konkret umsetzen lassen. Eine Weiterentwicklung dieses ersten Prototyps zu einer integrierten und umfänglichen Webapplikation für die HOOU folgt dann in der Hauptprojektphase ab 2017. Sowohl die organisatorischen als auch die technischen und konzeptionellen Erfahrungen aus dem Vorprojekt dienen als Basis für die Applikationsentwicklung im Hauptprojekt. Diese wird durch die OK gesteuert. Für die Gestaltung nutzerinnen- und nutzerzentrierter technischer Lösungen wurden Prinzipien der agilen Entwicklung (siehe u.a. Patton 2014) eingeführt.

Zentrale Herausforderung bei der Plattformentwicklung ist es, die Anforderungen, die sich erst im Laufe des Vorprojektes im Rahmen der Konzeption, Implementation und Erprobung der Lernarrangements aus den Early-Bird-Projekten ergeben, in die Konzeption der Plattform miteinzubeziehen und dennoch schon während dieser konzeptionellen Phase mit der technischen Entwicklung einer Plattform zu beginnen, um zu einem möglichst frühen Zeitpunkt der Entwicklung die neu entstehenden Lernformate der Öffentlichkeit zur Verfügung zu stellen. Die frühzeitige Bereitstellung ist nötig, um die neuen Konzepte erproben und weiterentwickeln zu können.

Aus organisatorischer Perspektive ergeben sich damit zwei Handlungsfelder, die parallel zueinander laufen und gleichzeitig inhaltlich und zeitlich aufeinander abgestimmt sein müssen.

Abbildung 1: Die zwei Handlungsfelder in der HOOU-Entwicklung

Handlungsfeld 1: (medien-)didaktische Innovation und Hochschulentwicklung

Die Förderung (medien-)didaktischer Innovation und Entwicklung ist eines der beiden zentralen Handlungsfelder. Verantwortlich für die Entwicklung und Erprobung innovativer Formen medienbasierten Lehrens und Lernens sind die Hochschulen, hier konkret die Lehrenden, die sich im Rahmen der Early-Bird-Projekte dazu verpflichtet haben, Lernarrangements unter den Vorgaben des Markenkerns zu gestalten. Ein exploratives Vorgehen fördert dabei die Innovationskraft. Aus technischer Sicht sind flexible Strukturen für die Implementation notwendig, die sich je nach Fachkultur der Early- Bird-Projekte und nach hochschulspezifischer Ausrichtung stark voneinander unterscheiden können.

Im Rahmen der Early-Bird-Projekte konkretisieren die Hochschulen ihre spezifischen Anforderungen an eine zukünftige HOOUWebapplikation. Im Sinne agiler Entwicklung fungieren die Early- Bird-Projekte zunächst als organisatorischer Rahmen zur Erstellung funktionaler Prototypen (Patton 2014, S. 40): Sowohl didaktisch als auch technisch werden medienbasierte Formen der Hochschullehre entwickelt und umgesetzt und im Rahmen von teilweise öffentlich zugänglichen Lehrveranstaltungen hinsichtlich der Zielstellungen des Markenkerns erprobt. Die technische Implementierung der Early-Bird-Projekte erfolgt in dezentralen Experimentierfeldern. Grundlage hierfür sind bestehende Infrastrukturen der Hochschulen sowie eigens für die HOOU bereitgestellte Installationen von Open-Source-Tools, die lose miteinander gekoppelt werden.

Aufgabe der OK ist es, anschließend, auf Basis von Evaluationen der ersten Durchläufe der aus den Early-Bird-Projekten entstandenen Lehr-/Lernszenarien, die Anforderungen an die Plattform gemeinsam mit den Hochschulen zu konkretisieren und zu operationalisieren.

Handlungsfeld 2: zentrale Entwicklung eines Prototyps

Die Entwicklung eines gemeinsamen Prototyps als zweites Handlungsfeld ist eine zentrale Aufgabe, die von der OK gesteuert wird. Langfristiges Ziel der Plattformentwicklung ist eine Seamless Software Integration (Paulheim & Erdogan 2010). Das bedeutet, die bisher in den Experimentierfeldern lose gekoppelten Tools werden – nach Erprobung und Evaluation im Rahmen der Durchführung von Lernarrangements – so miteinander verbunden, dass es keine wahrnehmbaren Brüche in der Nutzung der Plattform gibt. In der aktuellen Vorprojektphase steht der Aufbau eines strukturierten und benutzerinnen- und benutzerfreundlichen Zugangs zu Materialien und den verteilten Lernangeboten der Early-Bird-Projekte im Fokus der Entwicklung.

In Abstimmung mit der Expertengruppe Plattform und Konzeption wurden folgende konkrete Zielsetzungen für die Prototypentwicklung herausgearbeitet:

• Alle Inhalte und Angebote, die im Rahmen des Projektes erstellt werden, werden als Open Educational Resources (OER) unter CC-Lizenzen bereitgestellt, sodass eine Weiternutzung der Inhalte ermöglicht wird. Dabei geht es darum, die Weiterverbreitung und die Nutzung in anderen Kontexten zu ermöglichen sowie die gemeinsame Bearbeitung, Weiterentwicklung und Versionierung von Lernmaterialien zu unterstützen (siehe auch Wileys „5R“ (2014) für OERMaterialien: „Retain, Reuse, Revise, Remix, Redistribute“).
• Über ein zentrales Portal erhalten Studierende und interessierte Bürgerinnen und Bürger Zugang zu Lernangeboten der Hochschulen. Die Lernangebote werden mittels eines formalisierten Steckbriefes auf dem Portal dargestellt. Über einen Link gelangt man direkt zu den Lernangeboten, die von den Hochschulen auf den jeweiligen hochschuleigenen Infrastrukturen zur Nutzung bereitgestellt und auch dort organisatorisch verwaltet und gesteuert werden.
• In einem zentralen OER-Repository werden die einzelnen Lernmaterialien wie z. B. Vorträge, Skripte, Bildersammlungen, Arbeitsblätter etc. gespeichert und öffentlich zugänglich gemacht. Intelligente Vorschlagsmechanismen und thematische Verknüpfungen der einzelnen Materialien unterstützen das Finden von Inhalten. Zusätzlich zur Teilnahme an den vorstrukturierten Lernangeboten wird damit auch verstärkt ein informelles, selbstgesteuertes Lernen für interessierte Bürgerinnen und Bürgern ermöglicht.
• Zur Schaffung einer möglichst großen Anschlussfähigkeit an andere Repositorien wird ein Metadatenmodell implementiert, das sich an gängigen Standards orientiert.
• Alle Inhalte, die im Repository gespeichert sind, können direkt in andere Webseiten, Learning Management Systems (LMS), Blogs etc. eingebunden werden, sodass zentral gespeicherte Materialien auch im Rahmen der Lernangebote in den Infrastrukturen der Hochschulen genutzt werden können.

Ausblick

Da sich in einer Zeit des permanenten technologischen Wandels auch die Formen und Tools der Kollaboration und Kommunikation permanent verändern, ist das oben beschriebene zweigleisige Vorgehen nicht als reine Projektstruktur zu verstehen, die nach Fertigstellung der HOOU-Webapplikation auf Betrieb und Weiterentwicklung einer Plattform reduziert werden kann. Vielmehr ergibt sich mit der HOOU die Möglichkeit, agile Formen der Entwicklung und Raum für hochschul- und mediendidaktische Experimente als langfristiges Konzept für eine zeitgemäße Infrastrukturentwicklung in die Hochschulen zu überführen – ganz im Sinne Werner Sesinks, der bereits 2006 postulierte: „Die Bildungseinrichtungen werden sich darauf einstellen müssen, dass sie zu permanenten Baustellen werden. ‚Under construction‘ wird keine vorübergehende Behinderung des Betriebs mehr anzeigen, sondern die neue Grundverfassung. Das kann man bejammern und beklagen. Darin kann man aber auch eine Chance sehen: zu offenen Strukturen, die auf Experiment und Kreativität, auch auf Bereitschaft zur Revision, Umgang mit Erfahrungen des Scheiterns eingestellt sind und eine permanente Meta-Reflexion des Entwicklungsprozesses verlangen“ (in Scheibel 2006, S. 4).

Verweis und Literatur

*Dieser Beitrag von Christina Schwalbe, Patrick Peters, Tina Ladwig, Iver Jackewitz, Marc Göcks, Sönke Knutzen aus der SYNERGIE – Fachmagazin für Digitalisierung in der Lehre, #2, Seite 42-43, steht unter CC-BY-SA 4.0 und darf unter den Bedingungen dieser freien Lizenz nachgenutzt werden. Der Beitrag wurde ergänzt um die Abbildung 1 „Die zwei Handlungsfelder in der HOOU-Entwicklung“.

HOOU (2016). https://projekte.hoou.de/p/konzept-hamburg-open-online-university-hoou/

Patton, Jeff (2014). User Story Mapping: [discover the Whole Story, Build the Right Product]. Beijing [u.a.]: O’Reilly.

Paulheim, Heiko & Erdogan, Atila (2010). Seamless integration of heterogeneous UI components. In: Proceedings of the 2nd ACM SIGCHI symposium on Engineering interactive computing systems (EICS ‚10). ACM, New York, NY, USA, S. 303-308. Verfügbar unter: https://uhh.de/hxb0g [12.10.2016].

Scheibel, Michael (2006). „Under construction“ – Ein Meinungsspiegel zur Transformation von Bildungsinstitutionen. merz medien+erziehung (2/06 und 3/06).

Wiley, David (2014). Opencontent.org: The Access Compromise and the 5th R. Verfügbar unter: http://opencontent.org/blog/archives/3221 [12.10.2016].

Work at and on the Hamburg Open Online University (HOOU) is leading to a variety of ideas and new creative approaches at the TUHH. Processes such as “digitization” and “opening” in universities are being discussed and interpreted at different levels, and technical solutions are being considered and evaluated in a new light against the backdrop of current trends and developments. The development of the HOOU is thus impacting on the TUHH. In recent weeks it has led to the conception and implementation of internal solutions, the experience and results of which are to feed back into the broader context of the HOOU. This paper presents the initial results of this development. This phase was guided by the basic principles of Open Educational Resources (OER), an approach of loose coupling of technical systems, and above all prioritization of didactic requirements over technical possibilities.

Technical requirements for OER

If in implementing this approach one is closely guided by the principles that David Wiley proclaimed as the mission of the OER movement, specific requirements for technical implementation result. Analogously to Richard Stallmann, who recorded the essential freedoms for free software in the GPL, Wiley formulated his “5 Rs.” Accordingly, users of OER should be able to:

“1. Retain – the right to make, own, and control copies of the content (e.g., download, duplicate, store, and manage)
2. Reuse – the right to use the content in a wide range of ways (e.g., in a class, in a study group, on a website, in a video)
3. Revise – the right to adapt, adjust, modify, or alter the content itself (e.g., translate the content into another language) 4. Remix – the right to combine the original or revised content with other material to create something new (e.g., incorporate the content into a mashup)
5. Redistribute – the right to share copies of the original content, your revisions, or your remixes with others (e.g., give a copy of the content to a friend)”¹

Along with the 5 Rs, Wiley goes on to suggest the technical environment to be considered when producing and delivering OER. His ALMS Framework is as follows:

“1. Access to Editing Tools: Is the open content published in a format that can only be revised or remixed using tools that are extremely expensive (e.g., 3DS MAX)? Is the open content published in an exotic format that can only be revised or remixed using tools that run on an obscure or discontinued platform (e.g., OS/2)? Is the open content published in a format that can be revised or remixed using tools that are freely available and run on all major platforms (e.g., OpenOffice)?
2. Level of Expertise Required: Is the open content published in a format that requires a significant amount technical expertise to revise or remix (e.g., Blender)? Is the open content published in a format that requires a minimum level of technical expertise to revise or remix (e.g., Word)?
3. Meaningfully Editable: Is the open content published in a manner that makes its content essentially impossible to revise or remix (e.g., a scanned image of a handwritten document)? Is the open content published in a manner making its content easy to revise or remix (e.g., a text file)?
4. Self-Sourced: It the format preferred for consuming the open content the same format preferred for revising or remixing the open content (e.g., HTML)? Is the format preferred for consuming the open content different from the format preferred for revising or remixing the open content (e.g. Flash FLA vs SWF)?”²

If one takes these rights and technical requirements for OER as a strict specification for the conception and implementation of a technical environment, there are consequences at the detailed level in respect of the file storage format and the nature of the location where open teaching and learning materials are made available. The software used must be taken into consideration, along with the skills and motivation of the players involved.

Against the backdrop of these conceptual stipulations guiding action in the context of the Open Education Movement, initial experiences of Early Bird supervision at the TUHH are taking shape.

OER: Decoupling of content and structure

At the TUHH the view has become established that separation of a teaching-learning arrangement into structuring and content units makes sense. This separation has the advantage of making content accessible openly and independently of a chronological process, thereby improving its shareability, further use and re-contextualization. In practice this means that interested parties can formulate their own questions and ideas to engage with a learning resource outside a structured process, and to develop it further where appropriate. Wikis and forums are examples of tools for creating places of this kind. At best, a learning community will come into being that attracts many interested parties because it permits high degrees of freedom for situating topics and content³. However, newer formats and tools for the provision and collaborative further development of content are also possible, as will be shown below.

There are some inspiring examples of the separation of content and structure in P2PU, such as the learning community “Play With Your Music”. Here, learning activities are centered around a modern forum based on the free software Discourse that calls on learners to engage cooperatively and/or collaboratively with the content. Upstream is a website that gives interested persons the choice of learning alone or with others in a group. If a sufficient number of interested persons come together, the cohort is guided through the content in a structured way⁴. This idea is implemented with a Mechanical MOOC by P2PU.

The concept of Course in a Box by P2PU brings another idea into the discussion. Fully in line with the OER idea, the aim is to enable interested persons to develop a learning offering themselves or to adapt and re-contextualize existing offerings for their own purposes. The approach to teaching how to create a Course in a Box is not just to supply a guide to organizing a learning arrangement of this kind. Instead, the guide itself is the software engineering starting point for your own offering. The Create Your Course page contains a description of what to do. This process refers to fork and contribute, a new cultural technique of sharing that has developed in the organization of software development work processes. I will explain below how these influences can be utilized for the OER concept and the HOOU.

Steps for developing an HOOU technical environment at the TUHH

A kind of self-experiment can be held responsible as the starting point of the step towards an HOOU technical environment at the TUHH, as described below. When I had to redesign the “Informatics I” course, I discovered there was no specific script or textbook to support students in processing the course topics. It quickly became evident that I should compensate for this lack by producing new and customized material. This gave rise to the idea of making this material available to prospective vocational school teachers on the course in the form of an OER resource that they could subsequently adapt to their own professional requirements and utilize for designing their own lessons. Guided by Wiley’s requirements and degrees of freedom for OER, I looked for a technical implementation tool that I could use to produce the material. In doing so I found the GitBook website and software, which seemed ideal for developing learning resources. Hence, the script Python.Processing.Arduino was generated online while the course was running. It changed frequently as a result of criticism and suggestions by students and tutors during production⁵. The students mainly used the online version, which exists in a simple HTML construct with an outline function and scroll function and enables incorporation of videos and other media. From time to time they also downloaded the PDF version⁶. My experience with the tool and the online service was very positive and I enjoyed authoring a living document in this way. The only thing that disturbed me was that in order to do so I was dependent on a service that was not under my control as regards data retention and functionality. As I will show in the following sections, it was possible to reduce or even remove these dependencies by meaningful coupling of individual free software components.

The simplicity and clarity of GitBook suggests a further use that implements the separation of structure and content I described at the beginning. Learning arrangements can also be mapped in the form of a GitBook. As a rule, these are linear in structure and in their most elementary form consist of a succession of work instructions and interaction offers (see again the structure of Course in a Box)⁷. Thus the use of GitBooks in HOOU serves a dual purpose, with a conceptual distinction between the two:

• Content GitBooks are multimedia HTML pages of linear structure that can be used to prepare information and supply it in a similar way to a textbook.
• Learning Arrangement GitBooks (LA GitBooks) are HTML pages of linear structure that can be used to structure a learning arrangement in the form of a sequence. They contain less specific specialist content, but rather formulations of goals, assignments, proposed methods, interaction offers, and general information on processing and dealing with content.

This idea gave rise to a design for the technical landscape at the TUHH with which several Early Bird projects are now being implemented. The overall construct with its individual units and interfaces will be presented in more detail below.

Technologies, software and interfaces

The developing HOOU technical environment at the TUHH is divided into various components that are currently being evaluated in the first Early Bird projects. Fig. 1, which is referred to in the following sections, should serve to demonstrate the structures and software solutions presented.

Figure 1: Developing HOOU-LAs at TUHH with GitBook, GitLab, Discourse and Sandstorm.

GitBook

GitBook is both an online service and a collection of free software tools that can be used for collaborative processing of text documents of linear structure. Thus GitBook is nothing but a simple and effective Static Site Generator⁸. Along with the aforementioned script Python.Processing.Arduino there are further examples of GitBooks on the service’s online presence.

Markdown: the online lingua franca

GitBooks are written in Markdown. Markdown is a widespread way of marking up text, or marking parts of it as headings, lists or emphases⁹. The Markdown documentation on the GitBook website conveys a visual impression of the concept. The aim of writing in Markdown is to convert documents subsequently into different formats, usually into HTML. This also happens in the GitBook production process, which involves generating a static HTML page from several structured Markdown documents.

Markdown is very helpful to the OER idea, since texts can also be converted into PDF and Office documents. Even presentations are possible¹⁰. Because the ultimate format has not been decided when producing Markdown texts, it is easy to comply with the requirement to distribute OER material not only as open source but also in a form that is technically easy to edit. The only thing required for editing is a text editor (Notepad, TextEdit or GitBook Editor), and the estimated cost of training qualified authors is low. Since Markdown is increasingly widespread on the Net, writers learn a modern means of expression that enables participation in collaborative processes in many other places.

There is a further advantage to using Markdown. Since Markdown documents are pure text files, technically they can be treated in exactly the same way as those that contain software code. As sec. 4.2 is intended to show about GitLab, that is a major advantage in terms of the shareability and re-usability of OER materials.

Markdown can easily be mixed with HTML elements. That external media and resources can be incorporated into the GitBook at any point with the help of the HTML tag iframe could be seen as an advantage¹¹. The benefit of this possibility will become clear in a later section on the interlinking of LA GitBooks and Discourse (cf. sec. 4.2.4).

Cooperation with the Early Bird teams

The production of LA GitBooks and Content GitBooks takes place collaboratively at the TUHH. Early Bird supervisors, research assistants and teachers initially work together on larger Markdown documents that are shared on TUHH Owncloud. Later, this content is divided into individual files in accordance with GitBook conventions and developed further collaboratively (cf. Fig. 1). But how do these files become a GitBook that can be used, copied, edited and used further by others? To meet these requirements, an instance of GitLab software is used. Its functionality and role will be explained in more detail below.

Collaboration with GitHub and GitLab

The page Course in a Box: Create Your Course invites you to act with the following sentence: “Fork this repository on GitHub”. Fork is the core concept of sharing in the manner of the GitHub service and means copying someone’s project files into your own GitHub account. This gives users the freedom to do what they like with the files without having to ask the originator for permission to become involved. As a rule, fork in this case is not an aggressive act that initiates entry into a competition for the better product¹². Rather, it is customary for improvements and changes resulting from the fork to be reported back to the originator with a pull request to integrate the changes into the original. In terms of OER ideas this signifies a decisive difference from Wikis. In this form of cooperation all involved are in principle always full participants in the data that constitutes a resource. In the classic database-based Wiki, it is not possible to fork without a request for and release of the appertaining data(base)¹³. However, this is not the only advantage in terms of maximum forkability. Compared with a Wiki, re-contextualization is performed relatively quickly in a fork, especially if the raw data consists of Markdown files, for example in the form of a GitBook. Such changes can range from changing the university logo to restructuring, supplementing, or omission of units, or enrichment with media.

Maximum Forkability with GitLab

Forking is also possible with GitLab. GitLab is free software that emulates the proprietary service GitHub and the Web-based exchange of files according to the principles of the version control system Git. If universities want to be independent of services that can change data use and handling rules at any time and even lock the data in their technical environment, free software solutions such as GitLab exist that are freely configurable and extendable. GitLab can be hosted on university servers and the current version is used at the TUHH for the HOOU.

Learning to share with Git and GitLab

So far there are few research findings on the use of Git/GitHub/GitLab in teaching and learning contexts, but in general the learning curve can be estimated as steep (see Zagalsky, Feliciano, Storey, Zhao & Wang, 2015). During the semester I am currently testing with my students the use of GitHub as a collaboration platform in teaching in order to identify the stumbling blocks and to learn more about the introduction of this promising tool.

In view of the steep learning curve we at the TUHH have decided not to burden colleagues at the interfaces with the Early Bird teams with acquiring Git/GitLab skills. We only ask them to file their articles in the form of Markdown files in a shared Owncloud folder. GitBooks are prepared by individual colleagues who are curious to explore the possibilities of this new form of collaboration. Simultaneously, we are trying to find out how meaningful and affordable Git/GitLab is for the production and further use of OER materials at the TUHH, including for research associates, student assistants and teaching staff.

Continuous publication of GitBooks

GitLab brings with it a component that enables automatic tests in software development (Continuous Integration). This quality assurance tool is repurposed in the context of GitBook production to ensure automatic generation of the GitBook HTML page every time changes are uploaded in GitLab (push). This means that the “source text” of a GitBook is always available on GitLab, but that the LA GitBook or Content GitBook can be published automatically anywhere on the Net.

This Continuous Deployment offers great added value, and not only for work with and on GitBooks. The workflow also makes sense in combination with other static site generators that process Markdown and then build good-looking and structured websites. So GitBook is only an exchangeable generator at the end of a flexible technical process.

Embedding of other media and tools

In an HTML context it is easy to embed other media from the Web. Many services such as Podcampus, Youtube, Twitter etc. offer integration of content into their own contexts. For this, the old HTML tag iframe is used. This loose coupling of media and tools is fully in line with the remix freedom of OER materials. For the Early Bird projects at the TUHH, discussions that take place in a Discourse forum are integrated into a GitBook by means of an iframe. In this way, elements from the learning community are connected with the LA Gitbook (cf. Fig. 1). Podcampus videos are integrated in the same way.

GitLab as an OER repository

A central tenet of the HOOU idea is that all OER materials generated should be provided in an OER repository. Here, too, the TUHH sees GitLab as a possible tool for technical implementation. Raw data and finished OER materials can be made publicly available to download or fork via GitLab. The next steps of our work will be to further develop this approach and test its suitability.

GitLab manages projects that are technically known as repositories. Any number of files can be stored in each repository. They should be text line-based as is the case with program code and Gitbooks. This favors collaboration by means of Git as described above. However, it is also technically possible to store other file formats such as Office documents or presentations, because these, too, can be recorded by Git/GitLab and can be annotated to indicate changes. GitLab is not suitable for storing moving image material and not recommended for managing pictures and graphics.

Since the homepage of a GitLab instance seems very technical¹⁴, a more appealing and functional home page with a search function could conceivably be installed upstream. GitLab’s public interface (API) permits adjusted processing of stored data.

Sandstorm as a further education instrument

Current studies show that by no means all students are as adept at dealing with modern Web applications as is always assumed¹⁵. The same may apply in part to teachers and other colleagues at universities, which is why we can assume a need for information and further education. In the context of Early Bird supervision at the TUHH one sees that it is good to inform everyone involved, first about the possibilities and potential of current tools¹⁶, in order to win them over to the process of joint development of a convincing learning arrangement.

Sandstorm software performs a good service in this respect as it assembles more than fifty free software tools in a single access and enables both teachers and learners to build their own media-based learning environment. In the course of evaluating media-based learning forms for the HOOU, Sandstorm is used experimentally in a variety of contexts so as to ascertain the potential for teaching and further education (see Knutzen & Howe, 2013). I have written about Sandstorm’s functioning and possibilities in my personal blog¹⁷.

Summary

The Hamburg Open Online University has given the TUHH a strong impetus for engagement with the subjects of digitization, openness and university didactics. In this article we have presented an approach to the technical implementation of HOOU learning arrangements at the TUHH with reference to the principles of the open education movement and their technical and didactical implications.

References

• Kerres, M. (2012). Mediendidaktik: Konzeption und Entwicklung mediengestützter Lernangebote. München: Oldenbourg.
• Knutzen, S., & Howe, F. (2013). Digitale Medien in der gewerblich-technischen Berufsausbildung – Einsatzmöglichkeiten digitaler Medien in Lern- und Arbeitsaufgaben. foraus.de/BIBB. Accessed Dec 12, 2013. Retrieved from http://datenreport.bibb.de/media2013/expertise_howe-knutzen.pdf
• Reinmann, G. (2010). Studientext Didaktisches Design. Studientext, Universität der Bundeswehr, München. Accessed May 5, 2015. Retrieved from http://gabi-reinmann.de/wp-content/uploads/2010/04/Studientext_DD_April10.pdf
• Tkacz, N. (2015). Wikipedia and the Politics of Openness. Chicago; London: University of Chicago Press.
• Wild, E., & Möller, J. (Eds.). (2015). Pädagogische Psychologie (2nd ed.). Berlin, Heidelberg: Springer Berlin Heidelberg. Accessed August 10, 2016. Retrieved from http://link.springer.com/10.1007/978-3-642-41291-2
• Zagalsky, A., Feliciano, J., Storey, M.-A., Zhao, Y., & Wang, W. (2015). The Emergence of GitHub as a Collaborative Platform for Education (pp. 1906–1917). ACM Press. http://doi.org/10.1145/2675133.2675284

Fotocredits: “Karelia” von Petr Magera@flickr, CC-BY

“Developing an Open Technical Infrastructure for HOOU Learning Arrangements at the Hamburg University of Technology (TUHH)” by Axel Dürkop is licensed under Creative Commons Attribution 4.0 International License.

This article was originally posted on the HOOU blog April 28, 2016 in German and can be found at https://projekte.hoou.de/p/2016/04/28/entwicklung-einer-offenen-technischen-infrastruktur-fuer-hoou-lernarrangements-an-der-tuhh/.

Die Arbeit in und an der Hamburg Open Online University (HOOU) führt auch in der TUHH zu einer Vielzahl von Ideen und neuen kreativen Ansätzen. Prozesse wie “Digitalisierung” und “Öffnung” der Hochschulen werden auf unterschiedlichsten Ebenen diskutiert und interpretiert, technische Lösungen vor dem Hintergrund aktueller Trends und Entwicklungen neu beleuchtet und evaluiert. Die Entwicklung der HOOU wirkt somit auch zurück auf die TUHH und hat in den vergangenen Wochen zur Konzeption und Implementierung erster hochschulinterner Lösungen geführt, aus denen Erfahrungen und Ergebnisse zurückfließen sollen in den Gesamtzusammenhang der HOOU. Die ersten Ergebnisse dieser Entwicklung sollen hier vorgestellt werden. Leitend in dieser Phase waren die Grundprinzipien für Open Educational Resources (OER), ein Ansatz der losen Kopplung technischer Systeme, vor allem aber die Priorisierung didaktischer Anforderungen vor technischen Möglichkeiten.

Technische Anforderungen an OER

Orientiert man sich für die Umsetzung dieses Ansatzes streng an den Prinzipien, die David Wiley einst der OER-Bewegung auf die Fahne geschrieben hat, ergeben sich konkrete Anforderungen an die technische Umsetzung. Wiley hatte – analog zu Richard Stallman, der die Freiheiten im Bezug auf Software in der GPL niedergeschrieben hat – seine “5R” formuliert. Nutzer_innen von OER haben das Recht zu

“1. Verwahren/Vervielfältigen – das Recht, Kopien des Inhalts anzufertigen, zu besitzen und zu kontrollieren (z.B. Download, Speicherung und Vervielfältigung)
2. Verwenden – das Recht, den Inhalt in unterschiedlichen Zusammenhängen einzusetzen (z.B. im Klassenraum, in einer Lerngruppe, auf einer Website, in einem Video)
3. Verarbeiten – das Recht, den Inhalt zu bearbeiten, anzupassen, zu verändern oder umzugestalten (z.B. einen Inhalt in eine andere Sprache zu übersetzen)
4. Vermischen – das Recht, einen Inhalt im Original oder in einer Bearbeitung mit anderen offenen Inhalten zu verbinden und aus ihnen etwas Neues zu schaffen (z.B. beim Einbauen von Bildern und Musik in ein Video)
5. Verbreiten – das Recht, Kopien eines Inhalts mit Anderen zu teilen, im Original oder in eigenen Überarbeitungen (z.B. einem Freund eine Kopie zu geben oder online zu veröffentlichen)”¹

Flankierend zu den “5R” macht Wiley auch noch einen Vorschlag zu den technischen Rahmenbedingungen, die bei der Produktion und Bereitstellung von OER berücksichtigt werden sollten. Sein so genanntes ALMS-Framework lautet wie folgt:

“1. Access to Editing Tools: Is the open content published in a format that can only be revised or remixed using tools that are extremely expensive (e.g., 3DS MAX)? Is the open content published in an exotic format that can only be revised or remixed using tools that run on an obscure or discontinued platform (e.g., OS/2)? Is the open content published in a format that can be revised or remixed using tools that are freely available and run on all major platforms (e.g., OpenOffice)?
2. Level of Expertise Required: Is the open content published in a format that requires a significant amount technical expertise to revise or remix (e.g., Blender)? Is the open content published in a format that requires a minimum level of technical expertise to revise or remix (e.g., Word)?
3. Meaningfully Editable: Is the open content published in a manner that makes its content essentially impossible to revise or remix (e.g., a scanned image of a handwritten document)? Is the open content published in a manner making its content easy to revise or remix (e.g., a text file)?
4. Self-Sourced: It the format preferred for consuming the open content the same format preferred for revising or remixing the open content (e.g., HTML)? Is the format preferred for consuming the open content different from the format preferred for revising or remixing the open content (e.g. Flash FLA vs SWF)?”²

Nimmt man die Rechte sowie die technischen Anforderungen an OER als strenge Vorgabe für die Konzeption und Implementierung einer technischen Umgebung, ergeben sich Konsequenzen auf der Detailebene und tangieren das Speicherformat für Dateien ebenso wie die Beschaffenheit des Ortes, an dem offene Lehr-Lernmaterialien zur Verfügung gestellt werden. Die verwendete Software ist zu berücksichtigen wie auch die Qualifikation und Motivation der beteiligten Akteure.

Vor dem Hintergrund dieser konzeptionellen Vorgaben, die das Handeln im Kontext der Open-Education-Bewegung leiten, kristallisieren sich erste Erfahrungen in der Early-Bird-Betreuung an der TUHH heraus.

Entkopplung von Inhalt und Struktur

An der TUHH hat sich die Auffassung gefestigt, dass eine Trennung eines Lehr-Lernarrangements in strukturierende und ein inhaltliche Einheiten sinnvoll ist. Diese Aufteilung bietet den Vorteil, Inhalte offen und unabhängig von einem chronologischen Ablauf zugänglich zu machen und so ihre Teilbarkeit, Weiternutzung und Rekontextualisierung zu verbessern. Für die Praxis bedeutet das, dass Interessierte sich auch jenseits eines strukturierten Ablaufs durch eigene Fragestellungen und Ideen mit einer Lernresource auseinandersetzen und diese ggf. weiterentwickeln können. Wikis und Foren sind hier als Beispiele für Werkzeuge zu nennen, um Orte dieser Art zu schaffen. Im besten Fall entsteht eine learning community, die viele Interessierte anzieht, weil sie hohe Freiheitsgrade in der Situierung zulässt³. Aber auch neuere Formate und Werkzeuge für die Bereitstellung und kollaborative Weiterentwicklung von Inhalten bieten sich an, wie im folgenden noch gezeigt werden wird.

Einige inspirierende Beispiele für die Trennung von Inhalt und Struktur finden sich bei der P2PU, so z.B. die learning community “Play With Your Music”. Im Zentrum der Lernaktivitäten liegt hier ein modernes Forum auf der Basis der freien Software Discourse, das die kooperative bzw. kollaborative Auseinandersetzung der Lernenden mit den Inhalten einfordert. Vorgeschaltet ist eine Webseite, die Interessierten die Wahl lässt: Alleine lernen oder in der Gruppe mit anderen? Kommen genügend Interessierte zusammen, wird die Kohorte strukturiert durch die Inhalte geführt⁴. Diese Idee wird mit einem Mechanical MOOCs der P2PU umgesetzt.

Einen anderen Gedanken bringt das Konzept Course in a Box der P2PU in die Diskussion: Ganz im Sinne der OER-Idee sollen Interessierte in die Lage versetzt werden, selbst ein Lernangebot zu erstellen oder vorhandene für eigene Zwecke anzupassen und zu rekontextualisieren. Durch den Ansatz, wie ein Course in a Box bereitgestellt wird, wird nicht nur eine Anleitung geliefert, wie man ein solches Lernarrangement aufziehen sollte – die Anleitung selbst ist die softwaretechnische Ausgangsbasis für das eigene Angebot. Auf der Seite Create Your Course wird beschrieben, was zu tun ist. Der Vorgang verweist auf eine neue Kulturtechnik des Teilens, die sich in der Organisation von Arbeitsprozessen in der Softwareentwicklung etabliert hat – fork and contribute. Wie diese Einflüsse für das OER-Konzept und die HOOU nutzbar gemacht werden können, will ich im folgenden ausführen.

Entwicklungsschritte zur technischen Umgebung der HOOU an der TUHH

Eine Art Selbstversuch kann als Ausgangspunkt für den im folgenden beschriebenen Schritt zu einem Teilbereich der HOOU-Technik an der TUHH verantwortlich gemacht werden. Infolge der Neukonzeption der Lehrveranstaltung “Einführung in die Informatik I” mangelte es an einem konkreten Skript oder Lehrbuch, das die Studierenden beim Erarbeiten des Veranstaltungsstoffs unterstützen sollte. Schnell war klar, dass der Mangel durch die Produktion eigenen Materials kompensiert werden musste. Dabei entstand die Idee, dieses den angehenden Berufsschullehrer_innen in der Veranstaltung in Form einer OER-Resource zur Verfügung zu stellen, die sie später in der Berufspraxis an eigene Bedürfnisse anpassen und für die eigene Unterrichtsgestaltung nutzen könnten. Geleitet von Wileys Anforderungen und Freiheitsgraden für OER suchte ich nach einer technischen Implementierung, mit der ich die Produktion des Materials umsetzen wollte. Dabei fand ich die Website bzw. Software GitBook, die für die Erstellung von Lernresourcen bestens geeignet schien. So entstand online und begleitend zur Veranstaltung das Skript Python.Processing.Arduino, das sich durch die Kritik und Anregungen der Studierenden und des Tutors während der Produktion oft veränderte⁵. Die Studierenden nutzten hauptsächlich die Online-Version, die in einem einfachen HTML-Konstrukt mit Gliederung und Blätterfunktion besteht und die Einbindung von Videos und anderen Medien ermöglicht, luden sich aber zeitweise auch die PDF-Variante herunter⁶. Meine Erfahrung mit dem Tool und dem Online-Service waren sehr positiv, es hat mir Spaß gemacht, auf diese Weise ein lebendiges Dokument zu verfassen. Einzig die Tatsache, dass ich hierfür auf einen Service angewiesen war, der hinsichtlich Datenhaltung und Funktionalität nicht meiner Kontrolle unterliegt, hat mich gestört. Wie ich in den folgenden Abschnitten zeigen werde, können diese Abhängigkeiten jedoch durch sinnvolle Kopplung einzelner freier Softwarekomponenten reduziert oder sogar aufgehoben werden.

Die Einfachheit und Klarheit von GitBooks legt noch einen weiteren Einsatzzweck nahe, der die eingangs beschriebene Trennung von Struktur und Inhalt implementiert: Lernarrangements lassen sich ebenfalls in Form eines GitBooks abbilden. Diese sind in der Regel linear aufgebaut und bestehen in ihrer elementarsten Form aus einer Abfolge von Arbeitsanweisungen und Interaktionsangeboten (vgl. hierzu nochmals den Aufbau von Course in a Box)⁷. Folglich ergibt sich mit dem Einsatz von GitBooks in der HOOU ein doppelter Verwendungszweck und damit eine begriffliche Unterscheidung:

• Content-GitBooks sind linear aufgebaute multimediale HTML-Seiten, mit denen Informationen aufbereitet und ähnlich einem Lehrbuch zur Verfügung gestellt werden können.
• Lernarrangement-GitBooks (LA-GitBooks) sind linear aufgebaute HTML-Seiten, mit denen ein Lernarrangement in Form eines Ablaufs strukturiert werden kann. In ihnen finden sich weniger konkrete fachliche Inhalte, sondern vielmehr Zielformulierungen, Aufgabenstellungen, Methodenvorschläge, Interaktionsangebote und allgemeine Informationen zur Erarbeitung und zum Umgang mit Inhalten.

Aus dieser Idee heraus entstand ein Entwurf für die technische Landschaft an der TUHH, mit der nun einige Early-Bird-Projekte umgesetzt werden. Das Gesamtkontrukt mit seinen einzelnen Einheiten sowie den Schnittstellen soll im folgenden genauer vorgestellt werden.

Technologien, Software und Schnittstellen

Die sich entwickelnde technische Umgebung der HOOU an der TUHH gliedert sich in verschiedene Komponenten, die derzeit in ersten Early-Bird-Projekten evaluiert werden. Zur Veranschaulichung der vorgestellten Strukturen und Softwarelösungen soll Abb. 1 dienen, auf die in den folgenden Abschnitten Bezug genommen wird. Dazu sei gesagt, dass die Grafik die verschiedenen Ansätze in der Umsetzung von Early-Bird-Projekten nicht umfassend abbildet. Kommende Posts in diesem Blog werden über weitere Lösungen berichten.

GitBook

GitBook ist sowohl ein Online-Service als auch eine Sammlung freier Software-Werkzeuge, die für das kollaborative Erarbeiten von Textdokumenten mit linearer Struktur genutzt werden können. GitBook ist dabei nichts anderes als ein einfacher und effektiver Static Site Generator⁸. Neben dem schon erwähnten Skript Python.Processing.Arduino finden sich weitere Beispiele für GitBooks auf der Online-Präsenz des Services.

Markdown: Lingua franca im Netz

GitBooks werden in Markdown geschrieben. Markdown ist eine mittlerweile weit verbreitete Art, Texte auszuzeichnen, Teile also als Überschriften, Aufzählungen oder Hervorhebungen zu kennzeichnen⁹. Einen bildlichen Eindruck des Konzepts vermittelt die Markdown-Dokumentation auf der Webseite von GitBook. Ziel des Schreibens mit Markdown ist es, die Dokumente anschließend in verschiedene Formate zu überführen, in der Regel in HTML. Dies geschieht auch im Prozess der GitBook-Produktion: Hier wird aus mehreren gegliederten Markdown-Dokumenten eine statische HTML-Seite generiert.

Für die OER-Idee ist Markdown sehr hilfreich, da Texte zusätzlich in PDF- und Office-Dokumente umgewandelt werden können. Sogar Präsentationen sind möglich¹⁰. Weil beim Produzieren von Texten mit Markdown noch nicht über das Endformat entschieden wird, kann leicht der Forderung entsprochen werden, OER-Material nicht nur lizenzrechtlich offen, sondern auch technisch einfach bearbeitbar zu distribuieren. Für die Bearbeitung ist lediglich ein Texteditor (Notepad, TextEdit oder der GitBook-Editor) notwendig, der Aufwand für die Qualifikation von Autor_innen ist als gering einzuschätzen. Da Markdown sich im Netz immer mehr verbreitet, lernen Schreibende ein modernes Ausdrucksmittel, mit dem auch an vielen anderen Orten Partizipation in kollaborativen Prozessen möglich wird.

Ein weiterer Vorteil schlägt bei der Nutzung von Markdown zu Buche: Da es sich bei Markdown-Dokumenten um reinen Text handelt, können die Dateien technisch genauso behandelt werden wie solche, die Softwarecode enthalten. Das bringt, wie der Abschnitt zu GitLab zeigen soll, einen großen Vorteil hinsichtlich der Teil- und Wiederverwendbarkeit von OER-Materialien.

Markdown lässt sich problemlos mit HTML-Elementen mischen. Ein Vorteil kann darin gesehen werden, dass externe Medien und Resourcen mithilfe des HTML-Tags iframe an jeder Stelle in das GitBook eingebunden werden können¹¹. Der Nutzen dieser Möglichkeit wird im späteren Abschnitt zur Verzahnung von LA-GitBooks und Discourse deutlich werden.

Zusammenarbeit mit den Early-Bird-Teams

Die Produktion von LA- und Content-GitBooks erfolgt an der TUHH kollaborativ. Early-Bird-Betreuende, WiMis und Lehrende arbeiten zunächst gemeinsam an größeren Markdown-Dokumenten, die in der TUHH-Owncloud geteilt werden. Später werden diese Inhalte in einzelne Dateien nach den Konventionen von GitBook aufgeteilt und kollaborativ weiterentwickelt (vgl. Abb. 1). Wie wird nun aber aus diesen Dateien ein GitBook, das von anderen genutzt, kopiert, bearbeitet und weiterverwendet werden kann? Um diesen Anforderungen zu entsprechen, kommt eine Instanz der Software GitLab zum Einsatz. Ihre Funktionalität und Rolle soll im folgenden genauer erläutert werden.

Kollaboration mit GitHub und GitLab

Die Seite Course in a Box: Create Your Course fordert mit folgendem Satz zum Handeln auf: “Fork this repository on GitHub”. Forken ist hierbei der Kernbegriff des Teilens in der Manier des Services GitHub und bedeutet, die zu einem Projekt gehörenden Dateien von jemandem in den eigenen Account bei GitHub zu kopieren. Damit erlangen Nutzer_innen die Freiheit, mit den Dateien selbst schalten und walten zu können, ohne den Urheber um die Erlaubnis zum Mitmachen fragen zu müssen. Der fork ist hierbei in der Regel kein aggressiver Akt, der den Eintritt in einen Wettbewerb um das bessere Produkt einleitet¹². Vielmehr ist es Usus, dass Verbesserungen und Veränderungen aus dem fork an den Urheber zurückgemeldet werden – mit einem pull request, dem Angebot, die Änderungen in den Ursprung zu integrieren. Geschieht dies, ergibt sich hinsichtlich des OER-Gedankens ein maßgeblicher Unterschied zu Wikis: In dieser Form der Zusammenarbeit sind alle Beteiligten prinzipiell immer vollständige Teilhaber der Daten, die eine Resource konstituieren. Der fork ist beim klassischen datenbankbasierten Wiki nicht ohne Anfrage und Herausgabe der zugehörigen Daten(bank) möglich¹³. Aber dieser Punkt ist nicht der einzige Vorteil hinsichtlich einer maximum forkability. Im Vergleich zum Wiki sind Rekontextualisierungen bei einem fork verhältnismäßig schnell gemacht, besonders wenn es sich bei den Rohdaten um Markdown-Dateien handelt, bspw. in Form eines GitBooks. Diese Änderungen können vom Ändern des Logos der Hochschule hin zur Umstrukturierung, Ergänzung oder Auslassung von Einheiten bis zur Anreicherung mit Medien reichen.

Maximum Forkability mit GitLab

Forken ist auch mit GitLab möglich. GitLab ist eine freie Software, die den proprietären Dienst GitHub nachbaut und den webbasierten Austausch von Dateien nach den Prinzipien des Versionskontrollsystems Git ermöglicht¹⁴. Wollen Hochschulen von Services unabhängig sein, die die Regeln für Nutzung und Umgang mit Daten jederzeit ändern können und ggf. die Daten in ihrer technischen Umgebung einschließen, bieten sich freie Softwarelösungen wie GitLab an, die frei konfigurierbar und erweiterbar sind. GitLab kann auf hochschuleigenen Servern gehostet werden und kommt in der aktuellen Version für die HOOU an der TUHH zum Einsatz.

Teilen lernen mit Git und GitLab

Es gibt bisher wenig Forschungsergebnisse zum Einsatz von Git/GitHub/GitLab in Lehr-Lernzusammenhängen, jedoch ist die Lernkurve allgemein als hoch einzuschätzen (vgl. hierzu Zagalsky, Feliciano, Storey, Zhao & Wang, 2015). Mit meinen Studierenden erprobe ich derzeit semesterbegleitend den Einsatz von GitHub als Kollaborationsplattform in der Lehre, um die Stolpersteine zu identifizieren und mehr über die Einführung dieses vielversprechenden Tools zu lernen.

In Anbetracht der hohen Lernkurve haben wir uns an der TUHH dafür entschieden, die Kolleg_innen an den Schnittstellen zu den Early-Bird-Teams nicht mit einer Qualifikation in Sachen Git/GitLab zu belasten. Wir bitten sie lediglich, ihre Beiträge in Form von Markdown-Dateien in einem geteilten Owncloud-Ordner abzulegen. Die Aufbereitung der GitBooks übernehmen einzelne Kolleg_innen, die neugierig sind auf die Möglichkeiten dieser neuen Form der Kollaboration. Gleichzeitig versuchen wir herauszufinden, wie Git/GitLab für die Produktion und Weiternutzung von OER-Materialien an der TUHH auch für wiss. Mitarbeiter_innen, studentische Hilfskräfte und Lehrende sinnvoll und erlernbar ist.

Kontinuierliche Veröffentlichung von GitBooks

GitLab bringt eine Komponente mit, die automatisierte Tests in der Softwareentwicklung möglich macht (Continuous Integration). Dieses Werkzeug zur Qualitätssicherung wird im Kontext der GitBook-Produktion umgenutzt und sorgt für die automatische Generierung der GitBook-HTML-Seite bei jedem Hochladen (pushen) von Änderungen in GitLab. Das bedeutet, dass der “Quelltext” eines GitBooks immer auf GitLab verfügbar ist, das LA- oder Content-GitBook aber automatisiert an beliebiger Stelle im Netz veröffentlicht werden kann.

Dieses Continuous Deployment bietet nicht nur für die Arbeit mit und an GitBooks einen großen Mehrwert. Auch in Kombination mit anderen Static Site Generators, die Markdown verarbeiten und dann gut aussehende und strukturierte Webseiten bauen, macht der Workflow Sinn. GitBook ist daher nur ein austauschbarer Generator am Ende eines flexiblen technischen Ablaufs.

Einbettung anderer Medien und Tools

Die Einbettung anderer Medien aus dem Web ist in einem HTML-Kontext leicht möglich. Viele Dienste wie Podcampus, Youtube, Twitter u.a. bieten das Integrieren von Inhalten in eigene Zusammenhänge an. Hierbei kommt der iframe, ein altes HTML-Element, zum Einsatz. Der losen Kopplung von Medien und Tools wird damit ganz im Sinne der Remix-Freiheit von OER-Materialien entsprochen. Für die Early-Bird-Projekte an der TUHH werden Diskussionen, die in einem Discourse-Forum stattfinden, per iframe in ein GitBook integriert. So werden Elemente aus der learning community mit dem LA-Gitbook verbunden (vgl. Abb. 1). Auch Videos von Podcampus werden auf diese Weise eingebettet.

GitLab als OER-Repository

Zentral für die Idee der HOOU ist die Bereitstellung aller entstehenden OER-Materialien in einem OER-Repository. Als eine mögliche technische Implementierung wird an der TUHH auch hier GitLab gesehen: Rohdaten und fertige OER-Materialien können über GitLab der Öffentlichkeit zum Herunterladen oder Forken zur Verfügung gestellt werden. Dieser Ansatz soll in den nächsten Arbeitsschritten weiter ausgearbeitet und auf Tauglichkeit geprüft werden.

GitLab verwaltet Projekte, die technisch repositories genannt werden. In jedem repository können beliebig viele Dateien gespeichert werden. Diese sollten textzeilenbasiert sein, wie es bei Programmcode aber auch Markdown-Dateien der Fall ist. Dadurch wird die zuvor beschriebene Kollaboration mittels Git begünstigt. Technisch möglich ist aber auch das Speichern anderer Dateiformate wie z.B. Office-Dokumenten oder Präsentationen, denn auch diese lassen sich von Git/GitLab erfassen und können mit Hinweisen auf Änderungen annotiert werden. Nicht geeignet ist GitLab für das Speichern von Bewegtbildmaterial und nicht empfehlenswert für das Verwalten von Bildern und Grafiken.

Da die Startseite einer GitLab-Instanz sehr technisch erscheint¹⁵, ist denkbar, eine ansprechendere und funktionalere Startseite mit Suchfunktion vorzuschalten. Die öffentliche Schnittstelle (API) von GitLab erlaubt eine angepasste Aufbereitung der gespeicherten Daten.

Sandstorm als Weiterbildungsinstrument

Wie aktuelle Studien zeigen, sind längst nicht alle Studierenden so versiert im Umgang mit modernen Webapplikationen, wie ihnen immer unterstellt wird¹⁶. Gleiches mag zu Teilen auch für Lehrende und andere Kolleg_innen an Hochschulen gelten, weshalb hier Informations- und Weiterbildungsbedarf angenommen werden kann. Im Rahmen der Early-Bird-Betreuung an der TUHH ist festzustellen, dass es gut ist, alle Beteiligten zunächst über die Möglichkeiten und Potenziale aktueller Werkzeuge zu informieren¹⁷, um sie für den Prozess der gemeinsamen Entwicklung eines überzeugenden Lernarrangements zu gewinnen.

Die Software Sandstorm leistet in dieser Hinsicht einen guten Dienst, da sie über fünfzig freie Softwaretools unter einem Zugang versammelt und es Lehrenden wie Lernenden möglich macht, ihre eigene mediale Lernumgebung zu bauen. Im Zuge der Evaluation von mediengestützten Lernformen für die HOOU wird Sandstorm in unterschiedlichen Kontexten experimentell eingesetzt, um das Potenzial für Lehre und Weiterbildung zu ermitteln (vgl. Knutzen & Howe, 2013). Über die Funktionsweise und Möglichkeiten hatte ich an anderer Stelle schon geschrieben.

Zusammenfassung

Die Impulse, die die Hamburg Open Online University in der Auseinandersetzung mit den Themen Digitalisierung, Offenheit und Hochschuldidaktik an der TUHH gesetzt hat, sind groß. Ein Ansatz für die technische Umsetzung von HOOU-Lernarrangements an der TUHH wurde in diesem Artikel vorgestellt, wobei Bezug genommen wurde auf die Prinzipien der Open-Education-Bewegung und die damit einhergehenden Implikationen hinsichtlich Technik und Didaktik.

Literatur

• Kerres, M. (2012). Mediendidaktik: Konzeption und Entwicklung mediengestützter Lernangebote. München: Oldenbourg.
• Knutzen, S. & Howe, F. (2013). Digitale Medien in der gewerblich-technischen Berufsausbildung – Einsatzmöglichkeiten digitaler Medien in Lern- und Arbeitsaufgaben. foraus.de/BIBB. Zugriff am 17.12.2013. Verfügbar unter: http://datenreport.bibb.de/media2013/expertise_howe-knutzen.pdf
• Reinmann, G. (2010). Studientext Didaktisches Design. Studientext, Universität der Bundeswehr, München. Zugriff am 8.5.2015. Verfügbar unter: http://gabi-reinmann.de/wp-content/uploads/2010/04/Studientext_DD_April10.pdf
• Tkacz, N. (2015). Wikipedia and the Politics of Openness. Chicago; London: University of Chicago Press.
• Wild, E. & Möller, J. (Hrsg.). (2015). Pädagogische Psychologie (Springer-Lehrbuch). Berlin, Heidelberg: Springer Berlin Heidelberg. Zugriff am 27.4.2016. Verfügbar unter: http://link.springer.com/10.1007/978-3-642-41291-2
• Zagalsky, A., Feliciano, J., Storey, M.-A., Zhao, Y. & Wang, W. (2015). The Emergence of GitHub as a Collaborative Platform for Education (S. 1906–1917). ACM Press. doi:10.1145/2675133.2675284

Fotocredits: “Karelia” von Petr Magera@flickr, CC-BY

“Entwicklung einer offenen technischen Infrastruktur für HOOU-Lernarrangements an der TUHH” von Axel Dürkop ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

Was wäre, wenn ein OER bzw. eine Open Educational Resource ein Lebewesen wäre?

Benennung und Einordnung

In diesem Fall, muss es erst einmal mit einem lateinischen Namen benannt werden:

Materia aperta eruditionis (kurz MAE)

Übersetzung:

• wortwörtlich:
  • Materia = Grundstoff
  • aperta = offen
  • eruditionis = bildend
• etwas freier: freiverfügbare Bildungsressource

Die Einordung im Sinne der klassischen evolutionären Klassifikation [2] sieht dann wie folgt aus:

• Reich: Ressourcen
  • Stamm: bildende Ressourcen bzw. Bildungsressourcen
    • Klasse: ..
    • Klasse: freiverfügbare Bildungsressourcen (MAE)
      • Ordnung: analoge
      • Ordnung: digitale
        • Familie: Videos
          • Gattung: Xvid
          • ..
        • Familie: Audios
          • Gattung: Ogg-Vorbis
          • ..
        • Familie: Fragebögen
        • ..

d.h. das MAE gehört zum Reich der Ressourcen und zum Stamm der Bildungsressourcen. Es bildet hier neben anderen eine eigene Klasse: die freiverfügbaren Bildungsressourcen und spaltet sich in zwei Ordnungen auf: die analogen MAEs und die digitalen MAEs.

Die Ordnung der digitalen MAEs fächert sich wiederum in viele verschiedene Familien auf: z.B. Videos, Audios, Bilder, Texte und auch komplexere Dinge wie z.B. Arbeitsblätter, Fragebögen, Tests. In einer speziellen Familie finden sich dann je nach Familie unterschiedliche Gattungen.

Darüber hinaus ist festzustellen, dass die Menge der digitalen MAEs schon recht umfangreich ist und dass die Anzahl der digitalen MAEs sich auch täglich vergrößert. Im Gegensatz dazu ist die Menge an analogen MAEs recht klein und nimmt besorgniserregend ab. Vielleicht sollten sie auf die Rote Liste [3] der vom aussterben bedrohten Arten gesetzt werden.

Reifung

Wie beim Menschen braucht es zur Geburt eines MAE Eltern, in diesem Fall aber nicht andere MAEs sondern Menschen. Und im Unterschied zum Menschen, der ja zwei Elternteile braucht, kann ein MAE von einem, zweien oder auch mehreren Menschen gezeugt werden. Bei MAEs spricht man aber eher von erzeugen und die Erzeuger heißen nicht Eltern sondern Autoren.

Nach der Geburt durchläuft ein MAE in der Regel eine Phase der Reifung. Diese drückt sich nicht wie beim Menschen in Jahren, sondern in Versionen aus. Am Anfang entwickelt sich das MAE meist schnell, es entstehen in einem kurzen Zeitraum mehrere Versionen. Verlängert sich die Zeit zwischen den entstehenden Versionen, so schreitet die Reifung voran. Entstehen keine neuen Versionen mehr oder nur noch sehr selten, so ist das MAE erwachsen. D.h. an den Zeiten zwischen den Versionen ist der Reifegrad eines MAEs zu erkennen.

Ist das MAE erwachsen, entlassen es seine Eltern (Autoren) in die freie Wildbahn, d.h. in das Ökosystem der Bildungsnetzwerke. Dabei entwickelt sich das MAE immer noch weiter, aber weniger im Inhalt. Während der Reifung hat ein MAE ein extrem leistungsfähiges Gedächtnis entwickelt. Alles was es im Laufe seines Lebens erlebt, wird gespeichert und nicht vergessen. Hierbei speichert das MAE seine Erlebnisse nicht in einem Gehirn, so wie wir Menschen, sondern in einem Bereich, der sich Metadaten nennt.

Diese Metadaten sind bei der Abnabelung von den Eltern nicht leer, sie sind schon mit gewissen Attributen über sein Äußeres (u.a. Höhe, Länge, Breite, Gewicht – meist in Kilobyte gemessen) und auch über sein Inneres (also dem Inhalt) gefüllt. Im Laufe seines Lebens ergänzt das MAE seine Metadaten durch weitere Daten, z.B.:

• Wie habe ich Menschen gefallen?
• Was haben Menschen über mich gesagt?
• Wo haben Menschen mich gesehen?
• Wohin haben mich Menschen genommen?
• Mit welchen anderen MAEs haben mich Menschen zusammengetan?

Beziehungen

An den Ergänzungen wird deutlich: so ein MAE hat im Ökosystem der Bildungsnetzwerke viel zu tun. Es ist unglaublich, wie voll der Terminkalender eines MAEs sein kann. Quasi in Sekundenbruchteilen kann es mal in einem Moodle-Kurs in der Schweiz, auf einem Wiki in England, in einem OLAT-Kurs in Deutschland und dann wieder auf einem WordPress-Blog in Österreich sein. Bemerkenswert.

Wie schon erwähnt, merkt sich ein MAE, wo und vor allen Dingen mit welchen anderen MAEs es zusammen gewesen war. Und da MAEs extrem kontaktfreudig und offen gegenüber anderen MAEs sind, entstehen Freundschaftsbeziehungen. Je öfter sich MAEs begegneten, desto inniger, fester und enger werden die Beziehung bzw. Verknüpfung zwischen den MAEs. So entsteht übrigens ein Netz aus MAEs und unsere These ist, dass alle MAEs mit allen MAEs „über mehrere Ecken“ verbunden sind.

Netz von MAEs – Laborbedingungen, nicht freie Wildbahn (Jan 2016)

Wird das Netz als Ganzes betrachtet, so ist zu konstatieren, dass auch das Netz in ständiger Bewegung ist. Ständig entstehen neue Verknüpfungen zwischen MAEs und durch das Netz laufen regelrecht Wellen, wenn neue MAEs zum Ökosystem der Bildungsnetzwerke hinzukommen. Das Netz ist in einem ständigen Wandel, so dass das Netz selbst als lebendig, vielleicht sogar als ein Lebewesen erscheint. Haben wir es hier mit einer Schwarmintelligenz zu tun? Ein intelligenter Schwarm aus MAEs?

Nein, denn die Ursache für die Bewegung im Netz liegt bei uns Menschen. Als Eltern bzw. Autoren führen wir dem Ökosystem, d.h. dem Netz neue MAEs hinzu. Insbesondere auch als Nutzende, wenn wir MAEs suchen, anschauen, gruppieren, kombinieren, an neuen Orten – d.h. thematischen Kontexten – neu arrangieren, speichern dies die MAEs in ihrem Gedächtnis / in ihren Metadaten und so entstehen die neuen Verbindungen.

Aber nicht nur das. Indem viele Menschen immer wieder den gleichen Verbindungen von einem MAE zum nächsten MAE folgen, entstehen Wege im Netz der MAEs. D.h. wir Menschen erzeugen nicht nur MAEs, sondern wir erzeugen auch durch unsere Nutzung unbewusst Pfade im Netz der MAEs. Wobei wir diese Pfade auch bewusst erzeugen können, d.h. vergegenständlichen, so dass diese Wege präsentiert und weitergegeben werden können.

Navigation

Diese Wege verknüpft mit abstrakteren Dingen der Bildungslandschaft, wie z.B.:

• Forschungsfragen
• Bildungsbedürfnissen
• Wissenslücken
• Curricula an Hochschulen
• Lehrplänen an Schulen herausgegeben von Schulministerien / -behörden

bieten uns Menschen Struktur, Halt und Anregung, uns in dem Netz von MAEs zurecht zu finden bzw. zu bewegen. D.h. diese abstrakteren Strukturen werden quasi zu einem Navigationsgerät der Bildung: “Beim nächsten MAE haben Sie Ihr Bildungsziel erreicht.” Wir haben aber zu jederzeit die Macht, der freundliche Stimme aus dem Bildungsnavigator nicht zu folgen, und links oder rechts mal abzubiegen. Warum auch nicht, im Netz der MAEs gibt es so viel zu entdecken.

OERde16 – Fachforum

Keine Lust zu lesen? Dann hören und schauen Sie mir auf dem OERde16 – Fachforum (01.03.2016) zu.

Start: ca. 3:16:00 – Ende: ca. 3:26:00

Begriffserklärungen / Quellen

[1] https://de.wikipedia.org/wiki/Gedankenexperiment

[2] https://de.wikipedia.org/wiki/Systematik_(Biologie)

[3] http://www.bfn.de/0322_rote_liste.html

Lizenz

Das lebende OER von Dr. Iver Jackewitz ist – mit Ausnahme des YouTube-Videos – lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

… für die Hamburg Open Online University sitzt an der TUHH und wird durch die Dipl. Kommunikationsdesignerin Dorothee Schielein vertreten. In Absprache mit allen sechs Hochschulen, dem UKE, dem MMKH, der interdisziplinären Entwicklergruppe (Technik- und Konzeption), sowie der Operativen Koordination durch Tina Ladwig (TUHH), Christina Schwalbe (UHH), Iver Jackewitz (UHH) und Patrick Peters (MMKH) wird das Erscheinungsbild der HOOU entwickelt.

Die Entstehung der Hamburg Open Online University ist für alle Hochschulen ein prozesshafter Vorgang mit vielen Akteuren und unterschiedlichsten Vorstellungen. Im Gegensatz zu einem herkömmlichen graphischen Prozess verändern sich die Anforderungen für die HOOU kontinuierlich (z. B. die Zielgruppe oder die Produkte für die Öffentlichkeitsarbeit der HOOU). Zudem sind die graphischen Entscheidungen langwierig, da das Mitspracherecht aller Hochschulen entscheidend sind, um das passende “Kleid” zu finden. Für das Kommunikationsdesign bedeutet dies eine besondere Herausforderung, da immer wieder agile, graphische Lösungen gefunden werden müssen, um die HOOU im Prozess mit seinen Zwischenergebnissen sichtbar zu machen.

In diesem Beitrag möchte ich die Prozesse des agilen, visuellen Designs dokumentieren und transparent machen.

Dezember 2014 /// HOOU Logo: Ohne zu wissen was die HOOU ist oder was sie einmal sein wird, fiel es mir schwer das passende Logo zu entwerfen. Deshalb habe ich recht pragmatisch mit dem vollständigen Namen der HOOU, in Kombination mit dem Hamburg-Logo eine Wort-Bild Marke geschaffen, die als Übergangslogo gedacht ist. Die Farben sollten zum Hamburg Logo passen und das Gold als Highlight-Farbe die Wertigkeit abbilden.

Januar 2015 /// Präsentation beim Ersten Bürgermeister von Hamburg Olaf Scholz:  Ziel war es, durch anregende Infografiken und Illustrationen die Ideen der HOOU vorzustellen. Da die Zeit knapp war, musste leider ohne intensiven Abstimmungsprozess aller Hochschulen die Präsentation gestaltet werden. Die Farbigkeit entstand aus dem kurz vorher entworfenen Logo. Um einen inhaltlichen Kontrast zum Logo zu schaffen, entschied ich mich für die Texte eine weitere Schrift zu verwenden (“ITC Officina Serif” und “TC Officina Sans Serif”). Die Lizenzen sind jedoch ausschliesslich für Printprodukte und interne Kommunikation, deshalb habe ich mich bei späteren Präsentationsfolien und dem Blog für die “Roboto serif” entschieden, da sie als Open Source Typo von Google zur Verfügung steht. (Beispiele aus der Präsentation:)

April 2015 /// Auftaktveranstaltung (TUHH): Für die Auftaktveranstaltung entstanden neue Anforderungen. Plakate und Flyer sollten die hochschulinternen Interessierten aus Professorenschaft, Mittelbau, Verwaltung und vor allem auch die Studierenden einladen, dem Startschuss der HOOU@TUHH beizuwohnen. Das Design entstand insbesondere in Absprache mit den TUHH-Mitarbeitern und unter Berücksichtigung der vielfältigen hochschulübergreifenden Inhalte. Hier die Beispiele des Flyer:

Mai 2015 /// Onepager: Eine einfache und schnelle Online Lösung, basierend auf den Inhalten des Flyers, war dringend nötig. Sie diente als Vorläufer für diesen Blog.

Juni 2015 /// Hilfsmittel zur Erstellung von HOOU-Projekten: In Absprache mit den Didaktiker_innen wurde ein “Konzeptpapier” entwickelt, welches den “Early Birds” (so nennen wir die Projekte in der Vorprojektphase der HOOU) helfen soll, Ihre Vorhaben im Rahmen der HOOU umzusetzen. Dieses nutzen alle Hochschulen für die prozessbegleitende Projektbetreuung.

August 2015 /// Halbzeitkonferenz des Hochschulforum Digitalisierung in Berlin: Zum ersten Mal waren alle Hochschulen aufgefordert inhaltlich an einem gemeinsamen Plakat zu arbeiten, dieses zu entwickeln und als Team zu präsentieren. Das hat gut geklappt. Da die Inhalte nun zunehmend konkreter werden, entschied ich mich die  Gestaltung etwas zurück zu nehmen. Es entstanden DIN A0 Plakate mit helleren Farben und zarterer Typo damit die Inhalte deutlicher in den Vordergrund treten.

August 2015 /// Medienproduktion:

Für jedes Projekt der HOOU wurde eine Video produziert, dass die Motivation und Idee des Projektes wiederspiegelt. Um die Videos einheitlich zu gestalten war ein 5 Sekunden “Opener” nötig. Einerseits sollten die Hochschulen mit ihren Logos vertreten sein, andererseits musste ein Sound Design komponiert werden. Neben dem Opener sind die Zwischentitel und Bauchbinden entstanden.
Hier das Beispiel des Projektes von Prof. Dr. Kuchta:

Die Logovariante hoou.de ist entstanden, da das bisherige HOOU Logo für die Medienproduktion zu kleinteilig ist:

September/Oktober 2015 /// Mock-Up für die Präsentation beim Ersten Bürgermeister Olaf Scholz am 23. September 2015:

Dieser Schulterblick bei Olaf Scholz war u.a. ein gestalterischer Blick auf das zukünftige Design und Konzept der HOOU. Das besonderes dieses Layouts ist weniger die Gestaltung als vielmehr die Idee, dass die “Teams” als eigene Qualität für das Lernen abgebildet wurde. Ein weiterer Punkt ist die Zusammführung von aktuellen Themen. Das Layout basiert auf den bisherigen Standards, die sicher noch verändern werden (müssen), da wir uns inhaltlich noch immer in der Anfangsphase befinden.

November 2015 /// Flyer für die Campus Innovation 2015: Unser Blog ist Online! www.hoou.de Dass mussten wir natürlich in Form eines Flyers öffentlich machen. Das Layout ist angelehnt an die Plakate:

Und Sie?

Haben Sie Anregungen zum Kommunikationsdesign? Kennen Sie Layouts die wir unbedingt sehen sollten? Wir freuen uns über Ihre Kommentare!

Zu Beginn stand hier schon die Frage, wie die Kultur und die Lebenswelt einer technischen Universität zum Selbstbild einer Kunsthochschule passen. Im Rahmen unserer intensiven Zusammenarbeit hat sich nun herausgestellt: Sie passen hervorragend zusammen.

Partizipativer Workshop an der HFBK. Lehrende, Studierende, IT, Öffentlichkeitsarbeit und Hochschulleitung erarbeiten erste Konzepte für Inhalt und technische Umsetzung

Im Moment sind wir an dem Punkt, das Konzept des Early-Bird Projektes Critic’s Picks an der HFBK konzeptionell und technisch detaillierter auszuarbeiten. Unter Verwendung freier und quelloffener Software entwickeln wir gemeinsam erste Lösungen für die Umsetzung des Projekts, wobei wir die vielfältigen Anforderungen der beteiligten Gruppen berücksichtigen. Lehrende, Studierende, Hochschulverwaltung und Menschen außerhalb der Hochschulen sollen sich an Critic’s Picks beteiligen können.

Im nächsten Schritt wird eine Testumgebung für die webbasierte Kollaboration von Lehrenden und Studierenden der HFBK evaluiert. Anschließend soll das Setting für Interessierte außerhalb der Hochschule geöffnet werden. Wir halten Sie auf dem Laufenden!

Projektverantwortliche aus den Hochschulen

Axel Dürkop und Tina Ladwig für die TUHH, Beate Anspach für die HFBK

Und jetzt kommen Sie!

Welche Inhalte würden Sie sich von dem Projekt wünschen und über welchen (mediengestützten) Weg könnten Sie sich vorstellen, in diesem Projekt mitzumachen?
Wir freuen uns auf Ihre Kommentare!