Der finale Seminarband des kooperativen Seminars FSLN10 der Universitäten Paderborn und Augsburg im Sommersemester 2010.

1. Future Social
Learning Networks
Ein Seminar an den Universitäten Paderborn und
Augsburg im Sommersemester 2010
Betreuer: Nina Heinze & Wolfgang Reinhardt

3. Contents
Real-Time Collaborative Learning
Rolf Wilhelm (UPB)
brix@mail.upb.de 3
Medienbrüche im Web 2.0
Dennis Horstkemper (UPB) & Marie-Luise Zankl (UA)
dhorstkemper@gmail.com, mazankl@gmx.net 33
Awareness in Learning Networks
Christian Metzko (UPB)
letris@upb.de 69
Interaktive Lernressourcen
Felix Meyer (AU) & Alexander Schäfer (UPB)
f.meyer1@gmx.de, alexx85@mail.upb.de 99
Soziale Netzwerkanalyse in Artefact-Actor-Networks
Matthias Moi (UPB)
moisun@upb.de 118
Game-based Learning
Eva Andreeva (AU) & Sebastian Lauck (UPB)
eva_andreeva@gmx.de, Sebastian.Lauck@lwf.uni-paderborn.de 162
Universität 2.0
Julia Schuhwerk (AU) & Manuel Schmidt (UPB)
julia.schuhwerk@googlemail.com, schmidti@upb.de 187
3

4. Contents
4

5. Real-Time Collaborative Learning
Rolf Wilhelm
brix@mail.uni-paderborn.de
Abstract: In der universit¨ ren Lehre werden aktuelle M¨ glichkeiten synchroner Mo-
a o
delle des Web 2.0 zur Kollaboration bisher kaum genutzt. Sofern Dienste existie-
ren, die auf aktuellen Technologien basieren, sind diese nur durch einen engen Kreis
oder Angeh¨ rige der Universit¨ t nutzbar. Diese Arbeit stellt eine L¨ sung vor, die ver-
o a o
schiedene Dienste zur kollaborativen Arbeit in einer Mashup-Anwendung vereint, um
Dienste miteinander kombinieren zu k¨ nnen. Reduzierung von Medienbr¨ chen und
o u
die Ausrichtung auf kollaborative Arbeit sind Leitkriterien der Umsetzung. Lauff¨ hig
a
ist die Anwendung in einem Browser. Man begibt sich aber nicht auf eine Webseite,
sondern auf eine Plattform, die gemeinsames Lernen und Arbeiten unterst¨ tzt. Wel-
u
che Dienste eingebunden werden und wie dies bereits zum Teil in einem Prototypen
umgesetzt wurde, ist Teil der Arbeit.
1 Einleitung
Die vorliegende Arbeit gibt einen Einblick in die M¨ glichkeiten des Web 2.0 und wie ver-
o
schiedene Dienste zum Lernen eingesetzt werden k¨ nnen. Lernen findet zunehmend mit
o
Hilfe des Computers statt. Materialien wie B¨ cher und Aufzeichnungen k¨ nnten z. B. mit
u o
entsprechender Ausr¨ stung digital auf einem Computer genutzt und bearbeitet werden.
u
Soziale Netzwerke geben die M¨ glichkeit, sich auszutauschen, in Kontakt zu bleiben und
o
sogar zu lernen.1 Innerhalb des letzten Jahrzehnts hat das Internet eine Flut an webbasier-
ten Diensten hervorgebracht. Als Internetnutzer sucht man sich Dienste f¨ r Email, Fotos
u
und mehr zusammen und nutzt diese meist unabh¨ ngig voneinander. Auch zum Lernen
a
k¨ nnen soziale Netzwerke und diverse Dienste genutzt werden. Wie soziale Netzwerke
o
und andere Dienste miteinander in einer Anwendung kombiniert werden k¨ nnen, darauf
o
gibt diese Arbeit eine Antwort.
Lernen in der Gruppe. In einer Gruppe lernt es sich besser als allein. Außerdem ist der
Kontakt zu anderen und der andauernde Austausch f¨ rs Lernen unerl¨ sslich. Die folgen-
u a
den Effekte, in [TD03] zus¨ tzlich durch ihren psychologischen Hintergrund unterstrichen,
a
resultieren aus der Gruppenarbeit:
• Steigerung der Motivation durch soziale Unterst¨ tzung und Verpflichtung
u
• Steigerung der Kreativit¨ t
a
• Steigerung der Qualit¨ t der Ergebnisse
a
• Lernen von Teamarbeit
1 [Pet10]
5

6. ¨
• Uberpr¨ fung des eigenen Wissens
u
• Aufdecken von Missverst¨ ndnissen
a
Diese Arbeit besch¨ ftigt sich mit einer Antwort auf die Frage, wie man die Gruppenarbeit
a
mit Hilfe aktueller Technologien unterst¨ tzen kann. Ausgegangen wird hier in erster Linie
u
davon, dass Gruppenmitglieder nicht am selben Ort sind, wenn ein Treffen stattfindet. Ein
positives Fazit in dieser Richtung kann schon jetzt aus einer Metastudie gezogen werden:
Sch¨ ler von Kursen, die zum Teil oder komplett online und am Computer gehalten wur-
u
den, lernten im Durchschnitt besser als Sch¨ ler in Kursen, die nur face-to-face Unterricht
u
hatten [MTMB09]. Auch wenn es in den Studien nicht speziell um Gruppenarbeit ging,
so zeigt dies doch auf, dass E-Learning durchaus eine positive Auswirkung aufs Lernen
haben kann. Hier wird nun der Fokus auf kollaboratives Lernen geschoben. Im folgenden
Abschnitt wird auf weitere Grundlagen der Gruppenarbeit und Technologien eingegangen,
bevor der Prototyp vorgestellt wird.
2 Grundlagen
Arbeitsbereiche. B¨ cher, Aufzeichnungen und ein Computer definieren den pers¨ nlichen
u o
Arbeitsbereich eines jeden. Dieser pers¨ nliche Arbeitsbereich wird mit einem Treffen
o
a a ¨
h¨ ufig zum Arbeitsbereich der gesamten Gruppe. Er dient der Verst¨ ndigung uber den
Lernstoff und gew¨ hrt jedem den Zugriff darauf. Wird sich nicht am selben Ort, sondern
a
online getroffen, fehlt ein gemeinsamer Arbeitsbereich in dieser Form meist. Ein solcher
¨
Arbeitsbereich geht uber einen gemeinsamen Informationsraum nach [TSMB95] deutlich
hinaus. W¨ hrend mit einem gemeinsamen Informationsraum im Wesentlichen der lesende
a
gemeinsame Zugriff auf ein Informationsobjekt gemeint ist, beinhaltet der gemeinsame
Arbeitsbereich auch kooperative Medienfunktionen ([Ham01]), die durch ihre Einschreib-
technologien beschr¨ nkt werden.
a
Online. Gruppen, die sich nicht an einem Ort in der ”realen”Welt treffen, k¨ nnen oder
o
wollen, haben heute die Wahl das Internet zu nutzen. Asynchronen Austausch erm¨ glicht
o
¨
bspw. ein Forum. Synchron kann sich z. B. uber Voice/Videochats ausgetauscht werden.
W¨ hrend f¨ r die bloße Kommunikation in ihrer Grundform gesorgt ist, fehlt ein gemein-
a u
samer Arbeitsbereich. Der pers¨ nliche Arbeitsbereich jedes Einzelnen ist f¨ r die anderen
o u
nicht direkt sichtbar und somit m¨ ssen Aufzeichnungen erneut verbalisiert oder verschrift-
u
licht werden, um auf eine gemeinsame Wissensbasis zu gelangen. Hier gibt es weitere Un-
terst¨ tzungsm¨ glichkeiten, die z. B. von Groupware- und Videoconferencing-Systemen
u o
genutzt werden, indem sie einen gemeinsamen Arbeitsbereich in Form von gemeinsamen
Dokumenten oder einem Whiteboard bereitstellen.
Synchron. Ein Problem asynchroner Kommunikation besteht darin, dass eine R¨ ckmel-
u
dung immer verz¨ gert erfolgt, und somit bspw. die Motivation nachlassen kann. Der syn-
o
chrone Austausch der Teilnehmer unterst¨ tzt dagegen die folgenden Szenarien [Fin06]:
u
• Direkter Kontakt zu Wissensexperten2 und anderen Teilnehmern
2 Definition hier: Eine Person, die durch genauere Auseinandersetzung im Rahmen einer Aufgabe Wissen
erworben hat, welches die anderen Teilnehmer (noch) nicht haben.
6

7. • Gleichzeitiger Austausch zwischen verschieden Teilnehmern
• F¨ higkeiten, Kenntnisse und analytisches Denken werden direkt ben¨ tigt
a o
• Einbeziehung von Experten3
¨
Technik nutzen. Seit uber 15 Jahren gibt es verschiedene computergest¨ tzte Hilfsmit-
u
tel wie ein Shared Whiteboard oder Videoconferencing Systeme. Lange Zeit musste f¨ r u
solche Funktionalit¨ ten eine extra Anwendung genutzt werden, die nur diesem Zweck
a
diente. Die Technik und die Bedingungen haben sich seitdem verbessert. In vielen mobilen
Endger¨ ten befindet sich inzwischen Kamera und Mikrofon und die Ger¨ te bieten ausrei-
a a
chend Rechenkapazit¨ t um einen Videochat oder ein Shared Whiteboard zu nutzen. Hinzu
a
kommt, dass seit mehreren Jahren praktikable Umsetzungen dieser Technologien im In-
ternet zur Verf¨ gung stehen. Als Webanwendung k¨ nnen diese Dienste in einem Browser
u o
ausgef¨ hrt werden. Durch derzeitige Technologien ist es einfacher denn je, eine synchrone
u
¨
Arbeitsumgebung zu nutzen und in einer Gruppe uber Distanzen hinweg zu arbeiten und
zu lernen. Im einfachsten Fall muss lediglich die Adresse im Browser angegeben werden
und schon kann es losgehen. Eine Installation ist nicht mehr notwendig.4
Computer Supported Collaborative Learning. Computerunterst¨ tztes kollaboratives Ler-
u
¨
nen uber Distanzen hinweg ist kein neues Thema, doch durch neue Technologien sind
inzwischen weitere Szenarien realisierbar. Ausgangspunkt ist hier das Web 2.0 mit einer
F¨ lle an verschiedenen Diensten. Im Sinne, das Rad nicht neu zu erfinden, gibt es die
u
M¨ glichkeit, vorhandene Dienste zu nutzen und neu zu kombinieren.
o
Mashup. Ein Mashup definiert sich im Wesentlichen durch die Kombination von zwei
oder mehr eigenst¨ ndigen Diensten oder Datenquellen, die in einer Anwendung integriert
a
werden. Dabei werden Schnittstellen genutzt, die von anderen Diensten zur Verf¨ gung
u
gestellt werden. In [PSB+ 09] ist ein Mashup definiert, als eine Plattform die eine Kom-
bination einer Vielzahl von Softwarekomponenten5 erm¨ glicht. In dem Paper liegt der
o
Fokus auf der Personal Learning Environment (PLE).6 In dieser Arbeit wird eine Mashup-
¨
Anwendung vorgestellt, welche uber Funktionen von Web Conferencing und PLE hinaus-
gehen soll. Durch die Einbindung verschiedener Dienste soll sowohl das Selbststudium,
als auch Gruppenarbeit erm¨ glicht werden. Vertrauen wird geschaffen durch entsprechen-
o
¨
de Rechteverwaltung. Daten werden weitestgehend uber externe Dienste persistiert, was
die Arbeit auch außerhalb der Umgebung gestattet und weitere Teilnehmer einl¨ dt am Ge-
a
schehen teilzuhaben, ohne die Mashup-Anwendung zu nutzen.
Social Software erm¨ glicht menschliche Kommunikation und Kollaboration. Durch
o
Mitwirkung von Teilhabenden wird im weitesten Sinne einen Mehrwert geschaffen.[B06]¨
Der Einsatz von Social Software soll als Katalysator dienen und Motivation und Engage-
ment der Teilhabenden unterst¨ tzen. Die Verbindung zwischen Social Software und der
u
¨
Lernumgebung muss fließend ineinander ubergehen, damit nicht das Gef¨ hl entsteht, dass
u
¨ ¨
3 Uber das Internet ist es zum einen m¨ glich einen Experten an einem anderen Ort zu einzubeziehen. Uber die
o
synchrone Kommunikation kann zum anderen auf Missverst¨ ndnisse oder Verst¨ ndnisprobleme direkt eingegan-
a a
gen werden, was bei asynchronem Austausch l¨ nger dauern w¨ rde.
a u
4 Voraussetzung f¨ r einige Szenarien ist eine schnelle Anbindung ans Internet. Sowohl die Bandbreite als auch
u
die Latenz der Verbindung ist hier von Bedeutung.
5 auch Widgets, Plugins, Gadgets oder Tools genannt
6 Bei [PSB+ 09] werden 6 Dimensionen mit 24 Funktionen definiert, woraufhin die Funktionen auf ihre
Verf¨ gbarkeit hin auf sechs verschiedene Dienste angewendet werden.
u
7

8. es sich um verschiedene Medien oder Plattformen handelt (Medienbr¨ che).7 Da Social
u
Software inzwischen den Alltag eines Studenten durchdringt, kann hierauf beim Lernen
effizient zur¨ ckgegriffen werden. Die Pr¨ sentation [Pet10] von Jim Pettiward von der Lon-
u a
don Metropolitan University zeigt Engagement bei Lernenden durch Nutzung von Face-
book auf. Auf der Grundlage, dass Lernende viel Zeit auf Facebook verbringen, wurden f¨ r
u
¨
Kurse Facebook Seiten angelegt, uber die eine Integration in die pers¨ nlichen Seiten der
o
Lernenden m¨ glich ist. Hier wird ausschließlich Facebook genutzt, was Vor- und Nach-
o
teile hat. Facebook ist einer der wenigen Plattformen, auf denen etwas derartiges Nutzen
bringen kann, denn eine Online Community funktioniert nur richtig, wenn sie eine kriti-
sche Masse von Mitgliedern ubersteigt.8 Die Mashup-Anwendung kann wiederum auch
¨
als Social Software angesehen werden. Palm´ r ([PSB+ 09]) spricht von einer h¨ heren Ge-
e o
¨
wichtung der Integration von RSS Feeds und anderen Diensten uber Schnittstellen in den
letzten Jahren, die eine Verkn¨ pfung zwischen der PLE und Social Software herstellt.
u
Ziel. In der Lehre oder einer Lernsituation sollten Dienste9 entsprechend den Anforderun-
gen, die sich durch die Aufgabenstellung definieren, verf¨ gbar sein. Die Implementierung
u
m¨ glichst vieler Features ist hier nicht gleichzusetzen mit einer h¨ heren Effizienz oder
o o
Engagement. Eine problemorientierte Auswahl von Tools in einer Anwendung erm¨ glicht o
eine Steigerung der Motivation und f¨ rdert die Effizienz bei den Teilhabenden. Der Imple-
o
mentierung einer vollst¨ ndigen Mashup-Anwendung m¨ sste die Analyse verschiedener
a u
Lern- und Lehrszenarien durchgef¨ hrt werden, um zu bestimmen, welche Tools sinnvoll
u
sind. Weiterf¨ hrende Informationen zu Engagement und Motivation f¨ r Videoconferen-
u u
cing findet sich in [Smy05] und f¨ r Shared Whiteboards in [Bee02]. Empirische Ergebnis-
u
se zu bestimmten Technologien w¨ ren w¨ nschenswert, sind aber auf diesem Feld kaum
a u
zu finden. Schlussfolgerungen auf den Einsatz im Mashup sind allerdings nicht unbedingt
zu ziehen, da verschiedene Kombinationen sich auch verschiedenen auswirken k¨ nnen. o
Durch die Kombination von Videoconferencing und Shared Whiteboard entsteht ein Mehr-
wert, der bei alleiniger Betrachtung der Dienste nicht vorhanden ist. Da die Auswahl der
Tools zur Laufzeit erfolgt, ist hier die Gefahr von Featuritis10 nicht unbedingt vorhanden.
Es sollen zwar eine hohe Anzahl von Diensten eingebunden werden k¨ nnen, doch zum
o
¨
Einsatz kommen in einem Szenario nur ausgew¨ hlte Dienste. Ahnlich der derzeitigen Ent-
a
wicklung des Vertriebs von Anwendungen f¨ r Handys oder der Verwendung von Gadgets
u
in Google Wave, k¨ nnen auch f¨ r die Mashup-Anwendungen Gadgets entstehen, die ge-
o u
nutzt (oder entwickelt) werden, wenn sie ben¨ tigt werden.
o
7 Dasselbe gilt f¨ r jeden anderen Dienst, der in dem Mashup integriert wird. Aufgrund der h¨ heren un-
u o
abh¨ ngigen Nutzung von Social Software auch außerhalb der Mashup-Anwendung wird es hier als besonders
a
wichtig anerkannt.
¨
8 [B06] und A community needs a critical mass of members for it to work.“[Min09]
9 Dienste k¨ ”
onnen im weiteren Sinne Tools, Widgets, Gadgets, Plugins oder von anderer Form sein. Gemeint
ist jede Form der Bereitstellung einer unterst¨ tzenden Funktion.
u
10 Definition: Die Vielzahl von attraktiven Tools, die kumulativ dem grundlegenden Zweck der Software wi-
¨
dersprechen. a proliferation of individually attractive features that cumulatively.”[SB03]
8

9. 3 Chancen derzeitiger Technologien
Klassen von CSCW Anwendungen. Es existieren zahlreiche Anwendungen, welche sich
klassifizieren lassen als Web Conferencing (WC), Personal Learning Environments (PLE),
Virtual Learning Environments (VLE) oder Groupware (GW). Alle erm¨ glichen in ge-
o
wissem Maße synchrone Kollaboration. Die Tabelle 1 zeigt auf, in welchen Bereichen
Anwendungen der vorgestellten Klassen ihren Fokus haben und wo Funktionen weniger
vorhanden sind11 . Der Fokus liegt bei der Auswahl der Funktionen auf der synchronen
Zusammenarbeit. Unter anderem zeigt die Tabelle auf, dass Web Conferencing Systeme
bereits einen Großteil grundlegender, synchroner Kommunikationsfunktionen umsetzen.
F¨ r Tabelle 1 wurde je ein Vertreter f¨ r eine Systemklasse herangezogen, um ein Bild der
u u
Unterst¨ tzungsfunktionen im Gesamt¨ berblick zu erhalten. Die Wahl der Vertreter f¨ r je
u u u
eine Systemklasse sieht folgendermaßen aus:
• Web Conferencing: Adobe Acrobat Connect12
• Personal Learning Environment: PLEF Personal Learning Environment Framework13
• Groupware: Novell GroupWise14
• Virtual Learning Environment: Blackboard15
Web 2.0. Beispieldienste werden in Tabelle 1 in der zweiten Spalte aufgef¨ hrt, dass f¨ r je-
u u
de Funktion ein Dienst im Internet gefunden werden kann. Die Dienste sind meist auf
eine bestimmte Funktion spezialisiert, wodurch die Funktionen ausgereift und in sich
vollst¨ ndig erscheinen. Vertreter der Systemklassen haben mit ihren Funktionen im Ver-
a
gleich zu den Beispieldiensten meist weniger zu bieten.
VLE. Eine Befragung zeigt, dass VLEs bisher kaum f¨ r synchrone Lernsituationen ge-
u
eignet sind ([Kea07]).18 Die Befragung hat lediglich ergeben, dass Chatfunktionen zur
synchronen Kommunikation kaum genutzt worden sind und wenn diese genutzt wurden,
so war das Empfinden, dass diese schnell un¨ bersichtlich und unstrukturiert werden. Als
u
potenziell vorteilhaft wurden von den Befragten Chatr¨ ume und Whiteboards genannt.
a
¨
Unterstutzungsfunktionen. Bafoutsou ([BM02]) untersuchte 2002 verschiedene Syste-
me auf ihre Unterst¨ tzungsfunktionen und ordnete diese Klassen von Systemen zu. Diese
u
Systemklassen wurden ihren Unterst¨ tzungsfunktionen entsprechend in das Diagramm in
u
Abbildung 1 eingeordnet. Eine Darstellung wie in Abbildung 1 w¨ rde hier im Großen und
u
Ganzen nur einer Aufz¨ hlung von Funktionen entsprechen, weshalb wir nachfolgend eine
a
weitere Darstellung nutzen.
11 Daten der Tabelle beruhen nicht auf einer wissenschaftlichen Erhebung, noch erheben sie den Anspruch der
Vollst¨ ndigkeit. 1: Nicht oder kaum vorhanden, 2: In Ans¨ tzen vorhanden, 3: Funktion vorhanden.
a a
12 http://www.adobe.com/products/acrobatconnect
13 http://eiche.informatik.rwth-aachen.de:3333/PLEF/index.jsp
14 http://www.novell.com/de-de/products/groupwise/
15 http://www.blackboard.com
18 Unter den untersuchten VLEs sind Moodle, Blackboard und WebCT.
9

10. Realisierte Funktion Beispieldienste Grad der Umsetzung
WC PLE GW VLE
Shared Whiteboard Dabbleboard 3 1 1 3
Videoconferencing TokBox, ooVoo 3 1 1 1
Voicechat TinyChat, Tolkr 3 1 1 1
Textchat / IM Meebo 3 2 3 3
Shared Editor Etherpad 3 1 1 1
Screen Sharing LiveLook16 3 1 1 1
RSS Feeds FeedBurner 1 3 3 3
Microblogging Twitter, Buzz 1 1 1 1
Social Bookmarking Delicious, Digg, Diigo 1 1 1 2
Website Annotation Diigo, Reframe It, Sidewiki 1 1 1 1
Document Sharing Dropbox 2 1 1 2
Kalender Google Calendar 1 1 3 3
Pr¨ sentation
a Slideshare 2 217 1 1
Umfrage/Poll Doodle 3 1 2 3
Tabelle 1: Web 2.0 Dienste, Anbieter und Auspr¨ gung
a
In [PGF07] werden bei einem Projekt zur F¨ rderung von kollaborativer Arbeit Tools
o
verschiedenen Unterst¨ tzungsfunktionen zugeordnet. Mit Communication, Collaboration
u
und Coordination handelt es sich im Wesentlichen um das 3K-Modell nach [TSMB95]
(Abbildung 2), welches Systemklassen und Unterst¨ tzungsfunktionen in einem Klassifi-
u
kationsschema in Beziehung zueinander setzt. Neben diesen Klassen wird bei [PGF07]
Awareness extra aufgef¨ hrt und zwischen synchroner und asynchroner Funktion unter-
u
schieden. Eine vergleichbare Abdeckung verschiedener Unterst¨ tzungsfunktionen spielt
u
auch bei der Mashup-Anwendung eine wichtige Rolle. Wir nehmen eine Unterteilung
nach [TSMB95] vor, um zwischen Kommunikations-, Koordinations- und Kooperatios-
unterst¨ tzung zu unterscheiden. Hierzu mehr im Abschnitt 3.2.
u
Warum eine weitere Anwendung? Die Implementierung einer Mashup-Anwendung, die
keiner hier aufgef¨ hrten Systemklasse zugeordnet werden kann, bietet diverse Vorteile:
u
Tabelle 1 zeigt, dass auch bekannte kommerzielle Anbieter nur einen bestimmten Bereich
von Funktionen bedienen. Es werden Funktionen außer Acht gelassen, die f¨ r bestimm-
u
te Anwendungsf¨ lle notwendig sein k¨ nnen. Die Mashup-Anwendung kann zum einen
a o
beliebige Dienste in einer Umgebung integrieren, w¨ hrend der Aufbau der Anwendung
a
flexibel bleibt. Sowohl das Hinzuf¨ gen von Funktionen, als auch die Reduktion auf weni-
u
ge Funktionen stellt kein Problem dar. Zum anderen k¨ nnen Dienste, die bereits ausgereift
o
oder bekannt sind, bereitgestellt werden. So z. B. auch Daten oder Funktionen bestehen-
der Learning Management Systeme (LMS) oder sozialer Netzwerke wie Facebook. Daten
¨
werden uber eine Ober߬ che zentral abgerufen und eingegeben. Persistiert werden die-
a
se Daten weitestgehend innerhalb externer Dienste, was die Arbeit auch außerhalb der
Umgebung gestattet und weiteren Teilnehmern die M¨ glichkeit gibt auch außerhalb der
o
Mashup-Anwendung zu nutzen.
10

11. Abbildung 1: Unterst¨ tzungsfunktionen von Systemklassen ([BM02])
u
Flexibilit¨ t. Die Mashup-Anwendung wird nicht nur f¨ r ein bestimmtes Szenario er-
a u
stellt, da die St¨ rke darin liegt, prinzipiell jeden Dienst oder jede Funktion bereitstellen
a
zu k¨ nnen. Weiterhin muss sich der Nutzer nur um die Zusammenstellung eines Mashups
o
Gedanken machen.19 Da die Anwendung im Browser des Nutzers l¨ uft, sind keine weite-
a
ren Vorkehrungen beim Nutzer notwendig.20
Tor zur kollaborativen Arbeit. So wie die PLE nach [CJWS09] das Tor zum Wissen
f¨ r den Lernenden ist, so l¨ sst sich die hier beschriebene Mashup-Anwendung als ein Tor
u a
zur kollaborativen Arbeit bezeichnen. Eine PLE besteht aus technischer Sicht aus einer
selbst definierten Zusammenstellung von Diensten, Tools und Mitteln, die dem Lernen-
den helfen, sein pers¨ nliches Wissensnetzwerk aufzubauen.21 Auch die ein Mashup in der
o
Mashup-Anwendung besteht aus einer Zusammenstellung von Diensten, Tools und Mit-
teln, nur das hier die Ausrichtung auf kollaborativer Arbeit liegt.
3.1 Mashup Frameworks und Plattformen
Mashup Frameworks. In diversen Ver¨ ffentlichungen22 werden drei verschiedene Tools
o
zur Entwicklung von Mashups vorgestellt. Gerade mal zwei Jahre, bzw. ein Jahr nach
Ver¨ ffentlichung ist nur noch eins vorhanden. Microsoft Popfly wurde aufgrund der wirt-
o
19 Zus¨ tzlich
a werden Profile im Ausblick genannt
20 Untersuchungsergebnisse einer Studie zu Distance Learning von [RL08] haben ergeben, dass die zu nutzen-
de Anwendung auf verschiedenen Betriebssystemen lauff¨ hig und die Installation so einfach wie m¨ glich sein
a o
sollte.
21 From a technical point of view, a PLE can be viewed as a self-defined collection of services, tools, and
devices that help learners build their Personal Knowledge Networks (PKN), [...]”[CJWS09]
22 [YBCD08], [CJWS09] und [AENH09]
11

12. Abbildung 2: Unterst¨ tzungsfunktionen von Systemklassen ([TSMB95])
u
schaftlichen Lage August 2009 eingestellt23 und den Google Mashup Editor gibt es eben-
falls seit August 2009 nicht mehr. Ein großer Teil der gewonnenen Kenntnisse soll aber in
die Google App Engine24 eingeflossen sein. Lediglich Yahooo Pipes25 ist von den erw¨ hnten
a
Tools noch vorhanden. Bei Yahoo Pipes liegt der Schwerpunkt allerdings auf der Ag-
gregation von Daten und es bindet standardm¨ ßig nur eine Reihe bekannter Dienste ein
a
([CJWS09]). Im Fall der entstandenen Mashup-Anwendung ist Yahoo Pipes deshalb we-
niger zu gebrauchen gewesen.
EzWeb. Die offene Enterprise 2.0 Mashup Platform EzWeb ([LSR08], [BnM09]) bie-
tet eine lauff¨ hige Umgebung, die jeder Nutzer nach Belieben konfigurieren kann. Dank
a
Open-Source Lizenz ist es m¨ glich, selber einen solchen Server aufzusetzen und seinen
o
Bed¨ rfnissen anzupassen. Der Fokus liegt hier allerdings eher auf einer individuellen Ar-
u
beitsumgebungen, als auf der kollaborativen Zusammenarbeit. Mit der Entwicklung neuer
Gadgets26 w¨ re aber auch eine Umgebung zu realisieren, die den Anspr¨ chen kollabora-
a u
tiver Zusammenarbeit gen¨ gen k¨ nnte. Abbildung 3 zeigt einen Workspace mit verschie-
u o
denen Gadgets. Um bestimmte Gadgets zu definieren, dienen spezielle Konfigurationsda-
teien, die auch w¨ hrend der Laufzeit eingespielt werden k¨ nnen. Auch Ein- und Ausgabe
a o
kann f¨ r ein Gadget hier¨ ber definiert werden. Damit wird die Verbindung zwischen ver-
u u
schiedenen Gadgets m¨ glich. Diese Verbindung kann vor dem Einsatz vom Nutzer vorge-
o
nommen werden, wie Abbildung 4 zeigt.
Google Wave. Google Wave27 ist eine weitere M¨ glichkeit f¨ r die kollaborative, synchro-
o u
ne Zusammenarbeit. Hier liegt die St¨ rke in einer ad hoc zu erstellenden Umgebung, in der
a
Teilnehmende zusammenarbeiten k¨ nnen. Es werden sogenannte Waves erstellt, die erst
o
einmal mit einem Shared Editor vergleichbar sind, aber Multimediainhalte und Apps ent-
halten k¨ nnen und Echtzeitkommunikation erm¨ glichen. Wie eine Wave sich entwickelt
o o
23 http://www.heise.de/newsticker/meldung/Microsoft-Popfly-streckt-die-Fluegel-6897.html
24 http://code.google.com/intl/de-DE/appengine/
25 http://pipes.yahoo.com/pipes/
26 Gadgets werden hier die Applikationen genannt, die verschiedene Dienste einbinden
27 http://wave.google.com/
12

13. Abbildung 3: Enterprise 2.0 Mashup Platform EzWeb
¨
hat, kann uber Playback nachvollzogen werden, indem hier chronologisch der Verlauf der
Entstehung abgespielt werden kann. Zum Ende der Arbeit ver¨ ffentlichte Google die Mel-
o
dung, dass diese Plattform nicht mehr weiterentwickelt wird.28
3.2 Auswahl der Dienste
Das Hauptkriterium f¨ r die Wahl der Dienste ist die Vermeidung von Medienbr¨ chen,
u u
um den Arbeits- und Lernfluss nicht unn¨ tig zu unterbrechen. Verschiedene Funktionen,
o
wie sie in Tabelle 1 aufgef¨ hrt sind, wurden gew¨ hlt, um eine Umgebung zu schaffen,
u a
die Echtzeit-Koordination, -Kollaboration und -Kommunikation zwischen Lernenden ef-
¨
fizienter gestalteten l¨ sst. Abbildung 5 zeigt auf, dass die Dienste alle uber die Mashup-
a
Anwendung zugegriffen werden. Außerdem werden in der Abbildung verschiedene Nut-
¨
zergruppen dargestellt, die uber eine Person mit einem Handy, einem Computer bis hin zu
¨
einer Gruppe mit einem Beamer geht. Jeder eingebundene Dienst steht uber den Mashup-
Server in Verbindung mit jedem Einzelnen. F¨ r den Nutzer stellt sich die Anwendung als
u
eine dar, die Mashup-Anwendung.
Schnittstellen zu Diensten. Um verschiedene Dienste erfolgreich integrieren zu k¨ nnen,
o
muss auf Schnittstellen des Dienstes zur¨ ckgegriffen werden. Eine solche Schnittstelle
u
(API) wird leider nur von einer geringen Anzahl von Diensten bereitgestellt, was die Aus-
28 http://googleblog.blogspot.com/2010/08/update-on-google-wave.html (Zugriff 05.08.2010)
13

14. Abbildung 4: Verbindung von Gadgets auf der EzWeb Plattform
wahl von vornherein stark eingeschr¨ nkt hat.29 Die APIs der Dienste werden dazu genutzt
a
¨
um die Integration in der Mashup-Anwendung zu realisieren. Uber die API erfolgt die
Kommunikation zwischen dem Server, auf dem die Mashup-Anwendung installiert wird
und dem eingebundenen Dienst. Im Prototypen wurden Whiteboard, Videoconferencing
und RSS Feeds eingebunden. Im Folgenden wird auf diese n¨ her eingegangen.
a
3.2.1 Whiteboard – Dabbleboard
Im Abschnitt 2 wurde der gemeinsame Arbeitsbereich bei der Gruppenarbeit genannt.
Ein Teil des (nun virtuellen30 ) Arbeitsbereichs stellt ein Whiteboard dar. Es dient der
impliziten Kommunikation ([TSMB95]), stellt einen Teil kooperativer Medienfunktionen
([Ham01]) bereit und es ist der Systemklasse gemeinsamer Informationsr¨ ume in Abbil-
a
dung 2 zuzuordnen.
Es gibt inzwischen eine große Auswahl an frei zug¨ nglichen Whiteboard Diensten31 . Ein
a
Großteil bietet auch erweiterte Funktionen gegen Bezahlung an. Dabbleboard32 sticht hier
durch das Angebot einer frei zug¨ nglichen API und dem Funktionsumfang hervor.
a
3.2.2 Videoconferencing – TokBox
Die Kommunikationskan¨ le der Teilnehmer werden miteinander verbunden, indem jeder
a
die gesamte Kommunikation mitverfolgen kann. Hier wurde sich aufgrund der Machbar-
keit gleich f¨ r Videoconferencing entschieden. Zuzuordnen ist die Videoconferencing der
u
Systemklasse Kommunikation.
Es standen vier Dienste zur Auswahl die eine API bereitstellen: TokBox33 , PalBee34 ,
29 Andere M¨ glichkeiten, einen Dienst einzubinden existieren, sind allerdings weniger praktikabel und feh-
o
leranf¨ lliger
a
30 Im Vergleich zur kollaborativen Arbeit an einem Tisch.
31 http://www.imaginationcubed.com – http://www.skrbl.com/ – http://www.scribblar.com/ –
http://www.scriblink.com/ – http://www.scriblink.com/ – ...
32 http://www.dabbleboard.com/
33 http://www.tokbox.com
34 http://www.palbee.com
14

15. ¨
Abbildung 5: Verbindung zwischen Nutzern und Diensten uber Mashup-Server
BigBlueButton35 und OpenMeeting36 . Die letzten beiden sind Open Source und erlauben
¨
die Installation der Dienste auf dem eigenen Server. Beide verf¨ gen uber eine API, doch
u
die Einrichtung stellte sich als langwieriger als geplant heraus. PalBee ist schon bei der
Registrierung ausgeschieden, da nie ein Aktivierungscode an mich verschickt wurde. Nicht
nur deshalb fiel die Wahl auf TokBox. TokBox bietet eine sehr vollst¨ ndige API und stellt
a
sogar ein rudiment¨ res Python-Sktipt zur Anbindung zur Verf¨ gung.
a u
3.2.3 RSS Feeds – Twitter und Delicious
Microblogging sollte in den Prototypen Einzug erhalten und es standen neben weiteren
Diensten37 Twitter und Google Buzz als bekanntere Vertreter zur Auswahl. Im Gegensatz
zu Twitter erlaubt Google Buzz mehr Inhalt in einem Beitrag und die M¨ glichkeit einer
o
Konversation zu jedem Beitrag. Feedback ist unmittelbar mit dem Beitrag verbunden. Der
¨
Umgang mit Google Buzz ist ein deutlich anderer als bei Twitter. Ahnlichkeit hat Google
¨
Buzz in dieser Hinsicht eher mit den Statusupdates bei Facebook, wo auf ahnliche Weise
35 http://bigbluebutton.org
36 http://code.google.com/p/openmeetings/
37 identi.ca (http://identi.ca), bleeper (http://bleeper.de), Jaiku (http://www.jaiku.com)
15

16. Links und Medieninhalte angehangen werden k¨ nnen. Twitter wurde aufgrund der Ein-
o
schr¨ nkung in der L¨ nge der Nachrichten ausgew¨ hlt, denn f¨ r l¨ ngere Inhalte kann z. B.
a a a u a
ein Shared Editor besser genutzt werden bei synchroner Zusammenarbeit. Twitter erlaubt
es durch die Ver¨ ffentlichung von Beitr¨ gen auf einfache Weise weitere Menschen in eine
o a
Diskussion mit einzubeziehen, immer mit der Beschr¨ nkung sich kurz halten zu m¨ ssen
a u
¨
und so auch den Uberblick behalten zu k¨ nnen. Durch die Vergabe von Tags k¨ nnen Bei-
o o
tr¨ ge sortiert und gefiltert werden, was die Einordnung in Themenbereiche oder Sitzungen
a
m¨ glich macht. Schaut man sich an, wie Twitter genutzt wird, so ist eine Zuordnung we-
o
der in eine Systemklasse noch in eine Unterst¨ tzungsfunktion zul¨ ssig. Bisher vorgestellte
u a
Schemata passen hier nicht..
Echtzeit. Auch wenn Twitter nicht unbedingt als Echtzeit-unterst¨ tzend angesehen wird,
u
so zeigt der Trend bei Twitter, das Antworten und Feedback bei Twitter in vielen Kreisen so
schnell erfolgt, dass man dies durchaus unter Echtzeit einordnen kann. In einer synchronen
Lernsituation kommt diese Dynamik f¨ r Teilnehmende im Mashup und außerhalb zum
u
Einsatz. Twitter hat außerdem den Vorteil, dass aufgrund der Verbreitung auf mobilen
Plattformen mehr Menschen direkt erreicht werden k¨ nnen. Ein Computer im eigentlichen
o
Sinne muss nicht benutzt werden.
Social Bookmarking. Um auf einer gemeinsamen Grundlage in der Gruppenarbeiten zu
gelangen sind Verweise auf Literatur und weitere Inhalte von großer Bedeutung. Hierzu
stehen Dienste wie Delicious38 , Digg39 oder LinkedIn40 als bekannte Vertreter von Social
Bookmarking zur Auswahl. Einordnen k¨ nnte man diesen Dienst nach [TSMB95] weniger
o
in eine Systemklasse, sondern zu den Unterst¨ tzungsfunktionen Koordination und Koope-
u
ration.
¨
RSS Feeds. Die Realisierung f¨ r den Prototypen fand in Form von RSS Feeds statt. Uber
u
RSS Feeds werden hier Informationen von den Diensten geholt, gefiltert und aufbereitet
¨
zur Anzeige. Eine vollst¨ ndige Integration der Dienste uber die Anmeldung beim Dienst
a
herzustellen ist Aufgabe f¨ r die Weiterentwicklung. Dann w¨ re es auch m¨ glich, Daten
u a o
im Mashup41 direkt zu ver¨ ffentlichen, um so auch den Medienbruch zu vermeiden, der
o
¨
es n¨ tig macht Daten uber eine andere Anwendung einzustellen. Da RSS Feeds an vielen
o
Stellen im Netz genutzt werden, ist eine Nutzung dieses Moduls auch f¨ r weitere Zwecke
u
m¨ glich.
o
3.2.4 Weitere Dienste
Bisher wurden Dienste in den Prototypen eingebunden die eine erste Nutzung erm¨ glichen
o
und wesentliche Unterst¨ tzungsfunktionen realisieren. Die Anwendung wurde geschaffen
u
weitere Dienste Einbinden zu k¨ nnen. Welche weiteren Dienste f¨ r die Integration denkbar
o u
sind, sollen die folgenden Abs¨ tze nennen.
a
Shared Editing. Urspr¨ nglich war ein Shared Editor schon f¨ r den Prototypen geplant,
u u
weshalb der n¨ chste Schritt w¨ re, diesen zu integrieren. Hier w¨ rde auf eine Open Source
a a u
38 http://delicious.com
39 http://digg.com
40 http://www.linkedin.com
41 und nicht in einer anderen Anwendung
16

17. Variante des Etherpads42 zur¨ ckgegriffen werden, um diesen direkt auf dem Server der
u
Mashup-Anwendung einzurichten. Bisher scheint es leider so, dass bei diesen Vertretern
keine API vorhanden ist. Der Shared Editor w¨ rde der Systemklasse Workgroup Compu-
u
ting zugeordnet, womit nach Teufel et al. weitere kooperationsunterst¨ tzende Funktionen
u
zur Mashup-Anwendung hinzuk¨ men.
a
Desktop Sharing. Manchmal reicht es einfach zuzuschauen oder jemand anders uber-¨
nimmt die Kontrolle. Einerseits kann Desktop Sharing bedeuten, dass alle Teilnehmer
denselben Desktop sehen k¨ nnen. Andererseits kann es bedeuten, dass ein Teilnehmer
o
¨
die Steuerung eines anderen Teilnehmers ubernimmt, um bspw. nicht alle Instruktionen
verbalisieren zu m¨ ssen. Genutzt werden kann Desktop Sharing somit z. B. zum Support
u
oder zu Pr¨ sentationszwecken. Diese Funktion w¨ rde im Wesentlichen der Kommunikati-
a u
onsunterst¨ tzung zugeordnet.
u
Website Annotation. Eine Erweiterung f¨ r Social Bookmarking. Mit Annotationen auf
u
beliebigen Webseiten k¨ nnen entscheidende Informationen schnell gefunden werden. Hier
o
w¨ re die Einbindung von Diigo43 , The Awesome Highlighter 44 oder Google Sidewiki45
a
eine M¨ glichkeit. Der Informationsaustausch geschieht implizit und eine Zuordnung ist in
o
die Systemklasse der gemeinsamen Informationsr¨ ume m¨ glich.
a o
Mit der erfolgten Auswahl ist die Mashup-Anwendung keiner bestimmen Systemklas-
se in Abbildung 2 mehr zuzuordnen. Wenn eine direkte Zuordnung einzelner Dienste
m¨ glich war, so wurden bisher kommunikations- und kooperatiosunterst¨ tzende Funk-
o u
tionen direkt zugeordnet. Koordinationsunterst¨ ztende Funktionen ließen sich z. B. durch
u
Umfragen46 , gemeinsame Kalender47 und Polling48 realisieren. Die Zuordnung zu Un-
terst¨ tzungsfunktionen sollte nicht als absolut angesehen werden, da die bereits vorgestell-
u
ten Funktionen immer auch einen Teil weiterer Unterst¨ tzungsfunktionen bereitstellen.
u
4 Umsetzung
Fehlende Semantik bei der Suche nach Diensten. Wie in der Arbeit von Benslima-
ne ([BDS08]) hervorgehoben wird, gibt es bei Diensten im Internet bisher Defizite beim
Auffinden, der Nutzung und der Einheitlichkeit. Hauptprobleme werden unter anderem
mit einer fehlenden semantischen Heterogenit¨ t und der damit in Verbindung stehenden
a
Interoperabilit¨ t begr¨ ndet. [CJWS09] versucht dieses Problem mit einer Service Map-
a u
ping Description (SMD) entgegenzuwirken, indem semantische Annotationen an einen
Webservice gebunden werden. In der Praxis werden SMDs bisher nicht eingesetzt. So ist
es auch bei der Umsetzung ein Problem gewesen, dass jeder Dienst der eingebunden wird,
mitunter grundlegend verschieden funktioniert. Auch das Auffinden kompatibler Dienste
42 http://etherpad.com/
43 http://www.diigo.com
44 http://www.awesomehighlighter.com
45 http://www.google.com/sidewiki/
46 Z.B. Doodle oder Google Docs
47 Z.B. Google Calendar
48 Implementierung verh¨ ltnism¨ ßig einfach
a a
17

18. ist nicht trivial, da man erst nach genauerem Studium der API feststellen kann, wie sie
genutzt wird, was hiermit m¨ glich ist und was nicht.
o
Erweiterung bestehender Systeme. Bestehende Systeme wie ezWeb zu erweitern kam
nicht infrage, da die Einarbeitung in ein System verh¨ ltnism¨ ßig viel Zeit in Anspruch
a a
genommen h¨ tte und der Lerneffekt geringer gewesen w¨ re. Keines der untersuchten Sys-
a a
teme zeigte eine entsprechende Grundlage auf, auf der h¨ tte aufgebaut werden k¨ nnen,
a o
ohne gr¨ ßere Einschr¨ nkungen in Kauf nehmen zu m¨ ssen. Auch wenn es bei einem Pro-
o a u
totypen bleibt, so sollte dieser unbedingt darauf ausgelegt sein, erweiterbar und skalierbar
zu sein.
Nutzung von Mashup Frameworks. Wie in Abschnitt 3.1 bereits erw¨ hnt wurde, gibt es
a
keine große Anzahl solcher Frameworks. Da Yahoo Pipes aus bereits genannten Gr¨ nden
u
nicht geeignet ist, wurde nach weiterer Recherche beschlossen, dass es am praktikabels-
ten ist, von Grund auf eine neue Anwendung zu erstellen. Wie sich anschließend gezeigt
hat, ist dies unter dem zeitlichen Aspekt und auf lange Sicht die richtige Entscheidung
gewesen.
Django. In der Kenntnis, welche Anwendungen bereits mit Hilfe des Django Frame-
works49 erstellt wurden und ohne Programmierkenntnisse in Python wurde Django als
Grundlage f¨ r die Entwicklung gew¨ hlt. Nach l¨ ngerer Einarbeitung stellte sich das Fra-
u a a
mework als die richtige Wahl heraus, denn mit ein bisschen Mehraufwand ist so ein mo-
dularer Mashup-Server entstanden, der im Folgenden im Detail beschrieben wird.
4.1 Architektur
Serverseitig. Entwickelt wurde der Prototyp als serverseitige Mashup-Anwendung. Das
bedeutet, dass die Integration eines Dienstes auf dem Server stattfindet und somit erst eine
Kommunikation zwischen Mashup und Browser stattfindet, bevor ein Dienst genutzt wird
¨
(Punkte 2 und 7 in Abbildung 6). Uber den Server, auf dem die Mashup-Anwendung liegt,
wird dann eine Verbindung zum entsprechenden Service hergestellt (Punkte 4 und 5 in
Abbildung 6).
Aggregierend und Integrierend. Eine Zuordnung zu aggregierenden oder integrieren-
den Mashups ([CJWS09]) kann hier nur in Abh¨ ngigkeit vom Dienst geschehen. So wie
a
die Nutzung von RSS Feeds aggregierend ist, ist die Nutzung des Whiteboards oder des
¨
Videoconferencings integrierend, da eine Einbindung uber APIs geschieht.
MVC & Django. Django ist ein Model-View-Controller (MVC)50 Framework. Dieses De-
sign Pattern legt eine Strukturierung des Programmiercodes derart fest, dass Datenmodell,
Pr¨ sentation und Anwendungslogik getrennt voneinander betrachtet werden k¨ nnen. Das
a o
o a ¨
erm¨ glicht bspw. den Austausch der Pr¨ sentationsschicht, ohne Anderungen am Modell
oder der Anwendungslogik vornehmen zu m¨ ssen.
u
49 Auf Python aufsetzendes Web Framework (http://www.djangoproject.com)
50 http://de.wikipedia.org/wiki/ModelView Controller
18

19. Abbildung 6: Funktionsweise der Mashup-Anwendung (vgl. [OBB07])
Objekte. Begonnen wurde mit dem Aufbau des Datenmodells. Verschiedene Elemente51
werden durch Objekte in Python gekapselt. Diese Objekte erben von der abstrakten Klas-
se GenericObject grundlegende Attribute, wie Name und Berechtigungen. Die konkreten
Objekte erweitern die Klasse GenericObject in dem Sinne, dass sie f¨ r das Objekt
u
spezifische Member implementieren. Beim Whiteboard muss bspw. ein Schl¨ ssel und ei-
u
ne zus¨ tzliche ID gespeichert werden. Die Implementierung des GenericObject ist in
a
Listing 1 aufgef¨ hrt.
u
1 class GenericObject(models.Model):
2 class Meta:
3 abstract = True
4 ordering = [’-changed_date’]
5
6 name = models.CharField(max_length=100)
7 description = models.TextField()
8 user_created = models.ForeignKey(User, related_name=
"created_%(class)s", verbose_name=’Ersteller’)
9 created_date = models.DateTimeField(’Erstellt’,
auto_now_add=True)
10 changed_date = models.DateTimeField(’Geaendert’,
auto_now=True)
11
12 def __unicode__(self):
13 return str(self.name)
14
51 Ein Element steht f¨ r ein beliebiges Objekt im Mashup. Das kann bspw. ein Whiteboard oder ein RSS Feed
u
sein
19

20. 15 import objectpermissions
16 permissions = [’Lesen’, ’Schreiben’, ’Rechte vergeben’]
17 objectpermissions.register(GenericObject, permissions)
Listing 1: Implementierung von GenericObject in Django
Klassen. Jede Klasse erbt in Django von django.db.model.Model, welche Metho-
den f¨ r die Kommunikation mit der Datenbank im Framework bereitstellt. Jedes Attribut
u
(Zeilen 6-10) repr¨ sentiert ein Datenbankfeld. In den Zeilen 2-3 werden Metadaten fest-
a
gelegt. Zum einen wird festgelegt, dass es sich um eine abstrakte Klasse handelt und zum
anderen wird die Sortierung bei der Ausgabe von Objekten entsprechend dem Attribut
changed date festgelegt.
Vererbung. Durch die Vererbungshierarchie lassen sich weitere Objekte ohne viel Pro-
grammiercode erstellen, da Berechtigungen, Name und Weiteres bereits durch die ab-
strakte Klasse GenericObject implementiert sind. Als Programmierer kann sich so
auf die wesentlichen Eigenschaften eines neuen Objekts konzentriert werden. Tabellen in
der Datenbank werden durch Erstellung neuer Klassen automatisch beim Start des Servers
erstellt. Die Erweiterung von Klassen und somit die Aktualisierung von Tabellen ist nicht
ohne Weiteres m¨ glich.
o
Rechtemanagement. Django bietet eine vorkonfigurierte Nutzerverwaltung die noch durch
ein differenzierteres Rechtemanagement erweitert wurde. Da Django es nur erlaubt Be-
rechtigungen auf Klassenebene zu definieren, wurde ein Modul eingebunden, welches er-
laubt, Rechte f¨ r einzelne Objekte zu erstellen und abzurufen. In den Zeilen 15-17 in Lis-
u
ting 1 wird hierzu das Modul objectpermissions importiert und Berechtigungen mit
entsprechenden Bezeichnungen definiert. Zeile 17 bewirkt, dass in der Datenbank f¨ r jede
u
Klasse zus¨ tzlich eine Berechtigungstabelle erstellt wird, in der f¨ r jeden Nutzer oder jede
a u
Gruppe eine Zeile dazu dient, die Stufe der Berechtigung auf ein Objekt festzulegen. Im
Prototypen k¨ nnen drei verschiedene Berechtigungen eingestellt werden: Lesen, Schreiben
o
und Rechte vergeben. Findet ein Zugriff auf ein Objekt statt, so muss im Programmcode
¨
zuvor auf das entsprechende Recht uberpr¨ ft werden. Im Prototypen geschieht dies uber
u ¨
¨
die implementierte Funktion check permission, die als Ubergabe den angemeldeten
Nutzer, das abzurufende Recht und das Objekt erh¨ lt. Je nachdem, ob das Recht vorhanden
a
u ¨
ist, wird ein Wahrheitswert zur¨ ckgegeben. In Listing 2 geschieht diese Uberpr¨ fung in
u
Zeile 4. Ist das Recht vorhanden, wird in Zeile 6 auf die entsprechende Seite weitergeleitet.
1 @login_required
2 def edit(request, board_id, queryset):
3 board = Board.objects.get(id=board_id)
4 if not check_permission(request.user, 1, board):
5 return permission_denied(request)
6 iframe_url = board.board_url(request.user)
7 return render_response(request, ’dabbleboard/edit.
html’, {’board’: board, ’url’: iframe_url,})
Listing 2: View-Funktion um Whiteboards zu bearbeiten
Pattern und Views. Neben der Implementierung der Klassen werden sogenannte Views
und entsprechende URL-Pattern definiert. Die URL Pattern f¨ r das Whiteboard-Modul
u
20

21. ¨
sind in Listing 3 aufgef¨ hrt. Views werden uber Python Funktionen definiert (Listing 2)
u
und dienen als Callback f¨ r die URL Pattern. In den Funktionen f¨ r die Views wird ein
u u
¨
Template angegeben und ggf. werden Variablen ubergeben, die im Template z. B. zu ei-
ner Ersetzung eines Platzhalters f¨ hren k¨ nnen. Der Ablauf ist nun folgendermaßen: Der
u o
Nutzer ruft eine URL auf, die auf das Pattern in Zeile 14 von Listing 3 passt52 . Darauf
wird die angegebene View-Funktion dabbleboard.views.edit (Listing 2) aufge-
rufen und das Template dabbleboard/edit.html (Listing 4) mit der ubergebenen ¨
Variable chat gerendert.
1 from django.conf.urls.defaults import *
2 from models import Board
3
4 queryset = {
5 ’queryset’: Board.objects.all().order_by("-
changed_date"),
6 }
7
8 urlpatterns = patterns(’django.views.generic.
list_detail’,
9 url(’ˆ$’, ’object_list’, queryset, name="board"),
10 url(’ˆ(?P<object_id>d+)/$’, ’object_detail’,
queryset, name="board"),
11 )
12 urlpatterns += patterns(’’,
13 url(’ˆlist_user_drawings/$’, ’dabbleboard.views.
list_user_drawings’, queryset, name="user_drawings")
,
14 url(’ˆ(d+)/edit/$’, ’dabbleboard.views.edit’,
queryset, name="edit"),
15 url(’ˆ(d+)/edit/f/$’, ’dabbleboard.views.
edit_fullscreen’, queryset, name="
edit_fullscreen_board"),
16 url(’ˆcreate/$’, ’dabbleboard.views.create_drawing’,
queryset, name="create_board"),
17 url(’ˆ(?P<instance>d+)/userrights/$’, ’dabbleboard.
views.set_rights_user’, queryset, name="
set_rights_user_board"),
18 url(’ˆ(?P<instance>d+)/grouprights/$’, ’dabbleboard.
views.set_rights_group’, queryset, name="
set_rights_group_board"),
Listing 3: URL Pattern f¨ r Whiteboards in der Anwendung
u
Jedes Element hat eine eindeutige ID. In Zeilen 10, 14 und 15 von Listing 3 steht das
d+ jeweils f¨ r die ID des Whiteboards. Weiterhin werden auf diese Weise auch Mashups
u
zusammengesetzt, indem die IDs in dem URL-Pattern verarbeitet werden. Das Besondere
dabei ist, dass aufgrund dieser Eigenschaft der Nutzer ein erstelltes Mashup oder ein be-
liebiges Element als Lesezeichen speichern kann. Außerdem erlaubt das die Weitergabe
eines Mashups in Form einer URL.53
52 Z. B. http://www.example.com/123/edit/
53 Hinweis: ¨
Die Rechte werden nat¨ rlich auch bei der direkten Eingabe der URL uberpr¨ ft.
u u
21

22. Templates. Templates stellen die Pr¨ sentationsschicht54 in Django dar. Sie k¨ nnen hier-
a o
archisch aufgebaut werden, was es hier erm¨ glicht hat, den ”Rahmen”des Mashups nur
o
ein mal f¨ r alle Seiten definieren zu m¨ ssen. Zu ersetzende Teile des Rahmens werden
u u
durch Platzhalter ersetzt. Diese Platzhalter k¨ nnen dann durch ein Template, welches
o
¨
vom ”Rahmen-Template” erbt, gef¨ llt werden. Diese Vererbung ist uber mehrere Stufen
u
m¨ glich.
o
1 {% extends ’base.html’ %}
2 {% block content %}
3 <h2>
4 <small>
5 {{ board.name }}
6 </small>
7 </h2>
8 {% include ’dabbleboard/_edit.html’ %}
9 <a href="{% url edit_fullscreen_board board.id %}">In
den Vollbild Modus wechseln</a>
10 {% endblock %}
Listing 4: Template zur Bearbeitung eines Whiteboards
Das Template in Listing 4 erbt vom Template base.html und ersetzt in base.html
den content-Block durch die Zeilen 3-9. In Zeile 8 wird ein weiteres Template inklu-
diert, welches einen iframe f¨ r ein Whiteboard enth¨ lt. In Zeile 9 wird ein Link angege-
u a
ben, der durch die Angabe des Namens edit fullscreen board und der Ubergabe ¨
einer id auf das URL Pattern in Zeile 15 in Listing 3 verweist. Der Link wird auf der
Basis des URL Pattern automatisch in eine URL umgewandelt und in Zeile 9 ersetzt.
4.2 Einsatz
Im Folgenden wird der aktuelle Stand der Mashup-Anwendung vorgestellt. Hier sei nur
darauf hingewiesen, dass der Prototyp bisher nicht auf Bedacht der h¨ chsten Usability
o
erstellt wurde und Verbesserungen im Ausblick angesprochen werden.
Aufbau der Benutzungsober߬ che. In Abbildung 7 sehen wir den Registrierungsdia-
a
log f¨ r die Anwendung. Mit der Registrierung wird gleichzeitig auch ein Konto55 beim
u
Whiteboard-Dienst Dabbleboard eingerichtet. Weiterhin zeigt Abbildung 7, wie der Rah-
men aufgebaut ist. Jede der folgenden Abbildungen ist im ”Rahmen” der Abbildung 7 zu
u ¨
sehen: Men¨ punkte und Uberschrift (oben), RSS Feeds (rechts). Aus Platzgr¨ nden wurde
u
der ”Rahmen” in den anderen Abbildungen weggelassen.
Whiteboards. Zum jetzigen Zeitpunkt kann jeder Nutzer alle Whiteboards in einer Liste
anzeigen lassen (Abbildung 8). In dem Moment, wo Details aufgerufen werden wird die
¨
Berechtigung uberpr¨ ft. Ist man nicht angemeldet, so erscheint ein Login-Dialog, der nach
u
54 Hier¨ ber kann sich gestritten werden. H¨ ufig wird als Pr¨ sentationsschicht auch der Teil bezeichnet, der f¨ r
u a a u
den Inhalt verantwortlich ist. Hier w¨ re das die View-Funktion und das URL Pattern.
a
55 Eigentlich nur ein Nutzername mit einem Passwort unter dem API-Account von Dabbleboard
22

23. Abbildung 7: Registrierung zur Mashup-Anwendung
Abbildung 8: Auflistung aller Whiteboards
erfolgreichem Login auf die gew¨ nschte Seite weiterleitet. Ist man angemeldet, aber nicht
u
berechtigt kommt eine entsprechende Meldung.
Abbildung 9 zeigt die Detailansicht eines Elements. Hier sehen wir ein Whiteboard-Ele-
ment. Analog ist dies beim Videoconferencing zu sehen. Jeder Nutzer kann Kommentare
zu Elementen hinterlassen.
¨
Rechte. Die Rechte auf ein Element k¨ nnen uber die Detailansicht (Abbildung 9) aufge-
o
rufen werden. Wie Abbildung 10 zeigt, k¨ nnen Rechte f¨ r einzelne Nutzer (a), wie auch
o u
f¨ r Gruppen (b) differenziert festgelegt werden.
u
Elemente k¨ nnen beliebig erstellt und einzeln genutzt werden. Um ein Mashup zu erstel-
o
len, werden die Dienste nacheinander ausgew¨ hlt. W¨ hrend dieser Auswahl (Abbildung
a a
11) wird nur angezeigt, worauf auch das Schreibrecht besteht. Erst wird der Videochat (a),
dann das Whiteboard (b) ausgew¨ hlt. Daraufhin wird zuoberst der Videochat, darunter das
a
Whiteboard und daneben RSS-Feeds angezeigt.
Bildschirmau߬ sung. Bisher wurde alles Besprochene im Design aus Abbildung 7 an-
o
gezeigt. Da man sich nicht auf eine bestimmte Bildschirmaufl¨ sung festlegen m¨ chte, ist
o o
¨
es weiterhin uber einen Link direkt m¨ glich in einen Vollbild-Modus zu wechseln. Bis-
o
her besteht der Unterschied darin, dass hier nicht das Design angezeigt wird, sondern auf
23

24. Abbildung 9: Details eines Whiteboards
die AUsnutzung der Bildschirm߬ che optimiert wurde. Im Vollbild-Modus werden zwei
a
Spalten RSS Feeds angezeigt und R¨ nder zu allen Seiten sind minimal gehalten.
a
5 Vergleich zu bestehenden Systemen
Wie Tabelle 1 bereits gezeigt hat, fehlt es in den vorgestellten Systemklassen an einer ab-
gestimmten Funktionsf¨ lle zur kollaborativen Arbeit in Echtzeit f¨ r verschiedene Anwen-
u u
dungsf¨ lle. Einige Funktionen sind bereits in den Applikationen vorhanden, nur m¨ ssen
a u
24

25. (a) Nutzerrechte (b) Gruppenrechte
Abbildung 10: Festlegen der Rechte auf ein Whitebord
(a) Videochat (b) Whiteboard
Abbildung 11: Erstellung des Mashups - Auswahl des Whiteboards und des Videochats
diese sinnvoll und flexibel vereint werden. Mit dem Fokus dieser Arbeit auf synchronen
kollaborativer Arbeit wurden in den vorangegangenen Abschnitten entsprechende Vor-
schl¨ ge gemacht, wie diverse Funktionen zum Einsatz kommen und so in ihrer Kombi-
a
nation einen h¨ heren Mehrwert schaffen. Weitere Funktionen folgen im Ausblick.
o
CVE. Die Ausf¨ hrungen von Portugal [PGF07] beziehen sich zwar auf Collaborative Vir-
u
tual Environments (CVE), was nicht unmittelbar auf ein Mashup zu beziehen ist, aber es
lassen sich Analogien ziehen. Das vorgestellte System nutzt zwei Metaphern: hall und
collaboration room56 .57 Die hall-Metapher beschreibt eine virtuelle Umgebung, in der
zwanglos interagiert werden kann. Ein collaboration room dient hingegen dazu, gemein-
sam zu arbeiten und Materialien zu teilen. Hier gibt es unter anderem auch ein White-
board, einen Shared Editor und Videoconferencing. Die Funktionen lassen sich auch in
weiteren Bereichen mit der Mashup-Anwendung vergleichen. Es gibt geschlossene, halb-
offene und offene collaboration rooms, die im weitesten Sinne dem Rechtemanagement
der Mashup-Anwendung entsprechen: Offen: jeder darf den Raum betreten, halb offen:
nur bestimmte Mitglieder d¨ rfen den Raum betreten, geschlossen: bedeutet, dass Nut-
u
zer in dem Raum nicht gest¨ rt werden m¨ chten. Letzteres ist und wird auch nicht in die
o o
Mashup-Anwendung einfließen, da Berechtigungen auf Elemente des Mashups ausreichen
¨
sollten. Die ersten beiden Punkte sind bereits ubertragbar auf das Rechtemanagement, nur
dass die Berechtigungen f¨ r jedes Element definierbar sind. Die Mashup Anwendung hat
u
gegen¨ ber der CVE den Vorteil, dass die Zusammensetzung eines Raums nicht festgelegt
u
ist. Die Elemente sind frei im Mashup kombinierbar, weshalb die Nutzung einer Raum-
Metapher hier eher unpassend und verwirrend w¨ re.
a
Weiterentwicklung bestehender Systeme. Blackboard hat den Trend zu Mashups er-
56 Im folgenden auch Raum genannt
57 Eine vergleichbare Metapher kommt bei [Ham01] zum Einsatz
25

26. Abbildung 12: Mashup im Vollbild Modus
kannt und gibt Nutzern und Entwicklern nun die Chance Mashups in ihrem LMS zu er-
stellen.
6 Ausblick
Aufgrund des zeitlichen Umfangs wurden nur wesentliche Funktionen in dem Prototy-
pen umgesetzt. Es k¨ nnen weitere Szenarien f¨ r weitere Integrationen von Tools und die
o u
Zusammenarbeit dieser Tools erstellt werden.
Zwei Defizite der Anwendung mit entprechenden L¨ sungsans¨ tzen:
o a
• Um RSS Feeds aktuell zu halten muss die komplette Seite neu geladen werden.
L¨ sung: Einsatz von AJAX.
o
• Die Anordnung der Elemente ist durch den Programmierer festgelegt.
L¨ sung: Elemente wie in iGoogle oder Netvibes in kleine manipulierbare Fenster
o
integrieren und so das Verschieben und Ver¨ ndern der Elemente erm¨ glichen.
a o
Rechte. Es lassen sich bei der Einbindung von externen Diensten nicht immer alle Rechte,
wie sie in der Mashup-Anwendung definiert sind, umsetzen. So muss das Recht Lesen bei
einem Whiteboard dahin gehend beschr¨ nken, dass nur die Details des Whiteboards an-
a
¨
gesehen werden k¨ nnen. Ansonsten ist das Schreibrecht dazu da, die Elemente zu offnen
o
¨
und somit am Whiteboard Anderungen vorzunehmen oder beim Videochat an einer Un-
26

27. ¨
terhaltung teilzunehmen. Hier w¨ re Schreibrecht evtl. in Betreten-Recht oder ahnlich um-
a
zu¨ ndern.
a
Single Sign On. Bereits angesprochen wurde die direkte Einbindung von Diensten wie
¨
Twitter oder Delicious. Wenn sich auch uber die Mashup-Anwendung bei diesen Diens-
ten angemeldet wird, ist die Ver¨ ffentlichung von Inhalten direkt hier¨ ber m¨ glich. Dies
o u o
w¨ rde den Wechsel zu einer anderen Anwendung (Medienbruch) verhindern und der Fo-
u
kus bliebe in diesem Fall bei der Anwendung.
Profile. Die Anwendung ist derzeit so ausgelegt, dass dem Nutzer eine sinnvolle Zusam-
menstellung eines Mashups an die Hand gelegt wird. Mit Hilfe der Template Engine (Ab-
schnitt 4.1) ist eine Definition g¨ ngiger Zusammenstellungen m¨ glich, ebenso wie eine
a o
Freischaltung oder Verwehrung bestimmter Dienste f¨ r Nutzer und Gruppen. Wie schon
u
in Abschnitt 2 unter Ziel erw¨ hnt, muss den Anforderungen entsprechend die Auswahl der
a
eingebunden Dienste geschehen.58
In Beziehung setzen. Eine weitere Richtung in die entwickelt werden k¨ nnte ist die Ver-
o
bindung zwischen verschiedenen Diensten und den Inhalten. Alle Dienste laufen bisher
nebenl¨ ufig in der Anwendung ab. Eine Beziehung zwischen verschiedenen Inhalten her-
a
zustellen ist m¨ glich, muss aber durch den Nutzer selber aufgrund von Zeitstempeln ge-
o
zogen werden. Weitergehend sind auch Beziehungen zwischen Inhalten denkbar, die nicht
¨
uber den Zeitpunkt der Erstellung zu ziehen sind, sondern eine direkte Beziehung zwi-
schen Inhalten herstellen.
Dynamische Gestaltung. Die Zusammensetzung eines Mashups erfolgt derzeit noch sehr
statisch. Der Nutzer wird durch eine Wizard-artige Konfiguration geschickt, damit er ein
Mashup mit dem richtigen Whiteboard und Videoconference erh¨ lt. Zum einen k¨ nnte
a o
man vordefinierte Mashups speichern, um diesen Zugang zu erleichtern und zum anderen
k¨ nnte die Auswahl der Elemente auf einer Seite runtergebrochen werden. Eine andere
o
Art der Zusammenstellung w¨ re in einer Art Warenkorb Denkbar. Hat man das richtige
a
Whiteboard gefunden, so kann an Ort und Stelle sofort eine Auswahl getroffen werden,
damit dieses zum n¨ chsten Mashup hinzugef¨ gt wird. F¨ hrt man die Analogie weiter, so
a u u
stellte der Warenkorb letztlich die Zusammenstellung eines Mashups dar.
Integration bestehender LMS. Bei dem Angebot von Lernsystemen scheint es erst mal
schwer, eine weitere Anwendung zu platzieren. Dem wird entgegengewirkt, da die Mash-
up-Anwendung potenziell alle Systeme integrieren kann. Wenn dies mit Whiteboards,
Twitter und Facebook funktioniert, so k¨ nnen auch Daten aus LMS, VLE, PLE oder
o
anderen Systemen integriert werden. Ein Problem stellt lediglich die Bereitstellung von
Schnittstellen dieser Systeme dar. An der Uni Paderborn k¨ nnten bspw. Dokumente oder
o
Foren des bestehenden LMS direkt integriert werden. Der Mashup-Anwendung wird Zu-
griff auf bestehende Systeme gew¨ hrt, so dass Daten innerhalb des Mashups eingestellt
a
werden aber letztlich im System der Uni landen. So k¨ nnen Daten im Mashup und im
o
System der Uni gleichermaßen genutzt werden.
Integration in bestehende LMS. Abgesehen davon, dass es externe Dienste in einem Uni-
internen System schwer haben, w¨ re eine Einbindung von Diensten auch f¨ r den direkten
a u
58 Im Zentrum dieser Arbeit stand die Entwicklung der Plattform. Didaktisch sinnvolle Szenarien m¨ ssen bei
u
der Einbindung weiterer Dienste untersucht werden.
27

28. Einsatz von Mashup-Technologien auf den Lernplattformen der Universit¨ ten f¨ rderlich.
a o
Touchscreens. Die derzeitigen Entwicklungen bei Tablet-Computern zeigen, dass wir
vielleicht in naher Zukunft kaum noch eine Tastatur oder eine Maus nutzen werden. Die
Kluft der Trennung von Wahrnehmungs- und Handlungsraum, die auch durch die Nutzung
der Maus entsteht, wird durch ber¨ hrungsempfindliche Bildschirme nahezu aufgehoben.
u
Mit Blick auf diese Entwicklung m¨ ssten weitere Anwendungsszenarien entwickelt wer-
u
den, die speziell den Umgang mit der Technologie unter die Lupe nehmen.
Bildschirmau߬ sung. Youtube hat im Juli 2010 begonnen Videos mit mehr als vierfacher
o
HD-Aufl¨ sung zu unterst¨ tzen.59 Der Trend zu immer gr¨ ßeren Bildschirmen ist seit Jah-
o u o
ren konstant, doch seit Einf¨ hrung von Full HD mit 1920 Pixeln in der Breite gab es keine
u
wesentlichen Schritte mehr. Nicht zuletzt Youtube zeigt auf, dass Monitor und Fernseher in
Zukunft h¨ here Aufl¨ sungen erhalten werden. Entsprechend wird auch die Bildschirmdia-
o o
gonale gr¨ ßer60 . Folglich wird der Lernende der Zukunft nicht unbedingt durch den Platz,
o
den er auf dem Bildschirm hat, beschr¨ nkt sein. Diese Beschr¨ nkung ist derzeit beim De-
a a
sign der Benutzungsober߬ che ein kritischer Faktor, der jederzeit betrachtet werden muss.
a
Bei h¨ heren Aufl¨ sungen und gr¨ ßeren Bildschirmen muss die Benutzungsoberfl¨ che neu
o o o a
¨
uberdacht werden. Gerade bei der Widget-basierten Architektur von Mashups ist eine hohe
Aufl¨ sung gleichzusetzen mit h¨ herer Usability.61
o o
Anonymit¨ t. In [DT01] wird herausgestellt, dass Anonymit¨ t f¨ rderlich f¨ r Lernsitua-
a a o u
tionen sein kann. Positive Auswirkungen k¨ nnen sich bei Wettbewerbssituationen, Pro-
o
bleml¨ sen und Kreativit¨ t und der Zur¨ ckhaltung aufgrund von dummen Fragen“ erge-
o a u
”
ben. Der Prototyp erlaubt solche Szenarien bisher nicht, aber eine Erweiterung hierhin
gehend w¨ re denkbar. Abstriche muss dann allerdings bei Videokonferenzen, Twitter und
a
sonstigen Diensten machen, bei denen sich mit einem zuzuordnenden Namen angemeldet
u a ¨
wird. Das Szenario w¨ rde sich somit g¨ nzlich andern. Alternativ k¨ nnten Module/Widgets
o
entwickelt werden, die Anonymit¨ t gew¨ hrleisten, w¨ hrend der Rest der Anwendung wie
a a a
bisher l¨ uft. Eine Abstimmung ist ein Beispiel f¨ r anonyme Beteiligung.
a u
Gruppenbildung. W¨ hrend in [TD03] noch gesagt wird, dass zus¨ tzliche M¨ glichkeiten
a a o
der virtuellen Gruppenbildung noch nicht ausgesch¨ pft werden, zeigt sich heute anhand
o
Facebook, dass die soziale Vernetzung bei Sch¨ lern und Studenten die Gruppenbildung
u
durchaus unterst¨ tzt ([ESL07]). Hinzu kommt, wie in [TD03] geschrieben wird, dass die
u
¨
Grundgesamtheit sich durch die Aufhebung ortlicher Grenzen vergr¨ ßert. W¨ hrend in der
o a
¨
realen Welt schnell der Uberblick verloren geht, gibt es f¨ r computerunterst¨ tzte Gruppen
u u
Techniken zum Matching passender Lernpartner.
7 Fazit
Die Ausarbeitung hat gezeigt, dass es m¨ glich ist, verschiedene Dienste zur Kollaboration
o
in einer Mashup-Anwendung zu vereinen. Der erste Prototyp wurde erfolgreich getestet
59 YouTube unterst¨ tzt mehr als vierfache HD-Aufl¨ sung: http://newsticker.sueddeutsche.de/list/id/1013682
u o
60 nichtunbedingt im selben Verh¨ ltnis wie die Aufl¨ sung
a o
61 Dasselbe l¨ sst sich bei einem zu kleinen Schreibtisch erkennen.
a
28

29. und einer Weiterentwicklung um weitere Dienste steht nichts mehr im Wege. Bisher fehlt
eine Studie, die den Nutzen von Kombinationen von Funktionen aufzeigt und somit die
Notwendigkeit der Weiterentwicklung der Mashup-Anwendung unterst¨ tzen w¨ rde. Hin-
u u
zu kommt, dass relativ neue Dienste mit Facebook oder Twitter bisher in der Lehre nicht
eingesetzt wird.
Notwendigkeit. Die Notwendigkeit f¨ r ein solches System hat sich außerdem w¨ hrend des
u a
Seminars selber gezeigt. Ein nicht unerheblicher Aufwand wurde betrieben, um Pr¨ senta-
a
tionen und Diskussionen zwischen zwei entfernten Gruppen zu erm¨ glichen. Die Auftei-
o
lung zu Monitoren und Beamer sah auf der Seite der Paderborner Uni folgendermaßen
aus:
• Beamer: Pr¨ sentation62
a
• 1. Monitor: Twitter Feed
• 2. Monitor: Gruppe und Pr¨ sentation in Augsburg
a
Eine solche Konstellation ließe sich durch die Mashup-Anwendung auf einem Bildschirm
und in einem Browserfenster jeden Nutzers darstellen. Da die Pr¨ sentation nur in Pader-
a
born direkt auf den Beamer geworfen wurde, war es auch nur hier m¨ glich, diese zu be-
o
¨
dienen, da das Screensharing uber Skype die Bedienung nicht zuließ. Im Mashup w¨ re a
nun die Bedienung verschiedener Personen, unabh¨ ngig vom Aufenthaltsort m¨ glich. Ei-
a o
ne Aufgabe der Mashup-Anwendung liegt nun darin, die verschiedenen Elemente auf dem
Bildschirm oder Beamer zu verteilen. Hier bestehen zwei M¨ glichkeiten:
o
• Vergr¨ ßerung der Bildschirmfl¨ che: Ein Beamer mit h¨ herer Aufl¨ sung oder Zu-
o a o o
sammenschluss (Dual-Head) von zwei Beamern. Damit wird genug Platz geboten,
um alle genutzten Widgets in ausreichender Gr¨ ßer darzustellen.
o
• Aufteilen der Widgets: Mit der Mashup-Anwendung ist es m¨ glich die Widgets
o
auf verschiedene Computer zu verteilen. Wie in 4.2 bereits erw¨ hnt, kann jedes Ele-
a
ment auch einzeln genutzt werden. So ließe sich auf einem Beamer die Pr¨ sentation
a
in Vollbild zeigen, sowohl in Paderborn als auch in Augsburg. Videoconferencing
und Twitter-Feed k¨ nnten in einem Mashup auf einem weiteren Beamer gezeigt
o
werden. W¨ hrend im Seminar eine Videokonferenz nur zwischen den zwei Grup-
a
pen stattfand, ist in der Mashup-Anwendung auch jeder Einzelne in der Lage, sich
bei der Mashup-Anwendung anzumelden.
Weiterentwicklung von Systemen. Derzeitige VLEs haben die M¨ glichkeit durch ih-
o
re Modularit¨ t, Mashup-Technologien aufzugreifen und zu nutzen. Die Frage ist, ob der
a
Trend erkannt wird und dementsprechende Entwicklungen stattfinden werden. Bei Google
Wave k¨ nnen Gadgets unabh¨ ngig voneinander, wie Module, erstellt werden.63 Das zu-
o a
geh¨ rige Protokoll und große Teile von Google Wave sind Open Source, doch ein großer
o
Durchbruch, der auch die Entwicklung von Gadgets vorantreiben k¨ nnte, blieb bisher aus.
o
Aktuell wird das Potenzial, was in Google Wave steckt, noch nicht ausgesch¨ pft. Die Ar-
o
¨
chitektur jedenfalls erlaubt ahnliche Szenarien, wie sie mit dem Prototypen vorgestellt
wurden.
¨
62 Uber Skype Screensharing ebenfalls in Augsburg sichtbar
63 Wave Gadgets Tutorial: http://code.google.com/intl/de-DE/apis/wave/extensions/gadgets/guide.html
29

30. Zusammenfassend. Im Großen und Ganzen hat das Seminar selber gezeigt, dass f¨ r die u
Zusammenarbeit verschiedener Universit¨ ten keine Plattform existiert, die Kollaboration
a
unter Einbezug aktueller Technologien erm¨ glicht. Die Arbeit im Seminar war gekenn-
o
zeichnet durch eine F¨ lle an Diensten, die genutzt wurden. Speziell mit dem Ausblick
u
sollte die Ausarbeitung gezeigt haben, dass es m¨ glich ist, eine Plattform zu erstellen, die
o
die Arbeit, wie sie im Seminar stattgefunden hat, effizienter gestaltet.
Abbildungsverzeichnis
1 Unterst¨ tzungsfunktionen von Systemklassen ([BM02]) . . . . . . . . . .
u 7
2 Unterst¨ tzungsfunktionen von Systemklassen ([TSMB95]) . . . . . . . .
u 8
3 Enterprise 2.0 Mashup Platform EzWeb . . . . . . . . . . . . . . . . . . 9
4 Verbindung von Gadgets auf der EzWeb Plattform . . . . . . . . . . . . . 10
5 ¨
Verbindung zwischen Nutzern und Diensten uber Mashup-Server . . . . . 11
6 Funktionsweise der Mashup-Anwendung (vgl. [OBB07]) . . . . . . . . . 15
7 Registrierung zur Mashup-Anwendung . . . . . . . . . . . . . . . . . . . 19
8 Auflistung aller Whiteboards . . . . . . . . . . . . . . . . . . . . . . . . 19
9 Details eines Whiteboards . . . . . . . . . . . . . . . . . . . . . . . . . 20
10 Festlegen der Rechte auf ein Whitebord . . . . . . . . . . . . . . . . . . 21
11 Erstellung des Mashups - Auswahl des Whiteboards und des Videochats . 21
12 Mashup im Vollbild Modus . . . . . . . . . . . . . . . . . . . . . . . . . 22
Tabellenverzeichnis
1 Web 2.0 Dienste, Anbieter und Auspr¨ gung . . . . . . . . . . . . . . . .
a 6
Listings
1 Implementierung von GenericObject in Django . . . . . . . . . . . . 15
2 View-Funktion um Whiteboards zu bearbeiten . . . . . . . . . . . . . . . 16
3 URL Pattern f¨ r Whiteboards in der Anwendung . . . . . . . . . . . . .
u 17
4 Template zur Bearbeitung eines Whiteboards . . . . . . . . . . . . . . . 18
30

31. Literatur
[AENH09] A. Auinger, M. Ebner, D. Nedbal und A. Holzinger. Mixing Content and Endless
Collaboration–MashUps: Towards Future Personal Learning Environments. Universal
Access in Human-Computer Interaction. Applications and Services, 5616/2009:14–23,
2009.
¨
[B06] M. B¨ chle. Social software. Informatik-Spektrum, 29(2):121–124, 2006.
a
[BDS08] D. Benslimane, S. Dustdar und A. Sheth. Services mashups: The new generation of
web applications. IEEE Internet Computing, 12(5):13–15, 2008.
[Bee02] W. D. Beeland. Student engagement, visual learning and technology: Can interactive
whiteboards help. Annual Conference of the Association of Information . . . , 2002.
[BM02] G. Bafoutsou und G. Mentzas. Review and functional classification of collaborative
systems. International Journal of Information Management, 22(4):281–305, 2002.
[BnM09] C. Bre˜ a und A. L. Mart´nez. The Morfeo Project: an Open Source Approach towards
n ı
Open Innovation. 2009.
[CJWS09] M. Chatti, M. Jarke, Z. Wang und M. Specht. SMashup Personal Learning Environ-
ments. In M. Palm´ r D. M¨ ller F. Wild, M. Kalz, Hrsg., Proceedings of 2nd Workshop
e u
Mash-Up Personal Learning Environments (MUPPLE’09). Workshop in conjunction
with 4th European Conference on Technology Enhanced Learning (EC-TEL 2009), Sei-
ten 6–14, 2009.
[DT01] J. Desel und D. Tippe. Vorteile von computergest¨ tztem Lernen in Gruppen aus Sicht
u
der P¨ dagogischen Psychologie. Universit¨ t Eichst¨ tt, 2001.
a a a
[ESL07] N.B. Ellison, C. Steinfield und C. Lampe. The benefits of Facebook”friends:ßocial
capital and college students’ use of online social network sites. Journal of Computer-
Mediated Communication, 12(4):1143–1168, 2007.
[Fin06] Jonathan Finkelstein. Learning in Real Time: Synchronous Teaching and Learning
Online. Jossey-Bass, A John Wiley & Sons Imprint, San Francisco, 1. Auflage, 2006.
[Ham01] Thorsten Hampel. Virtuelle Wissensr¨ ume: ein Ansatz f¨ r die kooperative Wissensor-
a u
ganisation. Dissertation, Uni Paderborn, 2001.
[Kea07] K. Kear. Communication aspects of virtual learning environments: perspectives of early
adopters. 2007.
[LSR08] D. Lizcano, J. Soriano und M. Reyes. EzWeb/FAST: reporting on a successful mashup-
based solution for developing and deploying composite applications in the upcoming
web of services. Proceedings of the 10th . . . , 2008.
[Min09] Shailey (JISC/Unviversity Of Bristol) Minocha. A study of the effective use of social
software to support student learning and engagement, 2009.
[MTMB09] B. Means, Y. Toyama, R. Murphy und M. Bakia. Evaluation of evidence-based practi-
ces in online learning: A meta-analysis and review of online learning studies. Retrieved
October, 2009.
[OBB07] Ed Ort, Sean Brydon und Mark Basler. Mashup Styles, Part 1: Server-Side Mashups,
2007.
31

32. [Pet10] Jim (London Metropolitan University) Pettiward. university 2.0? using social software
to enhance learner engagement, 2010.
[PGF07] R. C. Portugal, L. A. Guerrero und D. A. Fuller. A Virtual Environment on the Web to
Promote Social Interaction and Collaborative Work. 2007.
[PSB+ 09] M. Palm´ r, S. Sire, E. Bogdanov, D. Gillet und F. Wild. Mapping Web Personal Lear-
e
ning Environments. In Proceedings of the second international workshop on Mash-Up
Personal Learning Environments (MUPPLE’09), ECTEL, Jgg. 9. Citeseer, 2009.
[RL08] S. Reushle und BI Loch. Conducting a trial of web conferencing software: why, how,
and perceptions from the coalface. Turkish Online Journal of Distance Education,
9(3):19–28, 2008.
[SB03] M. Scardamalia und C. Bereiter. Knowledge building environments: Extending the
limits of the possible in education and knowledge work. Sage Publications, Thousand
Oaks, CA, 2003.
[Smy05] R. Smyth. Broadband videoconferencing as a tool for learner-centred distance learning
in higher education. British Journal of Educational Technology, 2005.
[TD03] D. Tippe und J. Desel. Potentiale Virtueller Lerngruppen aus Sicht der Psychologie.
KI, 17(1):40, 2003.
[TSMB95] S. Teufel, C. Sauter, T. M¨ hlherr und K. Bauknecht. Computerunterst¨ tzung f¨ r die
u u u
Gruppenarbeit. Addison-Wesley, Bonn, 1995.
[YBCD08] J. Yu, B. Benatallah, F. Casati und F. Daniel. Understanding mashup development.
IEEE Internet Computing, 2008.
32

33. Medienbrüche im Web 2.0
Betrachtung von Web-Applikationen im Universitären Umfeld
Dennis Horstkemper, Marie-Luise Zankl
dhorstkemper@gmail.com
mazankl@gmx.net
Abstract: In der heutigen Zeit lässt sich ein Studium nur unter Nutzung der
einschlägigen Möglichkeiten, die das Web 2.0 bietet, absolvieren. Mit Hilfe
diverser Tools strukturieren Studierende nun also nicht nur ihren privaten Alltag,
sondern organisieren vor allem ihre Arbeit innerhalb des universitären Kontexts.
Für Kollaboration und Kommunikation werden zumeist mehrere Tools parallel
herangezogen. In der Folge kommt es zu sogenannten Medienbrüchen, was sich
nicht selten in einer empfindlichen Störung des Informationsflusses niederschlägt.
Um die Effizienz der studentischen Mediennutzung zu steigern, liegt es zunächst
nahe, die wichtigsten Gründe für Medienbrüche zu identifizieren und zu fragen,
wie solche „Bruchstellen“ gekittet und zukünftig vermieden werden können.
Eine Ist-Analyse, exemplarisch durchgeführt an den Universitäten Paderborn und
Augsburg, leitet in diesem Zusammenhang den Grundstock an theoretischem
Wissen über die Medienbruch-Thematik in praktische Anwendbarkeit über.
Ausgehend von den so gewonnenen Erkenntnissen wurde ein Tool entwickelt, das
die positiven Aspekte aus der Ist-Analyse weiterträgt und um einige sinnvolle
Neuerungen ergänzt.
33