Das Textdepot

So, wie versprochen fasse ich mal ein paar Eindrücke von Google Sites zusammen. Damit hat Google vor kurzem sein umfangreiches Angebot an Online-Services um eine Wiki-Funktionalität ergänzt. Genau genommen ist Google Sites Bestandteil von Google Apps, einem Paket, das einige der bekannten Google-Anwendungen (z.B. Docs, Mail, Kalender, Talk) zusammenfasst. Wie neulich erwähnt, habe ich mich (ich gebe zu: mit ein bisschen Bauchschmerzen) entschieden, die Sites im nächste Woche beginnenden Sommersemester für unseren PR-Schwerpunkt einzusetzen - anstatt der an unserer Hochschule sonst verwendeten eLearning-Plattform Blackboard.

Doch zunächst will ich kurz meine Anforderungen, die ich in diesem Fall an ein Wiki habe, erklären: Was ich wollte, ist ein schnell einsetzbares, gehostetes Wiki, das ohne ungewohnte Syntax gefüllt und einfach strukturiert werden kann. Im letzten Semester hat unser bisher verwendetes pmWiki einige Studenten und mich doch gelegentlich genervt (Probleme mit dem Editor, keine Diskussionsmöglichkeit in der Standardinstallation etc.). Weitere wichtige Anforderungen: Da wir mit dem PR-Wiki bereits über ein öffentliches Wiki verfügen, soll das aufzubauende Wiki nur für die jeweiligen Studenten und Dozenten zugänglich sein. Diese Abgeschlossenheit hat zwei Gründe:

• Erstens soll darin das Management von Semesterprojekten abgewickelt werden, d.h. darin werden auch halbwegs vertrauliche (bei weitem aber keine streng geheimen) Informationen gespeichert (z.B. ToDo-Listen).
• Zweitens habe ich festgestellt, dass ein nicht-öffentlicher Raum Studierende zu wesentlich intensiverer Zusammenarbeit im Wiki motiviert als ein öffentliches Wiki.

Doch nun endlich zu Google Sites. Bevor man sich dafür entschließt, ein wichtiger Hinweis: Man sollte sich wirklich klar werden, ob man die Nutzungsbedingungen von Google annehmen kann/möchte. Hierzu empfehle ich die Lektüre von Mediendidaktik zum Thema und die Diskussion bei Michael Kerres (Kommentare beachten). Ich bin jedenfalls zu dem Entschluss gekommen, es wagen zu können.

Gut, also zur Registrierung. Ich gebe ja zu, dass ich da erst ein wenig herumgepfuscht habe, da mir der Zusammenhang mit den Google Apps nicht gleich klar war. Und das ist für mich ein zentraler Kritikpunkt: Google will mit den Sites wohl nicht irgendwelche Privatleute ansprechen, die die Idee haben, mal ein Wiki einzurichten, sondern eine bereits bestehende Gruppe - z.B. ein Unternehmen, einen Verein, eine Schule oder Universität gewinnen. Und die sollen möglichst gleich den ganzen Google-Segen erhalten. Zur Anmeldung benötigt man eine Mailadresse einer Institution bzw. eine eigene Domain. Wer sich damit anmeldet, richtet das Ding für seine Institution ein - ich habe keine Ahnung, ob man damit für seinen gesamten Laden weitere Anmeldungen blockiert, vermute das aber. Wenn dem so ist, sind Probleme vorprogrammiert, die Google natürlich elegant auf die Institutionen abwälzt. Ok, das Ganze hat auch Vorteile, auf die ich hier aber jetzt nicht weiter eingehen möchte - wie auch auf die Google Apps insgesamt.

Wie arbeitet es sich denn nun mit den Sites? Kurz und bündig: “Gut”. Wie immer bei Google bin ich mit der Bedienung auf Anhieb klar gekommen, und einige Funktionen sind mir positiv aufgefallen:

• Es gibt ein paar Templates. Ich habe da nicht lange ausprobiert, sondern gleich eines gefunden, das mir geeignet schien. Es sieht u.a. eine Navigationsleiste vor, die ich editieren kann. Bei manchen Wikis muss man sowas erst über Umwege basteln.
• Eine Sitemap wird automatisch erzeugt.
• Jede Seite kann wie in einem Blog kommentiert werden. Sicher, das ist Geschmacksache - mir gefällt’s besser als eine eigene Kommentarseite
• Auf jeder Seite gibt es eine Uploadmöglichkeit für Dokumente. Das geht nicht bei allen gehosteten Wikis. 10 GB Speicherplatz sollten ein Weilchen genügen.
• Für jede neue Seite kann ich entscheiden, wo diese genau platziert werden soll (z.B. als Unterseite).
• Unterseiten werden am Fuß einer Seite automatisch verlinkt.
• Normale Wiki-Seiten sind mit dem WYSIWG-Editor problemlos zu bearbeiten.
• Ganz prima: Es gibt unterschiedliche Seitentypen: reine Wiki-Seiten (deren Layout lässt sich mit dem Editor auch auf zweispaltig umstellen), Announcements, Listen (gut geeignet für kleine Projekte, da gestaltbar und mit Prioritäten versehbar), Mashup-Seiten (= Dashboards in der Google-Sprache), und Download-Seiten (= File Cabinets). Letztere sind sehr gut geeignet, wenn man mehrere Dokumente zentral hochladen möchte. Man kann dann von beliebigen Seiten auf die einzelnen Dokumente linken, den Nutzern aber auch die gesamte Download-Seiten anbieten, auf denen alle Dokumente auf einen Blick zu sehen sind.
• Man kann unterschiedliche Dokumente aus dem Google-Universum (Präsentationen, Spreadsheets etc.) und so genannte Gadgets (Kalender, Feeds etc.) integrieren. Diese können direkt im Wiki angesehen werden, ähnlich wie auch Videos von YouTube und Google.
• Rollenbasierte Nutzung: Die Einladung von Mitarbeitern bzw. weiteren Administratoren hat bisher reibungslos geklappt. Einstellen lässt sich für jede Seite, ob sie öffentlich, für alle im Wiki Registrierten oder nur ausgewählte Nutzer zugänglich sein soll. Dabei kann nochmal unterschieden werden, ob die Nutzer die Seite nur sehen oder auch bearbeiten können.
• [Ergänzung, 12.3.08]: Als admin bekomme ich auf Wunsch per Mail Änderungen im Wiki sofort zugeschickt. Die Änderungen werden farblich hervorgehoben, Uhrzeit und Autor sind auch festgehalten.

Weniger gut gefällt mir:

• Es gibt keine Möglichkeit, Seiten zu sichern bzw. downzuloaden (abgesehen von pdf über das Drucken).
• Die Mashups haken manchmal, einige gehen gar nicht. Zum Beispiel hatte ich große Probleme RSS-Feeds einzubinden und das erst mal auf irgendwann verschoben. Mein Wunsch wäre, Social Bookmarks bzw. den Feed des bereits vorhandenen Mister-Wong-Gruppenarchivs ins Wiki zu ziehen.
• Die oben erwähnte Einrichtung über Google Apps

Ambivalent:

• Links werden von den Google Sites automatisch mit dem Attribut “nofollow” versehen. Hiergegen gibt es gute Argumente. Andererseits: Wenn die Sites als Intranet bzw. als nach außen abgeschlossener Bereich eingesetzt werden sollen, kann ich “nofollow” schon halbwegs nachvollziehen.

Mein Zwischenfazit nach etwa 20 eingerichteten Seiten: Das Arbeiten mit den Sites ist weitgehend problemlos. Die wenigen Dinge, die haken, habe ich bei anderen gehosteten Wikis in diesem Umfang bisher noch nicht gefunden. Statt dessen ist mein Eindruck, dass die Sites selbst ohne diese Funktionen etwas mehr bieten als manche andere Anbieter wie zoho. Besonders gut gefällt mir, dass die Sites zwar als typisches Wiki daher kommen, aber Funktionen haben, die einerseits das Projektmanagement und andererseits die Multimedialität unterstützen können.

Nach den bisherigen Erfahrungen scheinen die Sites also meinen Anforderungen für den Einsatz in der Lehre zu genügen. Nun müssen sie sich im realen Betrieb bewähren. Gut vorstellen kann ich mir auch, dass Vereine damit glücklich werden können. Ob ich die Sites bzw. das Gesamtpaket Google Apps jedoch im Unternehmen einsetzen würde, weiß ich nicht - da gibt es noch ganz andere Pakete, mit denen das verglichen werden müsste. Aber als einfaches, schnell aufsetzbares, kleines Intranet? Schon vorstellbar, meint auch der RSS-Blogger.

Um Missverständnisse zu vermeiden: Dieser Artikel spiegelt keinen systematischen Test oder Vergleich mit anderen Systemen wider, sondern ich schildere subjektive Eindrücke, die ich in den ersten Tagen der Nutzung der Google Sites gewonnen habe.

Weitergehende Lesetipps:

• TheReadWriteWeb: Google Sites - the next Sharepoint (…)?
• TechCrunch: It took 16 Months, but Google relaunches Jotspot
• Das Textdepot: Gehostete Wikis: Erste Erfahrungen
• Büffel, Steffen / Pleil, Thomas / Schmalz, Sebastian (2007): Net-Wiki, PR-Wiki, KoWiki – Erfahrungen mit kollaborativer Wissensproduktion in Forschung und Lehre. In: Stegbauer, Christian / Schmidt, Jan / Schönberger, Klaus (Hrsg.): Wikis: Diskurse, Theorien und Anwendungen. Sonderausgabe von kommunikation@gesellschaft, Jg. 8. (pdf)

Wer kann helfen? Eine Studentin fragt:

“Ich schreibe meine Abschlussarbeit bei der xy AG. Sie werden bald ein Wiki in ihr Intranet implementieren, welches dann europaweit von allen Mitarbeitern genutzt werden soll. Das große Problem ist die Sprache - Englisch war vorgesehen, aber das würde wahrscheinlich den Beteiligungsgrad der deutschen Mitarbeiter enorm senken, da viele kein oder nur kaum Englisch verstehen und somit kein Teil der englischsprachigen Wiki-Community werden könnten.

Meine Frage an Sie wäre, ob Sie mit solch einer Situation schon einmal Erfahrung gesammelt haben und evtl. Tools oder einen möglichen Lösungsansatz kennen, wie man mit solch einem Problem umgehen könnte?”

Hm, das Problem ist mir so noch nicht bewusst geworden; für mich sind Unternehmen selbstverständlich, die von ihren Mitarbeitern englisch als Geschäftssprache erwarten. Aus meiner Sicht ist eine gemeinsame Sprache Voraussetzung für das Funktionieren des Wiki-Gedankens in Unternehmen. Denn ein Wiki soll ja Leute zusammenbringen, die sich an unterschiedlichsten Stellen im Unternehmen mit ähnlichen Dingen beschäftigen. Sicher gibt es in den Landesgesellschaften eines Konzerns viele Anwendungsmöglichkeiten für einzelne Wikis. Doch dass Wikis ohne gemeinsame Sprache der Beteiligten für eine internationale Vernetzung sorgen können, bezweifle ich - mir fällt zumindest kein Tool bzw. kein Prozess ein, um das wirkungsvoll zu erreichen.

Wie sehen Sie das? Wissen Sie, wie internationale Unternehmen bei der Einführung von Wikis mit dem Sprachproblem umgehen?

Nachdem wir am Studiengang seit längerem mit eigenen Wiki-Installationen arbeiten (v.a. pmWiki, MediaWiki), habe ich vor einer Weile nach gehosteten Alternativen geschaut und mit dreien etwas herumgespielt. Inzwischen habe ich mit Zoho einen klaren Favoriten.

Grundsätzlich ist natürlich die erste Frage, ob man ein Wiki auf dem eigenen Server einrichten möchte, oder ob man ein gehostetes Wiki bevorzugt. Für mich liegen die Unterschiede vor allem in der Frage, wo meine Daten sind. Bei einem Wiki, das auf gemeinsam erarbeiteten Informationen basiert, vielleicht kein dramatisches Problem. Allerdings: Stellt ein Hoster seinen Dienst ein, fragt sich, was mit den erarbeiteten Inhalten passiert. Andererseits erspart ein gehostetes Wiki jeden Installationsaufwand und ist in zwei Minuten startbereit. Ich habe mich dafür entschieden, gehostete Wikis dann einzusetzen, wenn ich sie für zeitlich überschaubare Projekte oder eigene, aber nicht kritische Notizen einsetze.

Ausprobiert habe ich in den letzten Wochen drei gehostete Wikis, nämlich Wikispaces, Bluwiki und Zoho. Ich habe dabei ausschließlich kostenlose Angebote angeschaut. Ist man bereit, ein wenig für das Wiki-Hosting zu bezahlen, sind Backup-Möglichkeiten meines Wissens üblich, dazu hat man dann natürlich noch mehr Funktionen als bei den kostenfreien Varianten.

Am kürzesten habe ich mit Wikispaces gespielt. Das heißt aber nicht, dass es sich um ein schlechtes Angebot handelt. Zunächst zum Thema Abhängigkeit vom Hoster: Wikispaces bietet die Möglichkeit, Inhalte auf einen Knopfdruck zu exportieren (und damit z.B. lokal zu sichern). Außerdem gibt es verschiedene Vorlagen, um das Ganze zu gestalten. Die kostenlose Version hat zwei mögliche Nachteile: Zum einen gibt’s inzwischen nur  noch öffentliche Seiten, zum anderen ist Werbung drauf. (Ausnahme: für Lehrprojekte gibt es kostenlose werbefreie Wikis). Das Wiki selbst funktioniert problemlos, und zur Orientierung gibt es eine Navigation und Tags. Alternativ gibt es auch kostenpflichtige Varianten bei Wikispaces.  Bei ihnen gibt es z.B. die Möglichkeit (ähnlich wie bei Google Docs), die Privatsphäre einzelner Projekte zu steuern. Diese können also ganz privat sein, für eine definierte Arbeitsgruppe oder öffentlich. Auch, wer ein größeres Wiki betreibt, muss bezahlen.

Bluwiki ist dagegen kostenlos und werbefrei. Auch hier gibt es ein paar Skins. Doch entscheidend ist das nicht, sondern es handelt sich um ein sehr schlankes System, das alle Grundfunktionen eines Wikis enthält. Allerdings ist mir das Ganze inzwischen fast etwas zu schlank, denn sobald man mehrere Wikiseiten hat, ist es nicht ganz einfach, Orientierung herzustellen. Eine Navigation oder gar Tagging sind nicht vorgesehen. Ich bin deshalb dazu übergegangen, am Fuß jeder Seite einen Link zur Homepage oder ggf. zu einer anderen Seite manuell einzufügen. Bluwikis sind generell öffentlich, eine Exportfunktion der Inhalte habe ich nicht gefunden. Mein Beispielwiki, in dem ich z.B. mit kleinen Teams Material sammle oder Ergänzungen zu Vorträgen liefere, ist hier.
Der dritte Anbieter, Zoho, bietet nicht nur die Möglichkeit, Wikis einzurichten, sondern ist eine komplette, webbasierte Alternative zu Office - und noch mehr: Da gibt es neben dem Wiki den Writer (Textverarbeitung), eine Applikation für Tabellenkalkulation, eine für Präsentationen, ein virtuelles Notizbuch, ToDo-Listen, Chat- und Meetingmöglichkeiten sowie sogar eine Datenbank. 14 Anwendungen sind es inzwischen. Bisher habe ich nur mit dem Wiki gearbeitet. Und das funktioniert reibungslos. Da gibt es praktisch alle Funktionen, die auch Wikispaces bietet (die Steuerung der Privatheit ist bislang kostenlos; zudem gibt es Navigation, Tagging etc. Ausnahme: Export). Darüber hinaus gibt es eine Sitemap, für jede Wiki-Seite einen RSS-Feed sowie einen Feed, der eine Übersicht aller Änderungen liefert. Zusätzlich gibt es statt separater Diskussionsseiten eine Kommentarfunktion für jede Seite - Geschmacksache, mir gefällt’s. Schließlich bietet der WYSIWYG-Editor von Zoho sehr viele Formatierungsmöglichkeiten (fast schon zu viele), die aber zumindest bei den unterschiedlichen Varianten, um Links zu setzen, sehr hilfreich ist. Ebenfalls sehr schön: Ich kann unter einem Account mehrere Wikis einrichten und dort jeweils andere Zugangsregeln festlegen (also z.B. eines für private Notizen, eines für meine Arbeitsgruppe etc.) Im Moment Zoho noch kostenlos, doch dies dürfte sich im nächsten Jahr ändern. Wenn ich es richtig sehe, wird es aber auch weiterhin eine kostenlose Basisfunktion geben; bestimmte Funktionen (z.B. Backup, weitere Administration) sind jedoch in einem kostenpflichtigen Businesspaket enthalten. Wobei mir auch hierfür die Preise recht moderat erscheinen.

Mein Fazit: Wie gesagt bietet das Zoho-Wiki nach meinem Eindruck am meisten. Dies gilt allein schon für die Wiki-Funktionalität. Überlegt man, darüber hinaus noch mehr webbasierte Anwendungen zu nutzen, hat man sicher eine sehr gute Alternative zur Google-Welt. Ein wenig Geduld braucht allerdings, wer Mitarbeiter in sein Wiki einladen möchte. Im Härtetest mit etwa 20 gleichzeitigen Einladungen hat sich gezeigt, dass in drei Fällen die Anmeldung nicht ganz reibungslos geklappt hat und die Einladung oder die Registrierung nochmal gemacht werden musste. Waren die Mitarbeiter einmal drin, lief aber alles rund. Und was für den Arbeitsalltag wichtig ist: Zoho bietet ohne Installationsaufwand ein für meinen Geschmack wesentlich komfortableres System als zum Beispiel unsere pmWiki-Installationen (Beispiel), die erst mühsam an den Stand der Zeit angepasst werden müssen, aber dabei immer wieder an Grenzen stoßen bzw. einen versierten Admin erfordern.

Zum Schluss noch ein Hinweis: Ich habe die vorgestellten Angebote nicht systematisch getestet, sondern nur berichtet, wie sie sich mir aus Nutzersicht darstellen. Insofern gibt es sicher einige Aspekte, die anderen wichtig sind, ich aber hier nicht diskutiere. Ergänzungen, eigene Erfahrungen etc. sind deshalb natürlich sehr willkommen. Außerdem sollte natürlich jeder, der ein solches Wiki einrichtet, die Nutzungsbedingungen lesen, die habe ich jetzt hier gar nicht berücksichtigt.

Mehr zum Thema:

• Textdepot: Wikis in Hochschulen 
• kommunikation@gesellschaft: Wikis - Diskurse, Theorien, Anwendungen (Sonderausgabe)

Das ist eine nette Idee: Eine Art öffentliche Datenbank, die eine Übersicht gibt, wie Social Media in der PR eingesetzt werden (Fallbeispiele) bzw. welche Möglichkeiten es gibt (Theorie). Das Ganze funktioniert mit Zoho, einem Konkurrenzprodukt zu Google Docs, das jedoch leistungsfähiger ist. Initiiert wurde das Projekt vom Friendly Ghost, einem Londoner PR-Blogger. Das Dokument ist einerseits eine kleine Fundgrube, andererseits ein gutes Beispiel für Wissensmanagement im Web 2.0. Die Lösung ist für manche Aufgaben sicher eine gute Alternative zu einem Wiki.

Wikis dürften im Campaigning von NGOs in Zukunft eine immer wichtigere Rolle spielen. Ein gutes Anschauungsobjekt ist das Wiki des AK Vorrat, der sich gegen die geplante Vorratsdatenspeicherung engagiert. Dass in das Campaigning viele gute Ideen eingeflossen sind, zeigt die Übersichtsseite. Eine dieser Ideen: Plakate, die man - ganz im Sinne des Campaigings - selbst vervielfältigen und aufhängen kann:

In diesen Zusammenhang passt auch der Hinweis, dass natürlich auch eCard-Aktionen z.B. an Politiker, nach wie vor ein sinnvolles Instrument im Campaigning sein können. Eine solche Aktion hat nun campact begonnen und zwar zum Thema Online-Durchsuchung (via):

Markus, Student an der TU Berlin, hat ernst gemacht und das Wiki zum Sammeln akademischer Blogs, über das wir gestern bei Robert diskutiert haben, schon aufgesetzt. Dort können nun also munter Blogs eingetragen werden. Eingerichtet sind bisher drei Kategorien, und zwar für Blogs von Profs, Blogs von Studenten und Blogs aus dem Mittelbau. In die erste Kategorie ist schon Roberts Liste eingefügt, die anderen warten noch auf Input…

Denke, es ist gut, mit einer solchen Liste im Wiki einfach mal zu beginnen, die Zeit wird zeigen, ob sich dazu eine andere Darstellungsform lohnt/eignet. Wenn mal genügend Input vorhanden ist, wäre sicher Tagging o.ä. sinnvoll.

Soeben ist die zweite Sonderausgabe des Magazins kommunikation@gesellschaft (Herausgeber: Jan Schmidt, Klaus Schönberger und Christian Stegbauer) erschienen, diesmal zu Wikis. Unter anderem geht es um Qualität und diskursive Wissensproduktion in der Wikipedia, um Organisationsprinzipien von Wikis und um Erfahrungen mit Wikis - beispielsweise in der politischen Kommunikation oder in Forschung und Lehre.

In einem der zehn Beiträge (pdf) berichten Steffen Büffel (Trier), Jan Sebastian Schmalz (Münster) und ich über unsere Erfahrungen mit Wikis im medienwissenschaftlichen Umfeld (Net-Wiki, KoWiki, PR-Wiki). Zitat aus dem Abstract:

“Die Initiatoren der drei Wissenschafts-Wikis gehen in ihrem Erfahrungsbericht der Frage nach, inwiefern sich die Integration von Wikis als Arbeitswerkzeug und kollaborative Wissensplattformen in den Forschungs- und Lehrbetrieb eignen. Wikis ergänzen tradierte Formen der wissens­chaftlichen Wissensarbeit und Textproduktion durch die zunächst gleichberechtigte Beteiligung von Forschenden, Studierenden und Lehrenden und bilden die Bearbeitungs­schritte durch eine Dokumentation der einzelnen Textversionen ab. Multiautorenschaft, dezentrales und vernetztes Arbeiten sowie Strategien des Blended-Learning können so zum Einsatz gebracht werden.”

Dazu will ich aus meiner Sicht betonen, dass ich das PR-Wiki von einem Wissenschafts-Wiki inzwischen deutlich entfernt sehe. Zwar sind dort einige (halb-)wissenschaftliche Artikel (statt Hausarbeiten) entstanden und es werden seminarbegleitend Informationen dort abgelegt, doch nutzen wir die Wiki-Technologie im Studiengang Online-Journalismus inzwischen vorwiegend projektbegleitend. Das heißt, die Wikis (ja, eigentlich sind es inzwischen mehrere Installationen) dienen inzwischen als wichtige Tools dem Projektmanagement. Im Mittelpunkt des Artikels steht jedoch die Frage des Wissenschaftswikis - deren Diskussion mir viele Anregungen gegeben hat. Entstanden ist der Artikel übrigens stilecht kollaborativ, und zwar mit Google Docs.

Ähnlicher Artikel:

• Das Textdepot: Wikis an Hochschulen

Leserwahl: Habe ein bisschen in der WordPress-Statistik gewühlt und geschaut, welche Artikel aus diesem Blog besonders häufig gelesen wurden. 20 oft gelesene Texte habe ich in meinem privaten Wiki zusammengetragen und grob nach Themen sortiert. Die meisten beschäftigen sich mit Online-PR oder Praxisbeispielen aus der PR. 20 Artikel, 20 Links - im Vergleich zum Blog sieht das richtig aufgeräumt aus.

Auf die Idee gebracht hat mich schon vor längerer Zeit Robert Basic, der feststellte, dass Blogs per se ein lausiges Archiv haben und lesenswerte ältere Artikel oft nur schwer zugänglich sind. Robert hatte damals unterschiedliche Ansätze diskutiert, ein Archiv aufzubauen, das natürlich auch das Ziel hat, Besucher in den Long Tail des Blogs zu locken. Und eigentlich ist es naheliegend, dies innerhalb des Blog-CMS zu lösen. Mein Spieltrieb hat mich ins Wiki gelenkt. Hoffe, dass die Pflege des Archivs so ein bisschen leichter von der Hand geht als innerhalb des Blogsystems.

Die Mini-Auswertung der häufig gelesenen Artikel finde ich auch deshalb nett, weil sie zeigt, was Euch, liebe Leser, an diesem Blog am ehesten interessiert. Aber vorsicht: Das heißt nicht, dass ich künftig nicht mehr schreibe, wonach mir gerade ist…