So, nun sind wir schon wieder mitten drin im neuen Semester. Begonnen hatte es vergangene Woche mit den obligatorischen Semestereinführungen. Zudem gab es erstmals in unserem Fachbereich Media einen zweitägigen Workshop der Lehrenden und der Mitarbeiter, der dem Vorstellen aktueller Arbeitsgebiete und der Diskussion organisatorischer Fragen diente. In einem weiteren – eintägigen – Workshop haben schließlich die neuen PR-Studenten unsere Social Media-Szenerie – vom Blog PR-Fundsachen über das PR-Wiki (öffentliches Wiki), einem Gruppenarchiv bei Mister Wong bis hin zu den Google Sites (Gruppen-Wiki) kennengelernt. Da sich auch ein paar Kollegen aus dem Fachbereich besonders für unsere Erfahrungen mit Wikis interessiert haben, will ich ein paar Eindrücke zum Wiki-Einsatz in der Lehre zusammenfassen.
Ein weiterer Grund, ein paar Aspekte zu Wikis anzureißen, ist die hohe Aufmerksamkeit, die andere Social Media-Tools seit einiger Zeit haben, während Wikis offenbar nicht so intensiv diskutiert werden. Und schließlich ist zu erläutern, dass sich der Einsatz von Wikis zumindest bei uns im Studiengang etwas gewandelt hat – und zwar grob gesagt weg vom öffentlichen Wiki hin zum Wiki für Teams. Hier gibt es Wikis, die auf Dauer angelegt sind und solche, die ich als „Wegwerf-Wikis“ bezeichne. Dies sind Wikis, die jeweils nur für eine Gruppe zur Verfügung stehen, also ein oder höchstens zwei Semester genutzt werden. Ok, der Begriff „Wegwerf-Wiki“ ist etwas despektierlich – zumal, wenn ich sage, dass ich hierzu sehr gern die Google Sites verwende. Das ist aber gar nicht negativ gemeint. Zur Erklärung hole ich aber ein bisschen aus.
Hatte ich 2005 mit dem PR-Wiki ein vollkommen öffentliches Wiki eingeführt, so finden inzwischen die meisten unserer Wiki-Aktivitäten hinter verschlossener Tür statt. Genauer: Wir bilden mit unseren Wikis drei Arten von Öffentlichkeit ab:
- Weltweite Öffentlichkeit: dauerhaft angelegt; ein Ziel ist die Vernetzung der Hochschule mit der Praxis (im Wiki de facto kaum gelungen, findet statt dessen im Blog und über Twitter statt)
- Fachbereichs-Öffentlichkeit: v.a. für die Kommunikation und das Wissensmanagement von Student zu Student (z.B. Erfahrungsberichte zu Praktika). Das Journalismus-Wiki ist noch ganz neu, wie intensiv es gelebt wird, muss sich noch zeigen. Hier besteht natürlich eine gewisse Konkurrenz zu Gruppen innerhalb von StudiVZ, aus dem sich aber derzeit viele unserer Studenten verabschieden.
- Lehrveranstaltungs- bzw. Gruppenöffentlichkeit: E-Learning-Aspekte, v.a. aber Projektmanagment, nur für die Dauer eines Studienschwerpunktes, einer Lehrveranstaltung oder eines Projektes angelegt. Dieser Typ hat sich bisher sehr gut bewährt.
Jede dieser Öffentlichkeit hat also ein eigenes Wiki (oder mehrere). Der Hintergrund: Zwar werden im PR-Wiki nach wie vor Artikel veröffentlicht, doch hat sich darin nie eine wirkliche Kollaboration wie ich mir sie mit Blick auf die Wikipedia erhoffte, ergeben – offensichtlich fehlte es unserem kleinen Studiengang an einer gewissen kritischen Masse. Und auch die externe PR-Community hat sich daran noch nie beteiligt. Eine Rolle mag auch spielen, dass Journalismus-Studenten gerade das kollaborative Schreiben als fremd zu empfinden scheinen. Ein anderes und noch wichtigeres Problem, so zeigten Befragungen der Studenten, war die absolute Öffentlichkeit des Wikis. Die Studenten wollten weniger eine auf PR bezogene Enzyklopädie schaffen, sondern einen geschützten Arbeitsbereich für Seminare und vor allem für die Projektarbeit (mit den PR-Fundsachen besteht daneben ja ein Blog als öffentliche Kommunikationsplattform).
Der Wunsch nach einem nicht-öffentlichen Arbeitsraum stand also am Anfang einer veränderten Wiki-Nutzung. Zunächst setzten meine Kollegen und ich hierfür verschiedene pmWiki- oder Media-Wiki-Installationen ein. Wir schufen hier kein verbindliches Konzept, schließlich sollten die Studenten im Lauf ihres Studiums im Idealfall mit unterschiedlichen Systemen konfrontiert werden. Allerdings wurde ich den Eindruck nie los, dass die typische Wiki-Syntax und die zunächst nicht vorhandene Struktur solcher Wikis einigen Studenten Schwierigkeiten bereiteten – zumindest jedoch abschreckend wirkten.
Vor gut einem Jahr habe ich deshalb begonnen, für Lehrveranstaltungen (Seminare, Projekte) Google Sites einzusetzen. Meine ersten Eindrücke hatte ich hier beschrieben. Inzwischen habe auf dieser Basis etwa ein Dutzend Sites (=Wikis) eingerichtet, andere Kollegen setzen sie auch ein. Einzelne Sites nutzen Kollegen und ich gemeinsam, beispielsweise für organisatorische Aufgaben. Andere sind für studentische Gruppen allein zur Projektbegleitung eingerichtet. Im PR-Schwerpunkt bilden die Google Sites für mich eine Interims-Alternative zum für meinen Geschmack unhandlichen E-Learning-Tool Blackboard, das eigentlich nur vernünftige Kommunikation vom Dozenten zu Studenten erlaubt. Im Wiki dagegen sind alle Nutzer gleichberechtigt. So tragen die Studenten in den Ablaufplan eines Seminars zum Beispiel selbst ein, wann sie ihr Referat halten möchten. Und wer zu einem Seminarthema einen ergänzenden Literaturtipp hat, teilt ihn dort mit. Heute entstand gleich im Wiki das Protokoll eines Projektbriefings. In den vergangenen Semestern nutzten die meisten Studenten die Sites zum Projektmanagement (mit Ausnahme einer Gruppe, die ein Gruppenblog anlegte).
Und wie haben sich nun speziell die Google Sites als Wiki bewährt? Aus meiner Sicht recht gut. Kurz zusammengefasst haben sie Funktionen, die ich von einem Intranet 2.0 erwarten würde.
Vorteile:
- Die Orientierung: Es klingt banal, aber eine problemlos anpassbare (klassische) Navigation sowie die Möglichkeit, Seiten hierarchisch aufzubauen und die automatisch generierte Sitemap sind in einem Wiki sehr wertvoll.
- Die Multimedialität: Die Sites bieten u.a. die Möglichkeit, (Google-)Kalender, Videos, Bilder, Tabellen oder Google Docs (Präsentationen etc.) einzubinden.
- Die Funktionalität: Die Google Sites bieten einen selbsterklärenden WYSIWYG-Editor und ermöglichen unterschiedlichen Typen von Seiten. Neben der normalen Website lassen sich beispielsweise Downloads auf einer Seite in Ordnern organisieren oder es gibt Seiten mit anpassbaren Listen, die sich sehr gut für das Projektmanagement eignen. Und: Das Hochladen von Dateien ist ganz einfach.
Nachteile:
- Sicherheit: Zu Google als Anbieter und den Nutzungsbedingungen selbst muss sich jeder seine eigene Meinung bilden. Wirklich problematisch ist allerdings, dass es noch immer keine Möglichkeit einer eigenen Datensicherung gibt. Außerdem ist das Löschen einer kompletten Site nach meiner schmerzhaften Erfahrung etwas zu einfach – und dann absolut endgültig.
- Zugänglichkeit: Die Google-Sites kennen drei Rechte-Hierarchien: Eigentümer, Mitarbeiter und Leser. Allerdings gelten einmal vergebene Rechte jeweils für die gesamte Instanz und lassen sich nicht seitenbezogen definieren. Dies ist der Grund, weshalb ich so viele Instanzen eingerichtet habe, die letztlich Abbildung von Teamkonstellationen sind. Außerdem würde ich mir individuellere Abomöglichkeiten für Änderungen im Wiki wünschen – und diese vor allem mit RSS anstatt per Mail. A propos RSS: Am Einbinden von Feeds in das Wiki bin ich bisher gescheitert.
Ich muss betonen, dass die erwähnten Vor- und Nachteile kein Ergebnis eines systematischen Tests ist, sondern dass es sich um die Punkte handelt, die mir in der täglichen Nutzung besonders aufgefallen sind. Unterm Strich bleibt das Ergebnis positiv. Vor allem die erwähnten Vorteile kommen nach meinem Eindruck einer Facebook-gewöhnten Studentengeneration deutlich besser entgegen als die althergebrachten Kamelrücken-befüllten Wissensspeicher, die unsere früheren Wikis waren.
Inzwischen beginnt an unserem Fachbereich eine breitere Diskussion zu den Themen Wiki und eLearning-Plattform. Für eine solche systematische Anwendung werden wir vemutlich auf eine andere Plattform umsteigen (müssen). Dazu muss aber erst noch festgelegt werden, welche Ziele genau verfolgt werden sollen, dann erst wird die Suche nach einem System beginnen. Bis dahin sind für mich als Einzelkämpfer die Sites eine praktische Zwischenlösung, denn sie sind mit zwei Mausklicks eingerichtet und bieten auf Anhieb eine Fülle von Funktionen, die nur wenige andere Produkte haben. Für meine Zwecke werde ich mangels Zeit zunächst keine anderen Plattformen testen. Genau beobachten werde ich jedoch, welche Erfahrungen Heinz Wittenbrink in Graz mit dem Social Media Classroom machen wird. Denn ein integrierter Social Media-Ansatz für die Lehre dürfte einiges erleichtern – wobei ich einen dezentralen Ansatz bevorzugt habe. Mal sehen, ob ich das demnächst revidiere.
Ähnliche Artikel im Textdepot:
Danke für die ausführliche Besprechung von Sites. Habe es heute morgen ausführlich getestet und mich auch über die beiden Besprechungen als Basis gefreut – hat mir Aufwand erspart :-).
Unterm Strich werde ich nach direktem Vergleich von Wetpaint, pbWiki und Sites pbWiki fürs Kleinunternehmen wählen – pbWiki kann selbst in der kostenlosen Version das alles, auch RSS, und nach einem finanzierbaren Update auch noch viel mehr, z.B. SSL. Viele Grüße
LikeLike
Danke wiederum für den Hinweis auf pbWiki, scheint sich deutlich weiterentwickelt zu haben in den letzten Monaten :-). Sehe gerade, dass es neben RSS auch über Backup-Möglichkeiten verfügt – auf ersten Blick sehr gute Gründe, sich gegen die Sites und für pbWiki zu entscheiden.
LikeLike
Gern geschehen. Vor allem das Dokumentenmanagement finde ich ausgereifter und übersichtlicher. Allerdings haben sich die Anbieter von pbWiki was bei ihrem Geschäftsmodell gedacht: Das Backup geht nur in der kostenpflichtigen Business-Version http://pbwiki.com/content/pricing-basic-edition
Wer sich unbedingt ein Backup wünscht – verständlicherweise – dem bleibt von den obengenannten drei nur Wetpaint.com – HTML als Zip, in Sekunden.
LikeLike
Ah, ok, danke. Verständlicher Ansatz von pbWiki. In meinem Fall käme die Academic Version in Frage, deren Pricing mir auf ersten Blick angemessen erscheint (wenn ich überlege, wieviel unsere Hochschule bisher für die eLearning-Umgebung Blackboard bezahlt)
LikeLike