Bei der Planung und Realisierung einer PLE sind Entscheidungen zu treffen, die den Anforderungen der zukünftigen Nutzenden und den Rahmenbedingungen der Hochschule entsprechen müssen. Diese Entscheidungen betreffen Einzelfragen, wie zum Beispiel das Rechte‐ und Rollenmodell, Szenarien und Werkzeuge für die didaktische Gestaltung, Schnittstellen zu externen Anwendungen und vieles mehr. Die hier getroffenen Einzelentscheidungen haben in ihrer Summe maßgeblichen Einfluss auf den Charakter der entstehenden PLE. Die Entscheidungsfragen lassen sich (angelehnt an die oben genannten sieben Kernfragen) in sechs Bereiche einordnen, die sich als Konkretisierung der theoretischen Fragestellungen für das vorliegende Projekt auffassen lassen. Diese Entscheidungsfelder sind:

Aus den möglichen Ausprägungen dieser Gestaltungsfelder lässt sich ein Fingerabdruck für eine spezifische PLE erstellen (Buchem et al. 2011). Diese Darstellungsweise hat den Vorteil, dass die Ausprägung der verschiedenen Faktoren in einem gut erfassbaren Profil visualisiert werden können, was die Darstellung und Vergleichbarkeit verschiedener PLE‐Realisierungen erleichtern würde. Eine weitere Ausführung dieses Darstellungskonzepts übersteigt jedoch den Rahmen der vorliegenden Arbeit.

Ergänzend zu den Designentscheidungen auf dem Weg zu einer Personal Learning Environment wurde eine weitergehende Anforderungserhebung in Form von sogenannten User Stories durchgeführt, deren Ergebnis als Grundlage für die detailliertere Ausgestaltung der PLE genutzt wurde. Hierbei konnte jeder Universitätsangehörige über ein Online‐Formular seine Wünsche in Form von semi‐strukturierten Anforderungen (Hilse & Lucke 2013) eintragen. Eine Anforderung umfasste jeweils eine Rolle, eine Beschreibung und entsprechende Bedingungen, deren Erfüllung für eine zufriedenstellende Umsetzung aus Sicht des Eintragenden unerlässlich ist. Eine Beispielanforderung sieht wie folgt aus:

Abbildung 1 - Nutzerorientierte Beispielanforderung für ein persönliches Archiv

Insgesamt konnten bislang ca. 200 Anforderungen aus der Breite der Hochschule gesammelt werden. Diese Anforderungen wurden anschließend gesichtet und kategorisiert mit dem Ziel, weitere Beiträge zur Spezifikation einer softwaretechnischen Lösung ableiten zu können. So erwiesen sich einige Anforderungen als basale Voraussetzungen für die Schaffung einer Personal Learning Environment, sodass unmittelbar nach der Erhebung und Auswertung sich abzeichnende längerfristige Vorarbeiten angegangen werden konnten. Hierzu gehörten die Beschaffung, Installation, Inbetriebnahme oder Weiterentwicklung von existierenden und für die PLE notwendigen Systemen. Einige der Anforderungen führten zur späteren Inbetriebnahme von Kerndiensten, wie der Wunsch nach einer Medienplattform zur nutzerzentrierten Publikation von Video und Audio, nach einem hochschulinternen System zum Tausch und Ablage von Dateien oder nach einem Werkzeug zum kollaborativen Editieren von Textdokumenten. Hinzu kamen vielfältige andere Gedanken zur Vereinfachung von Studium und Lehre an der Universität Potsdam, die bei der Erweiterung von Diensten oder der Abbildung systemübergreifender Prozesse (vgl. Abschnitt 3.4) berücksichtigt wurden. Die Anforderungen spiegeln nicht zuletzt den sich wechselnden Zeitgeist und den voranschreitenden Wunsch vieler Akteure nach einer zunehmenden Digitalisierung der Hochschule wider. Mit den User‐Stories konnten zahlreiche Anwendungen identifiziert werden, deren Einbettung oder Bereitstellung in einer Personal Learning Environment unerlässlich sind. Diese Dienste werden im Folgenden auch als Kerndienste bezeichnet. Bei den Kerndiensten handelt es sich vornehmlich um heute bereits zentral nutzbare Dienste (z.B. die Lernplattform oder der E‐Mail‐Dienst) oder aber um Systeme, die z.T. im Rahmen des Projekts erst eingeführt wurden (z.B. Web‐Speicherdienst oder Videoplattform).

Für die Konzeption und Entwicklung von elektronisch unterstützen Lehr‐/Lernarrangements hat sich die Entwicklung von praxisorientierten Anwendungsszenarien bewährt. In Szenarien werden didaktische Elemente (wie Lerninhalte oder Lehr‐ und Lernaktivitäten) sowie deren medientechnische Umsetzung in einem konkreten Zusammenhang beschrieben. Ein Szenario kann sich auf eine bestimmte Lehrveranstaltung (z.B. eine Vorlesung, ein Praxissemester), auf einen Lernzusammenhang (z.B. eine Projektgruppe, ein Lerntandem) oder eine bestimmte Methodik (z.B. Portfolioarbeit, Unterrichtsbeobachtung) beziehen. Für die Entwicklung der PLE wurden ausgehend von den mediendidaktischen Beratungs‐ und Schulungsangeboten der Hochschule fünf Szenarien ausgewählt, die häufig auftretende Anwendungsfälle einer PLE im Kontext der Hochschule abbilden. Ziel der Szenarienerstellung ist es, jeweils einen Ausgangspunkt als Template und Testfall für spezifische Anwendungsmöglichkeiten zur Verfügung zu stellen. Die Templates bleiben jedoch für den Benutzenden anpass‐ und erweiterbar. In den Szenarien finden sich sowohl studiengangs‐ und lehrveranstaltungsspezifische Anforderungen als auch offene Anwendungsmöglichkeiten wieder. Die Szenarien wurden jeweils in Teams entwickelt und als Seiten‐Templates in dem Portal „Liferay“ prototypisch umgesetzt. Die Szenarien sind:

Der Prozess der Erstellung und gemeinsamen Diskussion der Szenarien führt einerseits zur Konkretisierung von Entwicklungsaufgaben und hilft technische Desiderate zu identifizieren (z.B. in der Rollenmodellierung). Andererseits führt dieser Prozess zu einer Verdichtung des gemeinsamen Verständnisses und somit zu einer Konsolidierung der zukünftigen Arbeit über die Fachdisziplinen hinweg. So hat sich in dieser Phase gezeigt, dass es für die kommenden Arbeitsschritte äußerst hilfreich ist ein Glossar anzulegen, in dem die wichtigsten Begriffe und Funktionen rund um die PLE gesammelt werden. Die so entstehende Wissenssammlung stellt eine Grundlage für die weitere Entwicklungsarbeit, aber auch für die kommende Einführung von neuen Nutzenden dar.

Zur Realisierung der vorgestellten Szenarien werden Funktionen vieler verschiedener Dienste benötigt. Für die Ausgestaltung der Szenarien wurden die Funktionen zunächst losgelöst vom jeweiligen Dienst oder Werkzeug formuliert und, sofern noch nicht vorhanden, als Platzhalter in das entsprechende Szenario eingefügt. Hierbei können einzelne Funktionen in mehreren Szenarien zeitgleich zum Einsatz kommen, unterscheiden sich jedoch hinsichtlich des jeweiligen Nutzungskontexts (z.B. Daten, Rechteinhaber oder Zugriffsbeschränkungen) und sind abhängig vom mediendidaktischen Ziel der Erstellenden. So kann die Funktion des „Microblogs“ zum einen im Persönlichen Profil als „Postwall“ oder aber auch im Szenario der Gruppenarbeit als „Schwarzes Brett“ genutzt werden. Dies soll exemplarisch für das Szenario „Gruppenarbeit“ aufgezeigt werden. Hier wurden verschiedene Funktionen genutzt und auf den folgenden vier Seiten gruppiert:

Jede dieser Seiten besitzt eigene Funktionen. So können sich die Nutzenden des Szenarios auf der Startseite über aktuelle Ankündigungen, die letzten Aktivitäten oder allgemeine Informationen zur Gruppe informieren und haben zugleich eine Möglichkeit zur Mitgliederverwaltung‐ und Mitgliederübersicht um schnell weitere Personen einzuladen. Die Seite Gemeinsam Arbeiten beinhaltet einem Seitenchat für den gruppeninternen Austausch, und ein kollaborativer Editor ermöglicht die schnelle Sammlung von Informationen für alle Gruppenmitglieder. Diese Seite besitzt weiterhin drei Unterseiten: einen Blog, eine Mindmap und ein Wiki. Auf der Seite Dokumente & Ressourcen finden die Nutzenden eine Verknüpfung zum hochschulinternen Web‐Speicherdienst und dem jeweiligen Gruppenordner sowie eine Möglichkeit zur Linkverwaltung. Auf der vierten Seite Organisatorisches befindet sich schließlich ein Kalender, eine Aufgabenliste und eine Möglichkeit zur Gestaltung von Umfragen.

Für alle in den Szenarien genutzten Funktionen wurden anschließend die in Frage kommenden Kerndienste identifiziert, also welcher Dienst für die Bereitstellung der einen oder anderen Funktion innerhalb des Szenarios bzw. in der PLE in Frage kommt. Um dies beurteilen zu können, wurden die Dienste hinsichtlich ihrer vorhandenen Funktionalitäten respektive Erweiterungsmöglichkeiten für die Verwendung in den Szenarien analysiert. Alle Dienste besitzen ihre jeweiligen Stärken und Schwächen im spezifischen Funktionsumfang. Aus strategischen Gesichtspunkten wurden auch einige Funktionen gezielt deaktiviert, da sich diese mit Funktionen anderer Dienste doppelten oder sich der Funktionsumfang bzw. die Handhabung für den späteren Nutzenden als Einschränkung herausstellte. Besonders essentielle Systeme haben sich als „führende Systeme“ für dedizierte Funktionen herauskristallisiert, die nicht (oder zumindest nicht mit vertretbarem Aufwand) ersetzbar sind und sich auf die Bereitstellung bestimmter Funktionen spezialisiert haben (z.B. E‐Mail‐Server, Kalenderdienste). Hierzu gehören u.a. die Datei‐ und Medienverwaltung, das Campus-Management-System oder das zentrale Learning Management System (Moodle).

Auch wenn die PLE den späteren Einstiegspunkt in die Dienste der Hochschule bildet, so können die Dienste dennoch unabhängig davon weiter genutzt werden. Dabei kann es zu Funktionsdoppelungen kommen, die kontextspezifisch auch sinnvoll sind. So besitzt das Campus-Management-System zentrale Termine, in Moodle finden sich kursbezogene Termine und in der PLE finden sich schließlich private und Arbeitsgruppen‐Termine. Dieser Sachverhalt wird bei den verschiedenen Integrationsansätzen berücksichtigt (vgl. Abschnitt 4.2). Für einige Funktionen muss somit eine dienstübergreifende Synchronisation oder Akkumulation der Informationen in der PLE stattfinden. Zunächst konnten für die Universität Potsdam die folgenden Kerndienste identifiziert werden, die wiederum als führende Systeme für bestimmte Funktionen in den Szenarien auftauchen:

Die folgende Abbildung 2 zeigt die zur Verfügung stehenden Kerndienste und die zugehörigen – als relevant erachteten – Funktionen. Sofern eine Funktion eines Kerndienstes in irgendeiner Form in der PLE berücksichtigt wird, taucht deren Nummer jeweils bei der Funktion auf. Die „führenden Dienste“ für eine Funktion sind auf der linken Seite dargestellt. Auf der rechten Seite der Abbildung ist die jeweilige Funktionszugehörigkeit zu den erwähnten Szenarien ersichtlich. Hinzu kommen Szenarien‐übergreifende Funktionen, die für die Zusammenarbeit der PLE und der Dienste notwendig sind. Hierzu gehören ein übergreifendes und übertragbares Gruppen‐ und Rollenkonzepte für alle Anwendungen, ein zentrales Identity Management zur Pflege von Kontakten und die Anmeldung bei den Diensten mittels Single‐Sign‐On.

Abbildung 2 ‐ Kerndienste und Funktionen der Szenarien

Für die Entwicklung elektronischer Lernumgebungen können verschiedene Vorgehensmodelle herangezogen werden. Im vorliegenden Projekt wurden Konzepte des Didaktischen Designs, des General System Designs und Prinzipien der Designentwicklung kombiniert. Mit „Didaktischem Design“ wird die systematische und schrittweise Konzeption und Umsetzung von Lehr‐/Lernszenarien beschrieben. Es basiert unter anderem auf pädagogischen Grundannahmen hinsichtlich der lernförderlichen Strukturierung und Sequenzierung von Lerninhalten und Lernaktivitäten (Kerres 2005; Reinmann 2011; Reinmann 2013). Ein Nachteil des Didaktischen-Design‐Ansatzes ist jedoch, dass hier in der Regel von der Gestaltung einer Maßnahme oder eines Lehr¬/Lernszenarios ausgegangen wird und generelle Planungs‐ und Implementationsprozesse eine untergeordnete Rolle spielen (Reinmann 2013). Wünschenswert für die Entwicklung einer PLE ist allerdings eine mehr generelle Sichtweise auf Planungs‐ und Implementationsprozesse im Sinne einer „vorausschauenden Koordination“, die unterschiedliche Zeithorizonte (kurz‐, mittel‐ und langfristig) und Handlungsebenen (Globalplanung und Detailplanung) einschließt (Seel 1999). Issing (2002) lenkt in diesem Zusammenhang den Blick auf das abstraktere General System Design (GSD) und stellt die vier Grundkomponenten „Analyse, Planung, Entwicklung und Einsatz“ vor, wobei alle Elemente mit Evaluation und Revision verknüpft sind. Aus dem GSD‐Modell hat sich das ADDIE‐Modell entwickelt, in dem die fünf Schritte „Analysis, Design, Development, Implementation and Evaluation“ als übergeordnete, stark generalisierte Handlungsstruktur Eingang gefunden haben (Zierer & Seel 2012). Die abstrakte Form des ADDIE‐Modells macht es als Ausgangspunkt für Entwicklungsaufgaben gut handhabbar, es muss jedoch mit den konkreten Vorgehensweisen für die Umsetzung im Sinne des Didaktischen Designs angereichert und aus der sequentiellen in eine stärker zyklisch und formativ orientierte Struktur umgesetzt werden. Für die zuletzt genannte Anforderung an Entwicklungsprozesse sind Ansätze der Designentwicklung besonders geeignet. Die Designentwicklung (Allert & Richter 2011) fasst den Zusammenhang von Gestaltung, Produkt und Nutzung als einen Prozess auf, in dem sich das Produkt erst in der Nutzung konkretisiert. Gestaltende geben demzufolge Nutzungsmöglichkeiten vor, die erst durch die Praxis der Nutzenden zum letztlichen Produkt „ausgehandelt“ werden. Dieser Ansatz entspricht in mancher Hinsicht den alltäglichen Erfahrungen in der Entwicklung von digitalen Lehr‐/Lernumgebungen und kann helfen, das Paradoxon bei der Anforderungserhebung in komplexen Softwareprojekten aufzulösen, das auftritt, wenn Nutzende ihre Anforderungen an ein zukünftiges System beschreiben sollen und dass Boehm (1988) so beschreibt: „I can't tell you what I want, but I'll know it when I see it.“ Designentwicklung kann im vorliegenden Zusammenhang vor allem für die Entwicklungsphasen von konkreten (Teil‐)Anwendungen nutzbar gemacht werden. Das von uns entwickelte Prozessmodell lässt sich als eine Kombination aus den vorgestellten Ansätzen beschreiben:

Das Prozessmodell kann grob in fünf Phasen unterteilt werden, die sukzessiv und zyklisch repetierend durchlaufen werden. Im Folgenden werden die fünf Phasen detailliert beschrieben (vgl. Abbildung 3).

Abbildung 3 ‐ Prozess zur Entwicklung einer elektronischen Lernumgebung am Beispiel der PLE

Phase I – Akkumulation und Konsolidierung der Einzelperspektiven

In der ersten Phase wird sich mit allen Projektbeteiligten ein Überblick zu den gewünschten Funktionen verschafft, die für die Realisierung der jeweiligen Lehr‐/Lernszenarios essentiell sind. Zur Identifikation der Grundfunktionen und des spezifischen intendierten Lehr‐/Lernszenarios eignen sich diverse Methoden der Kreativitätstechnik, die in Abstimmung mit den Akteuren auszuwählen sind. Das entsprechende Arbeitsergebnis wird fixiert und fortan als ständige Diskussions‐ und Austauschgrundlage für spätere Iterationen und Arbeitsphasen genutzt.

Phase II – Die softwaretechnische Anforderungserhebung

Eine wichtige Trennung zwischen Phase I (i.d.R. nicht standardisierte grafische und textuelle Beschreibung) und Phase II (eine vielmehr formalisierte Modellierung in einer standardisierten Notation) ist die Verringerung des Interpretationsspielraums der Beschreibung, sodass Eindeutigkeit für die spätere Implementierung geschaffen wird. Hierbei wird von der in Phase I erstellten Überblicksskizze ausgegangen, um die elementaren Kernfunktionen (aufgeschlüsselt nach den vorhandenen Rollen) auf einen verallgemeinerbaren Nenner mit allen Projektbeteiligten zu bringen. Das Festhalten von Anforderungen in Phase II dient weiterhin der Zieldefinition eines Entwicklungsprojekts, zur Herausbildung eines ersten gemeinsamen Begriffsverständnisses und zur Konsolidierung eines Konsens‘ über den Funktionsumfang.

Phase III – Anforderungserhebung als Konkretisierung der Teilfunktionen

In der dritten Phase werden gesammelten Anforderungen erneut konkretisiert. Hierbei werden die erhobenen Teilkomponenten differenziert und Teilfunktionen, Rechte & Rollen, technischen Grenzen und Herausforderungen näher spezifiziert. Hierbei handelt es sich um einen essentiellen Schritt des Prozesses, da sich alle Beteiligte detailliert mit den Funktionen auseinander setzen müssen. Die technisch geprägten Projektbeteiligten lernen dadurch viel über die intendierten Lehr‐/Lernprozesse, die Lehrenden hingegen über Grenzen und Begrifflichkeiten der Funktionskomponenten und alternative Umsetzungsmöglichkeiten. Dieser intensive Austausch muss strukturiert geführt werden und sollte beispielorientiert gestaltet sein.

Phase IV – Technik‐und Technologiesichtung

Nach erfolgreicher Zusammenstellung der Anforderungen werden in der vierten Phase bereits existierende und in Betrieb befindliche Systeme gesichtet, mit dem Ziel einen Großteil oder zumindest eine relevante Menge an Funktionen damit abdecken zu können. Diese Phase umfasst ausgedehnte Recherchen existierender und auf dem Markt befindlicher Systeme und Technologien, die an Hand der aktuell erhobenen Anforderung ausgewählt werden.

Phase V: Implementierung und Evaluation der erhobenen Teilsysteme

Die fünfte Phase umfasst schließlich die Umsetzung der konzipierten Lösung mit den ausgewählten Systemen. Das beinhaltet die Implementierung und Konfiguration von Systemen hinsichtlich der erhobenen Funktionen einschließlich Dokumentation und Tests. Durch diesen finalen fünften Schritt erhalten die Beteiligten einen tieferen Einblick in den Umgang, Administration und Konfiguration der Systeme und können in weiteren Zyklen deren Grenzen und Potentiale abschätzen und Wünsche an das System können in einer weiteren Iterationsstufe leichter formuliert werden. Je nach verwendeter Technik und Technologie sollte in dieser Phase die Einbindung der Projektbeteiligten in den Implementierungsprozess ermöglicht werden. In die Definition von Testfällen und der Evaluation an Hand realweltlicher Szenarien und Daten müssen die jeweiligen Lehr‐/Lernszenarios jedoch ausnahmslos mit einbezogen werden. Eine weitere Möglichkeit ist die Definition von „Dienst-Paten“, die auch Bewerbung, Einführung und Support der Dienste unterstützen.

Das zyklische Durchlaufen der fünf Phasen beinhaltet eine kontinuierliche Loslösung vom konkreten Lehr‐/Lernszenario, hin zu einer von Technologie abstrahierenden Formulierung der Anforderungen. Dieser Abstraktionsprozess bedingt, dass nicht verwendete Funktionen zunächst ignoriert werden. Dies reduziert zwar die Funktionen auf die von Lehrenden und Studierenden hauptsächlich genutzten und ermöglicht somit einem nichtversierten Benutzer einen schnellen Einstieg, verhindert jedoch das Neu‐Entdecken von vorhandenen aber bisher nicht genutzten Funktionen. Gerade aber dieses Entdecken neuer technischer Möglichkeiten bildet aber oftmals den Anstoß für Innovationen im Lehr-/Lernarrangement: Einer neuen technischen Möglichkeit werden vorher nicht bedachte oder vorher nicht mögliche didaktische Funktionen zugeschrieben. Aus diesen veränderten Lehr-/Lernszenarien entstehen wiederum veränderte Anforderungen an die Technologie. Während der notwendige Abstraktionsprozess zunächst überflüssig erscheinende Funktionen für das zu schaffende Bildungsmedium eliminiert, kann der weitere Innovationsprozess durch die Sichtbarkeit von zuvor unberücksichtigten Funktionen im Sinne eines zunächst „überschüssigen“ Potentials von Medientechnologien unterstützt werden. Dies ermöglicht medienunerfahrenen Lehrenden zum einen die Nutzung von bereitgestellten Kernfunktionen als Einstiegspunkt, ermöglicht zum anderen aber auch die weitergehende Auseinandersetzung und Verwendung von komplexeren Techniken und Funktionen. Im weiteren Verlauf kann beobachtet werden, ob Funktionen von den Anwendern angenommen werden und zu möglichen Innovationen in Studium oder Lehre führen. Ist keine weiterführende Nutzung ersichtlich, können die Funktionen ggf. entfernt werden.

Um die vorgestellten Funktionen der Kerndienste in den jeweiligen Szenarien zur Verfügung zu stellen existieren drei grundlegende Möglichkeiten der Einbettung:

Jede dieser drei Möglichkeiten besitzt ihre spezifischen Vor‐ und Nachteile. Beim Wrappen von Funktionen muss darauf geachtet werden, dass sich die Endanwendung gut in die den Kontext der PLE einpassen lässt, d.h. sowohl Styles und Designs übereinstimmen, das Layout responsiv ist und sich die Bedienmechanismen ähneln, sodass sich für den Endanwendenden ein homogenes Gesamtbild darstellt. Schwierig wird dies insbesondere bei systemübergreifenden Such‐und Hilfe‐Funktionen. Viele Anwendungen wie Moodle oder das Campus-Management-System sind sehr komplex, so dass es wenig Sinn macht ihre Einzelteile auf einer Seite innerhalb der PLE einzubinden. Um den komplexen Funktionen der Systeme den größtmöglichen Platz zu bieten, empfiehlt es sich diese komplett zu wrappen (vgl. Abbildung 4).

Die Einbettung von Teilfunktionen anderer Anwendungen in die PLE mit Hilfe des Portlet-Kontexts erweist sich als geeignet, sofern sich der Portletinhalt auf die wesentlichen gewünschten Teilfunktionen reduziert. Je nach verwendeter Technologie der einzubettenden Komponenten sind jedoch weitere Styleanpassungen notwendig um eine homogene Bedienoberfläche zu gewährleisten. Die Kommunikation zwischen den Portlets, auch als Inter-Portlet-Kommunikation bekannt (beispielsweise bei Auswahl eines Tages im Kalenderportlet werden alle für den Tag relevanten Inhalte im Blogportlet gefiltert), ist auf diesem Weg hingegen nicht möglich.

Hier bietet die Portlet‐Integration hingegen einen wesentlich flexibleren Weg, da die Darstellungs‐ und Interaktionsmechanismen frei definiert werden können und lediglich auf die Schnittstellen zurückgegriffen werden muss. Dieser Weg ist eleganter, bindet jedoch weitaus mehr Entwicklungsressourcen. Die Bereitstellung von Funktionalitäten in Form von Portlets bietet sich besonders für systemübergreifende und nicht explizit einem System zugeordnete Prozesse an, z. B. eine anwendungsübergreifende Kurs‐ und Ressourcenverwaltung.

Die Wahl des Integrationsweges richtet sich sowohl nach einzubettendem System als auch nach der gewünschten Integrationstiefe und damit Verzahnung unterschiedlicher Systeme in der PLE. Die technischen Vor- und Nachteile sind bereits frühzeitig den Akteuren des Prozessmodells zu kommunizieren und geeignet in die Entscheidung einzubeziehen. Ausgehend von den vorher definierten Szenarien und den notwendigen Funktionseinbindungen wurde am Beispiel einer PLE für die Universität Potsdam festgelegt, welche Dienste und Funktionen auf welche Art und Weise zu integrieren sind. Informationen, die über diverse Kerndienste hinweg existieren und auch gepflegt werden, nehmen hierbei eine Sonderrolle ein, da diese zur Vereinfachung des Alltags der Nutzenden an einem Platz – nämlich in der PLE – zur Verfügung stehen sollen.

Abbildung 4 ‐ Einbindung von Moodle in die PLE mittels Wrappen

Hierzu ist es nötig diese Informationen über die Dienste hinweg in der PLE abzubilden, um den Endanwendern einen homogenen Blick über alle Dienste gewähren zu können. Hierzu gehören die folgenden Funktionen:

Im folgenden Abschnitt wird der Frage nachgegangen, wie die komplexe Zusammenführung von Informationen über verschiedene Dienste erfolgen kann und die PLE dennoch flexibel für Erweiterungen von Diensten bleibt.

Die zugrundeliegende Systemarchitektur muss nicht nur die Anbindung und Einbettung verschiedener externer und hochschulweiter Dienste in die PLE ermöglichen; auch die Bereitstellung von Schnittstellen für die PLE und die Ausführung von systemübergreifenden Prozessen muss hierbei sichergestellt sein. Mit dem Ziel der Übertragbarkeit der PLE auf andere Hochschulen muss weiteren Anforderungen an eine langfristige Wiederverwendbarkeit, Skalierbarkeit und Erweiterbarkeit Rechnung getragen werden. Darüber hinaus müssen die vorgestellten Szenarien und damit die Integrationsansätze (besonders diejenigen, die eine Synchronisation zwischen verschiedenen Diensten voraussetzen) realisierbar sein. Wie in Abschnitt 3.4 beschrieben wurde, gliedern sich in die PLE viele Dienste der jeweiligen Hochschule und weitere Werkzeuge externer Anbieter ein. Neben dem einfachen Wrappen von Anwendungen in die PLE stellen vor allem dedizierte Ansichten in Form von Portlets eine Herausforderung dar, die mit den spezifischen Diensten und Werkzeugen verknüpft werden müssen. Die Dynamik dieser Landschaft erfordert einen besonders flexiblen und wartungsarmen Kopplungsansatz.

Um dies zu ermöglichen greifen die Portlets zunächst auf ein Bindeglied zwischen dem Endsystem (Dienst) und den Portlets zu – auf den sogenannten University Service Bus (USB), an den alle wichtigen Dienste (Kerndienste) mittels Schnittstellen angebunden sind. Diese Middleware-Komponente ermöglicht die Austauschbarkeit der Dienste und die Erweiterung der Schnittstellen zur Laufzeit, bietet weitreichende Funktionen zur Absicherung sowie zur Protokoll‐ und Datentransformation und stellt eine service‐orientierte Architektur zur Verfügung, die den Ansprüchen an Skalierbarkeit und Ausfallsicherheit gerecht wird (Kiy, Lucke & Zoerner 2014). Die Dienste werden hierbei mittels Webservices über den USB bereitgestellt. Hierbei wird soweit möglich auf standardisierte Protokolle und Formate zurückgegriffen (vgl. SOAP, REST, WSDL, XML oder JSON). Eigens entwickelte Schnittstellen sind über eine XSLT jederzeit austauschbar ohne andere Komponenten modifizieren zu müssen. Auf diese Weise ist die Lösung auch auf andere Hochschulen mit deren spezifischen Diensten und Schnittstellen transferierbar. Personenbezogene Daten werden ausschließlich über gesicherte Schnittstellen zur Verfügung gestellt; hierzu steht der USB mit der Endanwendung in einer Vertrauensbeziehung.

Diese Schnittstellen können in einem weiteren Schritt über den Öffentlichen University Service Bus – eine von außen zugängige Erweiterung des USB – von anderen Endanwendungen wie beispielsweise nativen und webbasierten Apps genutzt werden (Kiy, Grünewald et al. 2014). Ausgewählte Dienste oder Schnittstellen können auf diese Weise auch für andere Hochschulen bzw. Kooperationspartner freigegeben werden.

Eine weitere zentrale Komponente stellt die „Prozess‐Engine“ dar. Abläufe, die mehrere Systeme umfassen, werden einmalig aus bestehenden Webservices modelliert und unter Steuerung durch diese Komponente ausgeführt. Die hier modellierten Prozesse treten als Services auf, werden nutzbar für andere Prozesse oder Anwendungen und sind wiederum an den USB angebunden, so dass jeglicher Zugriff hierüber gekapselt ist (vgl. Abbildung 5).

Abbildung 5 ‐ Systemarchitektur für eine PLE mit den Hauptkomponenten

Die Basis einer funktionierenden PLE ist ein konsolidiertes Identity & Access Management, so dass jeder Nutzende mindestens einer Statusgruppe und somit den korrespondierenden Arbeitsgruppen und Studiengängen zugeordnet werden kann. Die Studiengänge können hierbei wiederum spezifische Funktionen und Werkzeuge bereitstellen. Hinzu kommen Datenbanken zur Speicherung weiterer personenbezogener Informationen zu freiwillig eingetragenen Daten wie Interessen, Forschungsschwerpunkten, Vorschlägen, Annotationen zu Lernobjekten oder dem Studiengang.

Die Validierung des Konzepts der Personal Learning Environment erfolgte zweistufig. Zunächst erfolgte die Ausgestaltung der Szenarien mit Hilfe des oben beschriebenen Prozessmodells und darauf aufbauend die Erprobung der Szenarien und der mediendidaktischen Gestaltung der konzipierten Szenarien im Rahmen zweier Studiengänge, die im Folgenden kurz beschrieben werden sollen. Sowohl der Masterstudiengang „Anglophone Modernities in Literature and Culture“ in der Anglistik/Amerikanistik als auch der Graduiertenstudiengang „Clinical Exercise Science (CES)” in den Sport- und Gesundheitswissenschaften wurden als neue gestufte Studiengänge an der Universität Potsdam etabliert. Der Masterstudiengang „Anglophone Modernities in Literature and Culture“ wird in Kooperation mit anderen Universitätsinstituten in den USA, Südafrika und Indien durchgeführt. Während des Studiums absolvieren die Studierenden Auslandsaufenthalte von mehreren Wochen und Monaten an den Partneruniversitäten. Trotz der räumlichen Trennung müssen die Studierenden jedoch in der Lage sein, mit ihren Kommilitonen an anderen Universitäten (daheim oder bei anderen Partnern) weiterhin an Ihren Projekten zusammenzuarbeiten. Im Graduiertenstudiengang „Clinical Exercise Science (CES)” sind die Studierenden grundsätzlich auf An-Institute und klinische Einrichtungen verteilt. Sie finden sich lediglich zu den organisierten Ringvorlesungen zusammen. Die Veranstaltungen werden aktiv von Studierenden mitgestaltet. Die Betreuung findet hierbei bilateral zwischen Dozierenden und Studierenden statt. Die Präsenzzeit sowohl des Master- als auch des Graduiertenstudiengangs beschränkt sich lediglich auf vereinzelte Veranstaltungen und wird durch mehr oder weniger lange Auslandsaufenthalte unterbrochen. Weiterhin ist das Lehr-/Lernsetting weitestgehend forschungsorientiert und eigenverantwortlich gestaltet. Die beiden Studiengänge wurden als Fallstudien ausgewählt, da zum einen ein konkreter Bedarf zur Online-Unterstützung von Lehr-/Lernprozessen vorliegt und zum anderen Mitglieder des Projektteams direkt an der Gestaltung der Studiengänge beteiligt sind. Weiterhin bilden die Settings typische Szenarien neuer Studiengänge durch ihr Profil als forschungsorientierte und internationale Studiengänge mit verteilten Arbeits- und Lernorten.

Eine Validierung der zugrundeliegenden technischen Infrastruktur der PLE erfolgte mit Hilfe einer mobilen Applikation (Kiy, Grünewald et al. 2014), die bereits wesentliche Funktionen der PLE besitzt. Somit konnten Funktionen und das Zusammenspiel der Systemkomponenten bereits in einem abgegrenzten Rahmen mit bis zu 4000 Nutzenden getestet und basierend auf deren Feedback verbessert werden.

Im Rahmen der zwei exemplarischen Studiengänge, in denen sich die Komplexität des Handelns von Personen in ihrem jeweiligen sozialen Kontext abspielt (Ludwig 2005), sollten zunächst Forschungsfragen beantwortet werden, die im Hinblick auf die langfristige Entwicklung hin zu einer persönlichen Lernumgebung aus unserer Sicht als sinnvoll erschienen. Hierzu wurde der komplexe Untersuchungsgegenstand der PLE zunächst auf die wesentlichen notwendigen Teilfunktionen für die Abbildung der Szenarien der Studiengänge unter dem Begriff der „eClass“ reduziert (vgl. auch Vorgehensweise aus Abschnitt 4.1) und sich anschließend auf die Beantwortung der folgenden Fragestellungen fokussiert:

Ziel der vorgestellten technischen Fallstudie war es, die folgenden Fragestellungen zu beantworten und Implikationen für die Weitarbeit aufzeigen.

Im folgenden Abschnitt werden die Ergebnisse der zwei Fallstudien vorgestellt und auf Erkenntnisse für die Weiterarbeit eingegangen.

Zu Beginn des interdisziplinären Entwicklungsprozesses waren die speziellen Bedürfnisse der zwei Fachdisziplinen unklar; es war ebenfalls fragwürdig ob trotz der inhaltlichen Ähnlichkeit der Studiengänge eine gemeinsame Umsetzung möglich ist. Die Lehrenden und Konzeptionisten der Studiengänge hatten ein Grundszenario im Kopf, für das sie sich eine technische Umsetzung wünschten. Die Szenarien entstanden aus Abwägungen über Inhalte, Ziele, einzusetzende Methoden und Medien in denen sich persönliche Vorerfahrungen, genutzte Werkzeuge und Technologieverständnis ausdrückten. Durch den regelmäßigen intensiven Austausch der Projektbeteiligten über die zu realisierenden Lehr-/Lernszenarien und durch zunächst „überflüssig“ erscheinende Technik und Funktionalität wurden die Lehrenden angeregt, ihre Überlegungen (insbesondere zu einzusetzenden Werkzeugen) zu hinterfragen und in existierende oder neue Lehr-/Lernsettings bzw. IT-Infrastrukturen zu integrieren. Die folgende Abbildung 6 stellt den resultierenden Systemüberblick dar, in dem bereits erste Technologien bzw. Werkzeuge für die Realisierung zugeordnet wurden.

Abbildung 6 - Grobübersicht zur Kommunikationsplattform eClass

In der zweiten Phase wurden die softwaretechnischen Anforderungserhebungen festgehalten und konkretisiert. Hierzu musste der beschriebene dynamische Aushandlungsprozess zwischen den verschiedenen didaktischen Handlungsebenen vorübergehend „eingefroren“ werden, um ein Momentbild einer bestimmten medientechnischen Funktionalität abstrahieren zu können. Während der Anforderungserhebung stellte sich heraus, dass die Sichtweise der Lehrenden auf ihr jeweiliges Technikkonzept sehr stark werkzeugorientiert bzw. werkzeugzentriert geprägt war. Die Anwender und Konzeptionisten hatten große Schwierigkeiten, aus den formulierten methodisch-medial-technischen Anforderungen die umzusetzenden didaktischen und technischen Funktionen zu abstrahieren und erwiesen sich bezüglich der analytischen Trennung von Methode, Ziel und Inhalt als wenig geübt. So wurden beispielsweise Methoden-, Ziel- und Inhaltsabstraktionen, wie „Stärkung kollaborativer Zusammenarbeit mit Hilfe von Kommentaren und Feedback“ und häufig mit „Ich brauche einen Blog“ umschrieben. So schien das Medium den Handlungsrahmen vollständig festzulegen: Was und in welcher Art und Weise präsentiert und erarbeitet werden soll, welche Aktivitäten erwartet werden und in welcher Form die Lehrenden intervenieren, definierte sich oft allein am Medium. Durch den beschriebenen Aushandlungsprozess gelang es, diese Vorstellungen schrittweise aufzubrechen.

In Phase III wurden die Teilfunktionen konkretisiert. Bereits einen Konsens über die Grundfunktionalität eines Blogs zu erlangen stellte sich als zunehmend schwierig heraus. Die Sichtweisen gingen stark auseinander ob beispielsweise RSS-Feeds, Tag-Clouds, Blogrolls oder sogar Kalender- und Kommentarfunktionen zwangsläufig zu einem Blog gehören. Somit wurden die Anforderungen für die jeweiligen Einzelfunktionen erneut zur Diskussion gestellt. Dieser Schritt erwies sich als besonders aufwändig, da hier zum ersten Mal Grundverständnisse von Technologien und eingesetzten Techniken, deren Tragweite und Grenzen verständlich gemacht werden mussten. Der fehlende Einblick in heutige Webtechnologien und mangelndes Verständnis für die Komplexität von Softwareentwicklungen auf der einen Seite sowie die im Kopf bereits vorhandenen, zum Teil aber nicht klar kommunizierbaren Lehr-/Lernszenarien und Erwartungen an die Technik auf der anderen Seite gestalten die Zusammenarbeit spannend. Für den Austausch der Vorstellungen und zur Konsolidierung von Terminologien, Technologien und Techniken können vor allem Analogien (bspw. „Login und Dienste wie bei Google Docs“ „eine Tag-Cloud wie hier bei Wordpress“ „Quizzes und Rechteverwaltung wie in Moodle“) einen wesentlichen Beitrag zu interdisziplinären Kommunikation leisten. Diese konnten als erste Verständigung mit den Lehrenden genutzt werden.

In der Phase IV erfolgte die Technik- und Technologiesichtung. Hierbei wurden am Beispiel der eClass zunächst die Systeme Typo3, Mahara, Wordpress und Moodle mit entsprechenden Erweiterungen genauer gesichtet, da diese Systeme den Beteiligten bereits bekannt waren. In dieser Phase werden den Projektbeteiligten sowohl die Stärken als auch die Schwächen der jeweiligen Technologien bewusst und sie erhielten tiefergreifende Einblicke in den Umgang mit den Systemen.

In Phase V wurden mit den Projektbeteiligten Funktionen implementiert. Da sich in der Zwischenzeit die Dimensionen des Ziels, der Methoden, der Medien und Inhalte der Beteiligten verschoben haben können, mussten erneute Anpassungen entlang der fünf Phasen vorgenommen werden. Es erfolgt somit nach jeder fünften Phase (also sobald ein überarbeiteter Prototyp für den Anwender zur Verfügung gestellt wird) eine gezielte Intervention, die nach Reinmann als Interaktion zwischen Methoden, Medien, Materialien, Lehrenden und Lernenden verstanden wird (vgl. Reinmann 2005). Diese praktisch evolutionären Entwicklungen werden von allen Beteiligten besser angenommen (vgl. Reinmann 2005). In Folge dessen hat das Projekt eine gewisse Eigendynamik erhalten, in dem sich Einzelinteressen, Kommunikationsstrukturen und Schwerpunktsetzungen über die Zeit verlagerten. Dies ist zugleich als Herausforderung und als Chance für die erfolgreiche Umsetzung einer zu entwickelnden Lernumgebung zu begreifen.

Im Rahmen der vorgestellten Fallstudien konnten wertvolle Erkenntnisse und Ergebnisse für die den entwickelten Prototyp und somit für die resultierende PLE gewonnen werden:

Im Laufe des Wintersemesters werden die vorgestellten Fallstudien fortgeführt und neue produktiv zu setzende Dienste an die PLE angebunden. Weiterhin ist geplant zum Ende des Wintersemesters ausgedehnte Nutzertests durchzuführen, um Rückschlüsse auf die Eignung des Bedienkonzepts, der Integrationsmodi und der bisher entwickelten Benennung von Funktionen ziehen zu können.