Skip to content. | Skip to navigation

Citation and Metadata
Document Actions
Full Text

1. Motivation

E‐Learning nimmt inzwischen einen festen Platz sowohl als ein integraler Bestandteil von Lehre und Studium als auch als ein strategisches Instrument bei der Steuerung von Hochschulen ein. Wenn auch viele Aspekte noch Gegenstand der aktuellen Forschung sind (Drummer et al. 2011), so wurden doch die Rahmenbedingungen für erfolgreiches E‐Learning bereits vielfältig untersucht. Dabei werden besonders die Integration einzelner Lösungen in eine durchgängige IT‐Infrastruktur sowie die Verankerung in passenden Organisationsstrukturen (Albrecht et al. 2005) hervorgehoben.

Der Status‐Quo der E‐Learning‐Infrastruktur von Hochschulen besteht jedoch meist aus einer heterogenen, historisch gewachsenen System‐ und Softwarelandschaft, die den vielfältigen und oft widersprüchlichen Anforderungen aus Forschung, Lehre und Verwaltung gerecht werden muss (Lucke & Tavangarian 2007; Kopp et al. 2013). Von Hochschule zu Hochschule verschieden, liegen E‐Learning‐Angebote häufig zentral und dezentral verteilt in unterschiedlichsten Systemen vor. Technische, organisatorische und rechtliche Rahmenbedingungen sind i.d.R. sehr inhomogen, was eine Integration verschiedener Werkzeuge und Plattformen erschwert. Hinzu kommen inkonsistente Bedienkonzepte, fehlende oder unausgereifte Schnittstellen und nur im seltensten Fall Standards zum Austausch von Lernobjekten oder Lernaktivitäten. Weitere Probleme sind komplexe Workflows und Lernabläufe über die verschiedenen Systeme hinweg. Viele Werkzeuge und Plattformen besitzen ein eigenständiges Profil‐ und Rechtemanagement. Besonders gravierend wird dies für Studierende und Lehrende, die mehreren Einrichtungen zugeordnet sind, sodass der Überblick über die genutzten Systeme schwer fällt. Den Nutzenden bleibt oft unklar, wo sich welche erstellten Lerninhalte und deren Verknüpfungen befinden. Es scheint jedoch selbstverständlich, dass derartige organisatorische Hürden mit Einbußen bei der Qualität und beim Erfolg von E‐Learning‐Maßnahmen einhergehen (Schulmeister 2006).

Wünschenswert wären dagegen eine langfristige systemübergreifende Weiterverwendung von Lernartefakten und eine Verzahnung von Lernprozessen über verschiedene Institutionen hinweg (Kiy, Lucke & Zoerner 2014). So würde eine Situierung von Lernen in verschiedenen Kontexten ermöglicht werden, ohne jeweils neue E‐Learning‐Umgebungen hierfür bereitstellen bzw. benutzen zu müssen. Das schließt eine weitestgehend automatisierte Anpassung von Inhalten und Werkzeugen für den jeweiligen Einsatzzweck ein (Lucke & Specht 2012). Darüber hinaus sollten Studierende und Lehrende die verwendeten bzw. erstellten Medien trotz heterogener Systeme und über Systemgrenzen hinweg flexibel kombinieren, arrangieren und transferieren können. Als Systemgrenzen seien dabei nicht nur die Dienste innerhalb einer Hochschule verstanden, sondern auch Grenzen zwischen Hochschulen bzw. jenseits des Hochschulkontexts ‒ bis hin zur Verwendung für das lebenslangen Lernen. Eine derartige Evolution von E‐Learning‐Systemen muss jedoch bestehende Strukturen und Plattformen berücksichtigen (Kerres et al. 2010), denn vielfach bilden Learning Management Systeme (LMS) wie Moodle, Blackboard oder Ilias den Kern der vorhandenen digitalen Lehr‐/Lernangebote an Hochschulen und sind zwingend in neue Lösungen zu integrieren.

Daher werden in zunehmendem Maße Portal‐Technologien eingesetzt (Strehl 2012; Hilse & Lucke 2013), die vorhandene Dienste als sogenannte Portlets in eine zusammenhänge Web‐Oberfläche einbetten. Neben der damit einhergehenden Systematisierung und Konsolidierung von IT‐Infrastrukturen, die u.U. sogar von schlankeren Organisationsstrukturen flankiert werden kann (Margaria & Hinchey 2013), können in einem konsistenten Portal zudem den Nutzern Zusammenhänge aufgezeigt und Vorgänge transparent gemacht werden, die zuvor über verschiedene Systeme hinweg nur schwer nachvollziehbar waren. Aufgrund der engen Integration verschiedener Werkzeuge (einschließlich deren Start‐ und Hilfeseiten, Suchfunktion usw.) ist der Zugang für den Anwender i.d.R. niedrigschwellig gestaltbar ‒ auch in einer komplexen Systemlandschaft. Ein weiterer Vorteil von Portalen ist die mögliche Einbindung externer Dienste, z.B. aus dem an Hochschulen bislang noch unterrepräsentierten Bereich Social Media (Wannemacher 2013). Beim Zugriff auf Cloud‐Dienste sind jedoch die spezifischen Sicherheitsbedürfnisse von bzw. juristischen Anforderungen an Hochschulen zu beachten, sodass eine Integration kommerzieller Cloud‐Angebote insbesondere aus dem anglo‐amerikanischen Raum im Allgemeinen schwierig ist (Wilms 2014).

Mit dem Aufbau einer durchgängigen E‐Learning‐Infrastruktur sind über typische technische, organisatorische und rechtliche Fragestellungen hinaus auch weiterführende strategische Aspekte wie z.B. IT‐Governance und Change Management (Blakley 2006; von der Heyde 2014) verbunden, die jedoch im Rahmen dieses Artikels nicht weiter vertieft werden können. Zugleich wird klar, warum E‐Learning nicht als separates Handlungsfeld innerhalb der Hochschule behandelt werden kann, sondern ein integraler Bestandteil der Digitalisierungsstrategie einer Hochschule sein sollte (Bode & Borgeest 2010). Der vorliegende Artikel widmet sich dem Aufbau einer komplexen Portal‐Lösung für E‐Learning an der Hochschule, die den oben genannten Anforderungen gerecht wird. Als Beispiel dient die Universität Potsdam, wo mit Unterstützung aus dem Qualitätspakte Lehre eine Personal Learning Environment (PLE) auf Basis der campusweit existierenden E‐Learning‐Systeme entsteht (Hilse & Lucke 2013). Dafür wird in Kapitel 2 zunächst die vorhandene Situation in der internationalen Forschung und Praxis analysiert. Darauf aufbauend werden in Kapitel 3 die abgeleiteten Kernfragen anhand der Universität Potsdam konkretisiert. Im Ergebnis entsteht ein Anforderungskatalog, der sowohl allgemeingültige Kriterien als auch lokale Vorstellungen und Rahmenbedingungen umfasst. Auf dieser Basis erfolgt in Kapitel 4 die Vorstellung eines interdisziplinären Entwurfs- und Entwicklungsmodells, verschiedener technischer Integrationsansätze und der Systemarchitektur der PLE. Anschließend wird in Kapitel 5 eine Synthese der vorhandenen Dienste und Plattformen innerhalb und außerhalb der Universität Potsdam in ein durchgängiges Portal an Hand einer durchgeführten Fallstudie vorgestellt. Der Artikel schließt mit der Zusammenfassung erzielter Erkenntnisse, setzt diese in Bezug zu noch ausstehenden Arbeiten und zeigt auf wie die Ergebnisse auf andere Hochschulen übertragbar sind.

2. Stand der Forschung und der Entwicklung

Der Stand von Forschung und Entwicklung zu Personal Learning Environments (PLEs) spiegelt die inhomogenen Konzeptionen und Zielsetzungen wieder, die mit relativ neuen technologischen Entwicklungen verbunden sind. In der überwiegend englischsprachigen Diskussion werden Konzepte wie „Personal Learning Environment“, „Virtual Learning Environment“, „Institutional Personal Learning Environment“ oder „Ubiquitous Personal Learning Environment“ unterschieden (Corous 2009; Schaffert & Kalz 2008; Buchem et al. 2011; Taraghi 2012). Ebenso sind darüber, welche Aufgaben und Funktionen PLEs im Kontext von Lehre, Studium und Lernen wahrnehmen können und auf welche lerntheoretischen Grundannahmen sie sich beziehen, verschiedene Auffassungen und Ansätze vertreten (Salinas 2011; Fiedler & Väljataga 2011).

Die generelle Fragestellung im Zusammenhang mit PLE‐Konzepten scheint zu sein, wie sich die positiven Effekte des Web 2.0 hinsichtlich aktiver Mitgestaltung, erweiterter Kommunikation und Vernetzung in den Kontext von Bildung und Lernen übertragen lassen (Schaffert & Kalz 2008; Downes 2005). Dementsprechend orientieren sich die technologischen „Blaupausen“ der PLEs zumeist an Diensten und Werkzeugen, die das Internet heute ausmachen: Differenziertes Kontaktmanagement, einfache synchrone Kommunikation, geräteunabhängige Verwaltung von Inhalten in der Cloud, die Nutzung von reichhaltigen Medien, gemeinsames Erstellen und Verwalten von Artefakten und das umstandslose Aggregieren und Teilen von digitalen Inhalten aller Art bilden das Spektrum der Features in PLE‐Konzepten. Gemeinsam ist den meisten Ansätzen, dass ein Perspektivenwechsel auf digitale Lehr‐/ Lernumgebungen proklamiert wird: Lernendenzentrierung, Autonomie und Selbstorganisation bilden die wiederkehrenden inhaltlichen Kernelemente, auf die sich PLE‐Ansätze beziehen. Lerntheoretisch verorten sich die PLE‐Konzepte zumeist in (sozial¬)konstruktivistischen und neuerdings in konnektivistischen Modellen (Schaffert & Hilzensauer 2008; Courous 2010). Schaffert & Hilzensauer (ebd.) beschreiben sieben Kernfragen bei der Weiterentwicklung von Learning Management Systemen hin zu einer PLE:

  • Wie kann die Veränderung der Rolle des Lernenden hin zu einem „Prosumer“ in einer Lernumgebung berücksichtigt werden?

  • Wie kann eine Personalisierung von Inhalten und Diensten erfolgen?

  • Wie können Inhalte offen und vernetzt durch die Lernenden organisiert werden?

  • Wie kann die soziale Organisation des Lernens mit dem Fokus auf Lerngemeinschaften und Kooperation realisiert werden?

  • Wie kann eine multiple, durch die Lernenden gesteuerte Eignerschaft an Inhalten realisiert werden?

  • Wie kann der Wandel zu einer auf Selbststeuerung und Selbstkontrolle basierenden Lernkultur unterstützt werden?

  • Wie kann Interoperabilität zwischen Systemen, digitalen persönlichen Profilen, Ressourcen und Quellen hergestellt werden?

Mit der Orientierung an Nutzungsweisen des Web 2.0. bzgl. Selbststeuerung und Autonomie der Lernenden ist eine Reihe von weitergehenden Fragen aufgeworfen, die bei der Entwicklung einer PLE beantwortet werden müssen. So kann gefragt werden, ob eine PLE als institutionelles Angebot nicht mehr notwendig oder sogar kontraproduktiv ist, da das Web alles zur Verfügung stellt, was der individuelle, digital vernetzte Lernende braucht: „Why do we need a PLE when we already have the Internet? The Internet is my PLE, ePortfolio, VLE what ever. Thanks to blogger, bloglines, flickr, ... I have a strong online ID and very extensive and personalised learning environment.” (Blackall 2005; vgl. auch zur Alternative „Facebook‐Gruppe statt LMS“ Meishar‐Tal et al. 2012).

Auch Fragen nach den institutionellen Zielen und Ansprüchen an die Qualität und die Möglichkeiten didaktischer Gestaltung in offenen Lernumgebungen (vgl. dazu im Kontext von „Web 2.0“ Gaiser 2008; Gaiser & Thillosen 2009) sind nicht beantwortet. Weiterhin ist offen, ob das Leitbild von Autonomie und Selbstverantwortung den Ansprüchen und Möglichkeiten der Studierenden überhaupt gerecht wird und die Übertragung der Gestaltungsprinzipien des Social Web in Bildungskontexte aus der Sicht der Studierenden wünschenswert ist (Schulmeister 2012). Beim Review der PLE‐Literatur stellen auch Zhou et al. fest, dass die Eigenschaften der Lernenden bislang nicht ausreichend berücksichtigt werden (Zhou 2013). Auch Mayrberger konstatiert in einer explorativen Studie, dass Studierende unter gewissen Umständen Fremdkontrolle des Lernprozesses nicht nur akzeptieren, sondern sogar als hilfreich erachten (Mayberger 2011). Gegen die Übertragung, Einbettung bzw. Nutzung von Web 2.0 Diensten und Konzepten sprechen nicht zuletzt auch rechtliche Gründe, und daher existiert eine gewisse Unsicherheit, was erlaubt oder wünschenswert ist. Die Tendenz der großen Web 2.0‐Dienstanbieter, etablierte Grundprinzipien der informationellen Selbstbestimmung, wie die Kontrolle über persönliche Daten, in Frage zu stellen (vgl. dazu Schultz 2010) wird nicht nur im Bereich der Schulen diskutiert. Ebenso befinden sich die institutionellen Rahmenbedingungen und die technischen Möglichkeiten zum Einsatz von Cloud‐Diensten an Hochschulen noch nicht in Übereinstimmung (Wilms 2014).

Angesichts dieser uneinheitlichen Lage geben die derzeitigen PLE-Konzeptionen nur wenig Hilfestellung für die Entwicklung didaktischer Konzepte, deren technische Realisierungen und den notwendigen Rahmenbedingungen. Das heute vorhandene Spektrum von Ansätzen zur Realisierung von PLEs reicht von offenen Plattformen, in denen Studierende ihre persönlichen Ressourcen, Kontakte und genutzten Dienste einbetten (vgl. das PLE der TU‐Graz, Ebner & Taraghi 2010), über Portale zur Studienorganisation inkl. Semesterplanung und Verwaltung von Studienleistungen (vgl. das MyDesk-Projekt an der TU‐Berlin: http://www.innocampus.tu‐berlin.de/index.php?id=262 ) bis hin zu stark auf mobile Nutzungsszenarien fokussierende Projekte, wie es im Rahmen des „Learning Layers“ Projekt entwickelt wurde, die auf den individuellen Charakter der „Lernumgebung“ fokussieren (Attwell et al. 2013).

Vor dem Hintergrund dieses Diskussionsstands sind wir in der Entwicklung der PLE an der Universität Potsdam von folgenden Grundannahme ausgegangen: Eine PLE wie wir sie im Rahmen unseres Projekts auffassen ist im Wesentlichen eine institutionell bereitgestellte Lehr-/Lernumgebung. Dies reflektiert die unserer Auffassung nach weiterhin bedeutsame Rolle, die die bewusste, zielgerichtete Gestaltung eines Lehr-/Lernarrangements durch zentrale Akteure spielt und trifft damit den Bedarf sowohl der Lehrenden wie der Studierenden. Dies entspricht auch der Rolle der Institution, bestehende Dienste anzubieten und zu integrieren, die Qualität und Integrität dieser Dienste zu gewährleisten sowie einen effektiven Support anzubieten. Gleichzeitig ist es aber auch erklärtes Ziel im Rahmen der zu schaffenden PLE, den Nutzern weitergehende Autonomie und Rechte einzuräumen. Das betrifft zum Beispiel die Einrichtung von Gruppenräumen oder Szenarien sowie das Teilen von Inhalten oder von Diensten (z.B. das Etherpad). Die zu schaffende Umgebung soll weiterhin personalisierbar und zu einem gewissen Grad bereits personalisiert sein. Das bedeutet, die Zugänge zu persönlichen Bereichen, wie zum Beispiel den eigenen Kursen der Lernplattform, dem eigenen Mail-Account u.a.m. sollen bereits angelegt werden, die Umgebung bleibt jedoch individuell anpassbar. Auf Grund dieser Konzeption einer institutionellen personalisierbaren Lehr-/Lernumgebung (iPLE) ergibt sich eine Reihe von notwendigen Entscheidungen hinsichtlich der Planung und Realisierung, wie sie im nächsten Abschnitt beschrieben werden. In der diesen Beitrag abschließenden Zusammenfassung wird unser spezifischer Ansatz und dessen bisher geleistete Realisierung anhand der sieben von Schaffert und Hilzensauer formulierten Kernfragen (siehe oben) in die bestehende Diskussion eingeordnet.

3. Anforderungen an eine Personal Learning Environment

3.1 Designentscheidungen auf dem Weg zur Personal Learning Environment

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:

  • Kontrolle und Ownership:
    In diesem Bereich liegen Fragen zur Gestaltung der technischen und juristischen „Eignerschaft“ an Daten und Diensten im Kontext einer PLE vor, zum Beispiel wie der Zugriff auf Daten verwaltet wird und wer darüber an welchem Punkt entscheidet.

  • Zielgruppen, Nutzer:
    Hier muss beantwortet werden, inwieweit Rollen und Eigenschaften für verschiedene Nutzergruppen festgelegt werden sollen und welchen Status diese haben, zum Beispiel Lehrenden‐Status, Zugehörigkeit zu Studienbereichen / Studiengängen, Studieninteressierte, Alumni etc.

  • Didaktische Funktionen:
    Wie können institutionelle Lernanforderungen, didaktische Orientierungsfunktionen aber auch informelle Lernzusammenhänge gestaltet werden? Wie können zum Beispiel Leistungsbewertung und Assessment berücksichtigt werden? Welche mikrodidaktischen Szenarien werden berücksichtigt?

  • Lebensbegleitendes und institutionsübergreifendes Lernen:
    Wie kann der Im‐ und Export von Lernartefakten stattfinden, und wie findet eine individuelle Kompetenzdarstellung statt? Wie können außerhochschulische und hochschulübergreifende Lernnetzwerke berücksichtigt werden?

  • Offenheit und Öffentlichkeit:
    Wie sind die technische Offenheit und der Schutz von Privatheit vereinbar, und in welchem Zusammenhang stehen die informationelle Selbstbestimmung und die Kontrollnotwendigkeiten und Schutzfunktionen der Institution?

  • Medientechnische Gestaltung:
    Wie können individuelle Gestaltung, Adaptierbarkeit und eine sinnvolle Beschränkung von Funktionsmöglichkeiten, z.B. durch Vorkonfigurationen, umgesetzt werden?

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.

3.2 Anforderungserhebung

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).

3.3 Szenarien

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:

  • Gruppenarbeit:
    Dieses Szenario beinhaltet verschiedene Funktionen die dazu geeignet sind, die selbstorganisierte Gruppenarbeit zu unterstützen. Dazu gehören Kommunikationswerkzeuge wie Kalender, Aufgabenlisten und Neuigkeiten sowie Funktionen, die das kooperative Arbeiten erleichtern, z.B. einen synchronen Texteditor (Pad), eine Mindmap, einen Blog‐Aggregator und ein Wiki.

  • Lehre interaktiv:
    Das Szenario stellt auf ein lehrendenzentriertes Setting ab. Die Idee ist, die PLE hier als eine Erweiterung und Integration der in der Lernplattform vorhandenen Möglichkeiten zu nutzen. Gegenüber einem Moodle‐Kurs sollen hier jedoch aufgabenbezogene Aktivitäten der Studierenden besser unterstützt werden. Dennoch ist dieses Szenario mit einem Moodle‐Kurs gekoppelt. Weiterführende Funktionen wie komplexe Tests und Online‐Aufgaben können wie gewohnt in Moodle genutzt werden.

  • (interne) Kommunikation:
    Das Szenario „interne Kommunikation“ soll die Möglichkeit bieten, vielfältige Arbeits‐ und Kommunikationsprozesse zu unterstützen, die nicht nur in der Lehre sondern auch in Projekt‐ und Forschungsgruppen aber auch in der Hochschulverwaltung genutzt werden können. Dieses soll auf Basis der PLE langfristig in Richtung eines komplexen Intranets weiterentwickelt werden.

  • Portfolio:
    Das Portfolio‐Szenario kapselt relevante Dienste und Funktionen für verschiedene E‐Portfolio‐Aktivitäten (wie Sammeln, Strukturieren und Veröffentlichen von Lernartefakten, das Führen von Lerntagebüchern oder die Darstellung von erworbenen Kompetenzen).

  • persönlicher Bereich:
    Auch der Persönliche Arbeitsbereich wurde in diesem Zusammenhang als ein Szenario bearbeitet. Hier geht es um eine eigene personalisierte und personalisierbare Einstiegsseite, die einen strukturierten und anwendungsfreundlichen Zugang zu den Hauptfunktionen der PLE und den Kerndiensten der Hochschule anbietet.

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.

3.4 Werkzeuge

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:

  • Startseite

  • Gemeinsam Arbeiten

  • Dokumente & Ressourcen

  • Organisatorisches

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:

  • Learning Management System (Moodle)

  • Web-Speicherdienst (ownCloud)

  • kollaborativer Editor (Etherpad)

  • Abstimmungs‐Tool des DFN (Tester)

  • E‐Portfoliosystem (Liferay / Mahara)

  • E‐Mail‐& Kalendersystem als Groupware (CommuniGate)

  • PLE‐Basis (Liferay)

  • Campus-Management-System (auf Basis von HIS‐GX bzw. HISinOne)

  • Universitätsbibliothek (Kataloge)

  • Medienserver (Helix Media Library)

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

4. Synthese in eine durchgängige Umgebung

4.1 Vorgehensweise

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 allgemeine Vorgehen orientiert sich am General System Design, wobei die ADDIE‐Sequenzierung als Handlungsorientierung dient.

  • Der Gestaltungsprozess ist an Modelle des Didaktischen Designs angelehnt, mit einem Fokus auf teamorientierte, ergebnisoffene Entwicklungsprozesse.

  • Die Entwicklung von Teilsystemen folgt Ansätzen der Designentwicklung, die mit entsprechenden Modellen aus der Softwareentwicklung kombiniert sind.

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.

4.2 Integrationsansätze

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

  • Wrappen:
    Je nach Dienst macht es Sinn diesen als vollständige Anwendung einzubinden. Dies ist vergleichbar mit dem bekannten Inline‐Frame (IFrame). Hierbei wird die Anwendung über die maximal zur Verfügung stehenden Breite und Höhe der PLE mittels eines speziellen IFrame‐Portlets eingebunden. Lediglich ein schmaler Streifen am oberen Rand bleibt für die übergreifende Navigation in der PLE erhalten (vgl. Abbildung 4). Mit der Fortschreibung von IFrame in HTML5 eröffnen sich für die Zukunft weitere Möglichkeiten, die einzubettende Applikation zu modifizieren.

  • Herauslösung:
    Hierbei können Teilkomponenten aus der einzubettenden Anwendung herausgelöst werden und mit Hilfe des Portlet‐Kontexts als Widget, Portlet oder Gadget in die PLE integriert werden. Dies ist nur möglich sofern die Anwendung dies technologisch unterstützt und bspw. auch auf einem Portal‐Server oder Ähnlichem basiert.

  • Portlet‐Integration:
    Bei der Portlet‐Integration wird mittels Schnittstellen auf die einzubettende Endanwendung zugegriffen um den Informationsfluss zwischen Dienst und Portlet zu gewährleisten. Das Anwendungsspektrum erstreckt sich von der bloßen Informationsdarstellung bis zur weitreichenden oder kompletten Funktionsabbildung des einzubettenden Diensts. Besonders hervorzuheben ist hierbei die Kontrolle über das äußere Erscheinungsbild der so angebotenen Funktionen des Dienstes.

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:

  • Kalender:
    Der Kalender in der PLE stellt hierbei die zentrale Sammelstelle aller Informationen dar, d.h. hier fließen alle Termine aus der Lernplattform, der Groupware, dem Campus‐Management‐System, der Bibliothek, privaten Kalenderquellen (z.B. Google) und weiteren in Zukunft zu identifizierenden Diensten ein.

  • Neuigkeiten:
    Eine weitere wichtige Komponente sind die neuesten und wichtigsten Aktivitäten in den Kerndiensten, also Informationen die andernfalls mühsam zusammengesucht werden müssten. Die Aktivitäten aus Moodle, der Speicherverwaltung, der Groupware, dem Campus¬-Management‐System, der Universitätsbibliothek und der Videoplattform werden hierzu an einem Ort gebündelt.

  • Aufgabenlisten:
    Aufgaben werden in der Groupware und in der PLE geführt, so dass diese in der PLE zusammengeführt werden.

  • Kursverwaltung:
    Eine an der Universität Potsdam bislang noch nicht vorhandene Funktion ist die Synchronisation zwischen dem Campus‐Management‐System und der Lernplattform. Diese Kursverwaltung soll über die PLE einsehbar sein. Weiterhin soll es den Endanwendern möglich sein, bei Bedarf selbst neue E‐Learning‐Kurse direkt in der Lehrveranstaltungsverwaltung des Campus‐Management‐Systems automatisiert anzulegen, Einschreibeprozesse der Studierenden und Kurszuordnungen zu vereinfachen oder weitere Dienste wie externe Wikis, Blogs, Web 2.0 Tools hinzuzufügen.

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.

4.3 Systemarchitektur

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.

5. Realisierung der PLE

5.1 Durchgeführte Fallstudien zur Validierung

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.

5.2 Validierungsziele und Methoden

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:

  • Wie lassen sich die verschiedenen fachspezifischen Sichtweisen von Technologie und Lehr-/Lernsettings vereinen und erfolgreich interdisziplinär realisieren?

  • Wie können die Szenarien für die PLE so verallgemeinert werden, so dass sich eine Vielzahl existenter Lehr-/Lernszenarien abdecken lassen.

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

  • Ist die Systemarchitektur ausfallsicher und skalierbar gestaltet und kann die Infrastruktur unkompliziert um beliebige Dienste erweitert werden?

  • Können mit den bisher etablierten Schnittstellen gängige Nutzungsszenarien für die PLE abgedeckt werden?

  • Welche weiterführenden Bedarfe ergeben sich aus Nutzendenperspektive für die Weiterentwicklung der PLE?

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

5.3 Ergebnisse der Fallstudien und Bewertung

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:

  • Essentielle Kerndienste zur Unterstützung der Studierenden und Lehrenden an der Universität Potsdam konnten für die PLE bereitgestellt werden.

  • Die vorgestellten Szenarien und damit verbundene Funktionen konnten ausdifferenziert und in Form von wiederverwendbaren Templates umgesetzt werden.

  • Die unterschiedlichen und individuellen fachspezifischen Sichtweisen lassen sich mit Hilfe des vorgestellten Prozessmodells konsolidieren und anschließend adäquat implementieren, so dass der Prozess auf weitere Studiengänge übertragbar ist.

  • Die vorgestellten die Integrationsmechanismen wurden exemplarisch eruiert und in der PLE umgesetzt.

  • Die Systemarchitektur wurde aufgebaut, Schnittstellen zu Kerndiensten etabliert und zunächst im Rahmen der mobilen Applikation erprobt.

  • Erste systemübergreifende Prozesse auf Basis zuvor etablierter Schnittstellen wurden umgesetzt.

  • Teilfunktionen wurden in Form von Portlets für den Endanwender in der PLE gekapselt.

  • Die Verwendung des Open‐Source Framework Liferay erwies sich für die Umsetzung einer PLE in unserem Kontext als geeignet.

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.

6. Zusammenfassung und Ausblick

Der Beitrag motiviert die Notwendigkeit, umfassende und personalisierbare E‐Learning‐Umgebungen an Hochschulen zu schaffen, die bestehende Werkzeuge und Dienste aus diesem Umfeld (und z.T. auch weitere) in eine durchgängige Lösung integrieren. Ausgehend von bisherigen Untersuchungen und Realisierungsansätzen für Personal Learning Environments wurde eine Lösung für die Universität Potsdam entwickelt. Hierzu beschreibt der Beitrag sowohl die identifizierten Anforderungen und die Umsetzung des Systems als auch den dahinter stehenden, interdisziplinären Entwurfs‐ und Entwicklungsprozess. Als eine wesentliche Erkenntnis kann hierbei festgehalten werden, dass die Gestaltung eines derart komplexen E‐Learning‐Systems zwingend in einem interdisziplinären Team und in beständigem, engem Abgleich von pädagogischen und technischen Aspekten erfolgen muss. Keinesfalls sollten diese beiden Perspektiven als Ebenen im Sinne einer hierarchischen Ordnung (egal in welcher Reihenfolge) oder einer Grob‐und Feinspezifikation in der Art einer Auftragsentwicklung verstanden werden. Vielmehr erfordert eine solche interdisziplinäre Aufgabe eine iterative Vorgehensweise aus wiederholt bearbeiteten Phasen, die von beständigem Versuch und Irrtum geprägt sein kann. Dies greift Methoden aus der agilen Software‐Entwicklung auf und setzt sie in dem hier beschriebenen Vorgehensmodell um.

Vergleicht man die entstandene Lösung mit den von Schaffert & Hilzensauer (2008) beschriebenen Herausforderungen der PLE‐Entwicklung, so lässt sich feststellen:

  • Der geforderte Paradigmenwechsel hin zu Studierenden als „Prosumern“, die selbstgesteuert Inhalte sowohl erzeugen als auch verwenden, wird insbesondere durch die Szenarien Gruppenarbeit, E‐Portfolio und persönlicher Bereich aufgegriffen. Aber auch das an die rechnergestützte Präsenzlehre angelehnte Szenario Lehre interaktiv sowie das Szenario zur internen Kommunikation profitieren von diesem Wechsel, da sich die Menge und die Vernetzungsmöglichkeiten der verfügbaren Artefakte und Werkzeuge erhöhen.

  • Die eingesetzte Portaltechnologie erlaubt es, die Benutzungsoberfläche (d.h. die Auswahl und die Anordnung der eingebundenen Dienste) an die individuellen und sich beständig ändernden Bedürfnisse anzupassen. Das kann sowohl durch manuelle Konfiguration als auch automatisiert (z.B. auf Grundlage vordefinierter Prozesse und Templates) erfolgen. Geeignete Schnittstellen vorausgesetzt, kann sogar dienstübergreifend das Verhalten der Anwendungslogik angepasst werden.

  • Die Nutzer können über den Activity Stream (Neuigkeiten) systemweit Informationen und Ereignisse im Überblick behalten; dafür stehen verschiedene Visualisierungsmöglichkeiten insbesondere im Szenario persönlicher Bereich zur Verfügung. Das erhöht die Transparenz der unterstützten Lehr‐/Lernprozesse, zeigt neue Möglichkeiten der Vernetzung sowohl auf technischer als auch auf persönlicher Ebene auf.

  • Dadurch werden unmittelbar die Community‐Bildung und die Kollaboration gefördert. Gemeinschaftliche Lerngelegenheiten werden insbesondere in den Szenarien Gruppenarbeit und Lehre interaktiv unterstützt, wirken sich aber aufgrund der sozialen Vernetzung auch positiv auf andere Szenarien aus.

  • Die Personalisierbarkeit der Lernumgebung fördert die Herausbildung eines Bewusstseins für die Eigentümerschaft nicht nur an Daten, sondern auch an Prozessen. Damit einher geht neben der pädagogischen Einbettung und technischen Unterstützung aber auch die Notwendigkeit einer Sensibilisierung für Fragen des Datenschutzes.

  • Ebenfalls eine Frage der Organisationsentwicklung ist die Förderung eines Kulturwandels in der Lehre, der Selbstorganisation und Selbstbestimmung der Lernenden stärkt. Das setzt jedoch zunächst einen grundlegenderen Wandel hin zu einer noch größeren Verbreitung von Online‐Lehr‐/Lernangeboten voraus. Die PLE unterstützt dies durch die Schaffung von Mehrwerten gegenüber den bisherigen Insellösungen, was die Attraktivität und Akzeptanz erhöht und dadurch den Wandel beschleunigen hilft.

  • Als letzte Forderung wird die Interoperabilität der Lernplattform und der PLE benannt, wobei in dem hier beschriebenen System über den reinen Austausch von Daten bzw. die Kopplung von Funktionen hinaus eine enge, aber dennoch flexible Integration verschiedenster Dienste innerhalb der Hochschule, aber auch darüber hinaus erreicht wird.

Aus technischer und pädagogischer Perspektive wird die geschaffene Lösung also den an sie zu stellenden Anforderungen gerecht. Inwiefern sich dadurch eine qualitative Verbesserung der unterstützten Lehr‐/Lernprozesse erreichen lässt, müssen nun ausführliche Evaluationen im Produktivbetrieb zeigen. Bis zu einem breiten Einsatz in der gesamten Hochschule sind jedoch begleitend auch Herausforderungen im Bereich des Change Managements zu meistern.

Anhand der dargestellten Vorgehensweise wird eine Übertragung des Ansatzes (jenseits einer bloßen Übertragung der technischen Lösung) auf andere Hochschulen vereinfacht. Als Ausgangspunkt steht zunächst die Beantwortung der identifizierten Kernfragen (vgl. Abschnitt 3.1) vor dem Hintergrund der lokalen Gegebenheiten. Darauf aufbauend können ggf. bekannte Anforderungen von Nutzenden (vgl. Abschnitt 3.2) und spezifische Lehr-/Lernszenarien (vgl. Abschnitt 3.3) formuliert werden. Unerlässlich ist anschließend die Festlegung von führenden, zu synchronisierenden oder zu deaktivierenden Funktionen der einzubindenden Dienste mit Blick auf die vorhandene IT-Strategie, -Infrastruktur und -Kompetenz der jeweiligen Hochschule. Hierbei können die in diesem Beitrag geschilderten Arbeiten als Orientierung dienen, und insbesondere der in Abschnitt 4 beschriebene Prozess fördert einen zielgerichteten Gestaltungsprozess ‒ von der grundlegenden Idee bis hin zur praktischen Nutzung, eingebettet in einen kontinuierlichen Feedback- und Innovationsprozess.

Die Einführung der PLE als eine leistungsfähige, komfortable und den heutigen Medien‐Ökosystemen entsprechende Arbeitsumgebung eröffnet Lehrenden und Studierenden vielfältige Potentiale. Sie ermöglicht eine Steigerung von Funktionalität, Transparenz und Selbststeuerung, womit zugleich die Hoffnung auf eine Kompetenzsteigerung verbunden ist. Unabhängig davon bringen das offene System und seine Präsentations‐ und Vernetzungsmöglichkeiten (z.B. E‐Portfolio und Social Software) eine Erleichterung mit Blick auf den Bologna‐Prozess und mögliche Hochschulwechsel mit sich. Auch für die Hochschulen selbst ergeben sich strategische Vorteile. Die Kooperation mit externen Einrichtungen wird erleichtert; die Dienste der PLE können über den öffentlichen USB als Angebot an Dritte (ggf. gegen Entgelt) bereitgestellt werden. Auch im Studierendenmarketing wird das Erschließen neuer Zielgruppen unterstützt, was zur Öffnung der Hochschulen beiträgt. Zugleich wird die Durchgängigkeit von Lehre und Forschung gefördert und so deren Qualität gesteigert.

Über das in diesem Artikel beschriebene System hinaus sollen zwei weitere Entwicklungen erwähnt werden: Die Aufbereitung der Schnittstellen von IT‐Angeboten der Hochschule als Web‐Services ermöglicht es, auch aus anderen Nutzungskontexten heraus darauf zuzugreifen, sodass z.B. mobile Apps auf einfache Weise darauf aufsetzen können (Kiy, Grünewald et al. 2014). Zudem kann die Integration verschiedenster E‐Learning‐Dienste in ein durchgängiges System als Data Warehouse aufgefasst werden, sodass Learning‐Analytics‐Werkzeuge eine aussagekräftige Datenbasis vorfinden (Kiy & Lucke 2014).

Diese Perspektiven unterstreichen die Relevanz des Themas für Hochschulen, die sich auch im digitalen Zeitalter als Treiber von Innovation verstehen. Daher wurde bei den beschriebenen Arbeiten darauf geachtet, dass die identifizierten Anforderungen, das realisierte System und dabei verfolgte Vorgehensweise auf andere Hochschulen übertragbar sind. Dazu soll auch dieser Artikel einen Beitrag leisten.

Danksagung

Die beschriebenen Arbeiten wurden z.T. vom Bundesministerium für Bildung und Forschung im Qualitätspakt Lehre finanziert. Wir danken den anderen Mitgliedern der PLE‐Arbeitsgruppe aus dem Projekt eLiS und der AG E‐Learning der Universität Potsdam, die maßgeblich zur Anforderungserhebung und Konzeption für die geschilderte PLE‐Entwicklung beigetragen haben: Franka Grünewald, Michael Krause, Christoph Otto, Alexander Knoth, Julian Dehne, Maren Schulze, Marlen Schumann und Luise Henze.

Literatur

Albrecht, Rainer et al.: Technische und organisatorische Rahmenbedingungen für eine erfolgreiche Einführung und nachhaltige Nutzung von E‐Learning an Hochschulen. Göttingen : DINI – Deutsche Initiative für Netzwerkinformation e.V., 2005.

Allert, Heidrun; Richter, Christoph: Designentwicklung. Anregungen aus Designtheorie und Designforschung. In: Ebner, Martin; Schön, Sandra (Hrsg.): Lehrbuch für Lernen und Lehren mit Technologien. Epubli, Berlin, 2011. http://l3t.eu/homepage/das-buch/ebook/kapitel/o/id/50/name/designentwicklung (last check 2014-12-17)

Attwell, Graham; Heinemann, Lars; Deitmer, Ludger; Kämäräinen, Pekka: Developing PLEs to support work practice based learning. In: eLearning Papers, Vol. 35, 2013, pp. 1–8. http://www.openeducationeuropa.eu/sites/default/files/asset/From‐field_35_1.pdf (last check 2014-12-17)

Leigh Blackall: Die LMS die! You too PLE! 2005. http://teachandlearnonline.blogspot.de/2005/11/die‐lms‐die‐you‐too‐ple.html (last check 2014-12-17)

Blakley, Jim: Strategic Thinking ‒A High‐Tech Strategy Guidebook. Institute of Electrical and Electronics Engineers, New York, 2006.

Bode, Arndt; Borgeest, Rolf (Hrsg.): Informationsmanagement in Hochschulen. Springer, Berlin , 2010.

Boehm, Barry W.: A Spiral Model of Software Development and Enhancement, 1988. http://www.dimap.ufrn.br/~jair/ES/artigos/SpiralModelBoehm.pdf (last check 2014-12-17)

Buchem, Ilona; Attwell, Graham; Torres, Ricardo: Understanding Personal Learning Environments: Literature review and synthesis through the Activity Theory lens, 2011. http://de.scribd.com/doc/62828883/Understanding‐Personal‐Learning‐Environments‐Literature-review‐and‐synthesis‐through‐the‐Activity‐Theory‐lens (last check 2014-12-17)

Couros, Alec: Developing Personal Learning Networks for Open and Social Learning. In: Veletsianos, G. (Hrsg.): Emerging Technologies in Distance Education. UBC Press 2010, pp. 109–128. http://www.aupress.ca/books/120177/ebook/06_Veletsianos_2010-Emerging_Technologies_in_Distance_Education.pdf (last check 2014-12-17)

Downes, Steven: E‐Learning 2.0. In: eLearn Magazin, 2005. http://elearnmag.acm.org/featured.cfm?aid=1104968 (last check 2014-12-17)

Drummer, Jens; Hambach, Sybille; Kienle, Andrea; Lucke, Ulrike; Martens, Alke; Müller, Wolfgang; Rensing, Christoph; Schroeder, Ulrik; Schwill, Andreas; Spannagel, Christian; Trahasch, Stephan: Forschungsherausforderungen des E‐Learning. In: Rohland, Holger; Kienle, Andrea; Friedrich, Steffen (Hrsg.): Proc. Die 9. e‐Learning Fachtagung Informatik (DeLFI 2011). Köllen, Bonn , 2011, pp. 197-208.

Ebner, Martin; Taraghi, Behnam: Personal Learning Environment for Higher Education – A First Prototype. In: Proc. of World Conference on Educational Multimedia, Hypermedia and Telecommunications 2010. Toronto, Canada, 2010, pp. 1158–1166. http://www.editlib.org/p/34779 (last check 2014-12-17)

Fiedler, Sebastian; Väljataga, Terje: Personal learning environments: Concept or technology? In: International Journal of Virtual and Personal Learning Environments (IJVPLE), 2(4), 2011, pp. 1–11.

Gaiser, Birgit: Lehre im Web 2.0–Didaktisches Flickwerk oder Triumph der Individualität. In: e-teaching.org, Portalbereich Didaktisches Design, 2008. http://www.e-teaching.org/didaktik/kommunikation/08‐09‐12_Gaiser_Web_2.0.pdf (last check 2014-12-17)

Gaiser, Birgit; Thillosen, Anne: Hochschullehre 2.0 zwischen Wunsch und Wirklichkeit. In: Apostolopoulos, Nicolas (Hrsg.): E‐Learning 2009: Lernen im digitalen Zeitalter. Waxmann Verlag, Münster, 2009, pp. 185– 196.

von der Heyde, Markus: CIO‐Modelle an deutschen Hochschulen ‐Umsetzung der IT‐Governance. In: Proc. Jahrestagung der Gesellschaft für Informatik. Köllen, Bonn , im Druck.

Hilse, Michael; Lucke, Ulrike: Systematische Verankerung von E‐Learning in der Breite der Hochschule. In: Berendt, Brigitte; Fleischmann, Andreas; Wildt, Johannes; Schaper, Niclas; Szczyrba, Birgit (Hrsg.): Neues Handbuch Hochschullehre, Nr. D 3.26. Raabe, Berlin, 2013.

Issing, Ludwig J.: Instruktions‐Design für Multimedia. In: Issing, Ludwig J.; Klimsa, Paul (Hrsg.): Information und Lernen mit Multimedia. Beltz, Weinheim, 2002, pp. 151–176.

Ludwig, Joachim: Fallstudien. In: Zeitschrift für Weiterbildungsforschung, Nr. 2, 2005, pp. 51-60. http://opus.kobv.de/ubp/volltexte/2008/1833/ (last check 2014-12-17)

Kerres, Michael: Gestaltungsorientierte Mediendidaktik und ihr Verhältnis zur Allgemeinen Didaktik. In: Dieckmann, Bernhard; Stadfeld, Peter (Hrsg.): Allgemeine Didaktik im Wandel. Klinkhardt, Bad Heilbrunn, 2005, pp. 214‐234. http://mediendidaktik.uni-due.de/sites/default/files/mdidaktikkerres_0.pdf (last check 2014-12-17)

Kerres, Michael; Stratmann, Jörg; Ojstersek, Nadine; Preußler, Annabell: Digitale Lernwelten in der Hochschule. In: Hugger, Kai‐Uwe; Walber, Markus (Hrsg.): Digitale Lernwelten : Konzepte, Beispiele und Perspektiven. Verlag für Sozialwissenschaft, Wiesbaden , 2010, pp. 141‐156.

Kiy, Alexander; Grünewald, Franka; Zoerner, Dietmar; Lucke, Ulrike: Ein Hochschul‐App‐Framework: Hybrid und modular. In: Proc. Die 12. e‐Learning Fachtagung Informatik der Gesellschaft für Informatik (DeLFI 2014). Köllen Verlag, Bonn, 2014.

Kiy, Alexander; Lucke, Ulrike: Learning‐Analytics‐Werkzeuge im Praxisvergleich. In: Proc. DeLFI Workshops 2014. CEUR, Aachen , pp. 104‐111.

Kiy, Alexander; Lucke, Ulrike; Zoerner, Dietmar: An Adaptive Personal Learning Environment Architecture. In: Maehle, Erik; Römer, Kay; Karl, Wolfgang; Tovar, Eduardo (Hrsg.): Proc. Int. Conf. on Architecture of Computer Systems (ARCS). Springer, Berlin, 2014, pp. 60‐71.

Kopp, Michael; Ebner, Martin; Nagler, Walther; Lackner, Elke: Technologie in der Hochschullehre ‐Rahmenbedingungen, Strukturen und Modelle. In: Ebner, Martin; Schön, Sandra (Hrsg.): Lehrbuch für Lernen und Lehren mit Technologien .TU Graz, 2013.

Lucke, Ulrike; Specht, Markus: Mobilität, Adaptivität und Kontextbewusstsein im E‐Learning. In: i‐com ‒ Zeitschrift für interaktive und kooperative Medien, Vol. 11, Nr. 01. Oldenbourg Wissenschaftsverlag, München, 2012, S. 26‐29.

Lucke, Ulrike; Tavangarian, Djamshid: Aktueller Stand und Perspektiven der eLearning‐Infrastruktur an deutschen Hochschulen. In: Eibl, Christian J.; Magenheim, Johannes; Schubert, Sigrid E.; Wessner, Martin (Hrsg.): Proc. Die 5. e‐Learning Fachtagung Informatik (DeLFI 2007). Köllen Verlag, Bonn, 2007, pp. 197‐208.

Margaria, Tiziana; Hinchey, Mike: Simplicity in IT ‒The Power of Less. In: Computer. IEEE, New York, 2013, pp. 23‐25.

Mayrberger, Kerstin: Lernen und Prüfen mit E‐Portfolios. In: Meyer, Thorsten; Mayrberger, Kerstin; Münte‐Goussar, Stephan; Schwalbe, Christina (Hrsg.): Kontrolle und Selbstkontrolle. Zur Ambivalenz von E‐Portfolios in Bildungsprozessen. VS. Kontrolle und Selbstkontrolle, Wiesbaden, 2011, pp. 251‐280.

Meishar‐Tal, Hagit; Kurtz, Gila; Pieterse, Efrat: Facebook Groups as LMS: A Case Study. In: The International Review of Research in Open and Distance Learning, 13(4), 2012, pp. 33–48.

Reinmann, Gabi: Didaktisches Design ‐Von der Lerntheorie zur Gestaltungsstrategie. In: Ebner, Martin; Schön, Sandra (Hrsg.): Lehrbuch für Lernen und Lehren mit Technologien. Epubli, Berlin 2011. http://l3t.eu/homepage/das‐buch/ebook/kapitel/o/id/18/name/didaktisches‐design (last check 2014-12-17)

Reinmann, Gabi: Didaktisches Design ‐Studientext, 2013. http://gabi‐reinmann.de/wp-content/uploads/2013/06/Studientext_DD_April13.pdf (last check 2014-12-17)

Schaffert, Sandra; Hilzensauer, Wolf: On the way towards Personal Learning Environments ‒Seven crucial aspects. In: eLearning Papers, Nr. 9, 2008.

Schaffert, Sandra; Kalz, Marco: Persönliche Lernumgebungen: Grundlagen, Möglichkeiten und Herausforderungen eines neuen Konzeptes. In: Wilbers, Karl; Hohenstein, Andreas (Hrsg.): Handbuch E‐Learning. Deutscher Wirtschaftsdienst, Cologne, Deutschland, 2008, pp. 1‐24.

Schulmeister, Rolf: eLearning ‒Einsichten und Aussichten. Oldenbourg Wissenschaftsverlag, München , 2006.

Schulmeister, Rolf: Der Schlüssel zur Medienkompetenz liegt im Begriff der Kontrolle. In: Zeitschrift für E‐Learning, 7(4), 2012, pp. 35‐45.

Schultz, Elmar (Hrsg.): Herausforderung Web 2.0. Beiträge Zur Hochschulpolitik. Hochschulrektorenkonferenz, Bonn, 2010.

Seel, Norbert M.: Instruktionsdesign: Modelle und Anwendungsgebiete. 1999. http://nbn‐resolving.de/urn:nbn:de:0111‐opus‐77259 (last check 2014-12-17)

Strehl, Bernhard: Einsatz von und Probleme mit Portalsoftware am Beispiel einer universitären Lehr‐Lernplattform. In: Desel, Jörg; Haake, Jörg M.; Spannagel, Christian (Hrsg.): Proc. Die 10. e‐Learning Fachtagung Informatik der Gesellschaft für Informatik (DeLFI 2012). Köllen Verlag, Bonn , 2012, pp. 303‐314.

Taraghi, Behnam: Ubiquitous Personal Learning Environment (UPLE). In: International Journal of Emerging Technologies in Learning, 7(2), 2012, S. 7–14.

Wannemacher, Klaus: Soziale Medien in der Hochschulpraxis – noch studentisch dominiertes Terrain? In: Stratmann, Friedrich (Hrsg.): IT und Organisation in Hochschulen. HIS Hochschul-Informations‐System GmbH, Hannover, 2013, pp. 43‐51.

Wilms, Marcus (Hrsg.): Cloud‐Dienste. Addendum zu den Empfehlungen der Kommission für IT Infrastruktur. Deutsche Forschungsgemeinschaft, Bonn, 2014.

Zhou, Hong: Understanding Personal Learning Environment: A Literature Review on Elements of the Concept. In: McBride, Ron; Searson, Michael (Hrsg.): Proc. of Society for Information Technology & Teacher Education International Conference, 2013, pp. 1161‐1164.

Zierer, Klaus; Seel, Norbert M.: General Didactics and Instructional Design. 2012. http://www.springerplus.com/content/1/1/15 (doi:10.1186/2193‐1801‐1‐15) (last check 2014-12-17)