Das Textdepot

Mit den Tags ‘Wiki’ versehene Einträge

Infopaket: Wikis und Public Relations

8 Mai 2009 · Kommentar schreiben

Höchste Zeit, auf ein Infopaket hinzuweisen, das ich nebenan bei Agglom zusammengestellt habe: Hier geht’s um die Frage, wie Wikis in der PR (Webslideshow) eingesetzt werden können. Gesammelt habe ich Links zu Fallbeispielen und Erfahrungsberichten sowie zu Artikeln, in denen grundsätzlicher über die Einsatzmöglichkeiten von Wikis diskutiert wird. Besonders wichtig aus PR-Sicht ist natürlich der Umgang mit der Wikipedia. Hierzu gibt es eine eigene Sammlung (Wikipedia & PR, Webslideshow). Beide Sammlungen dienen für Interessierte als einfache Selbstlernpakete.

Zuvor jedoch noch ein paar ergänzende Überlegungen: Grundsätzlich ist der Einsatz von Wikis in vielen Organisationen erst einmal eine Frage des Wissensmanagements. Hierzu gibt es eine fast uferlose Literatur und entsprechend viele Studien. Sehr schnell ist man dann bei der Diskussion um Enterprise 2.0. Und natürlich kann diskutiert werden, im Einzelfall das Intranet schlicht durch ein Wiki zu ersetzen. Damit das Ganze nicht ausufert, habe ich nur einzelne Quellen aufgenommen, die den Blick in diese Richtungen lenken. Entscheidend ist aus meiner Sicht, dass sich in der Praxis zu diesem Thema Vertreter unterschiedlicher Herkunft zusammentun. Denn gerade beim Wiki-Einsatz werden die engen Wechselwirkungen zwischen Arbeitsprozessen bzw. Wissensmanagement und Unternehmenskultur besonders deutlich – und gerade beim letzten Punkt kommen die Kommunikationsexperten ins Spiel. Ebenso übrigens auch, wenn es um die Kommunikation zu einem Wiki geht.

Eine interne Wiki-Anwendung, die besonders nahe liegt, ist natürlich die innnerhalb von Kommunikationsabteilungen. Gerade wenn man es mit laufend anderen Themen zu tun hat (z.B. durch Anfragen von Journalisten), kann ein Wiki viel intere Recherche und Abstimmerei ersparen. Auch Texte (Presseinfos, Artikel, Imagetexte etc.) lassen sich im Wiki wunderbar schreiben bzw. abstimmen. Ob das so gemacht wird, weiß ich nicht. Mir ist zwar bekannt, dass einige PR-Agenturen Wikis einsetzen, auf Erfahrungsberichte von Kommunikationsabteilungen bin ich jedoch bisher nicht gestoßen.

Etwas weniger wahrgenommen werden in der Diskussion die Möglichkeiten, Wikis auch in der externen Kommunikation einzusetzen. Doch Wikis zu Städten oder touristischen Zielen, zu komplexen Produkten etc. zeigen, dass sie auf einfache Weise Community-Building und einen Nutzen für die Stakeholder zusammenbringen und Kommunikationsziele untersützen können.

Und dass das wichtigste Wiki im Netz, die Wikipedia, im Auge behalten werden sollte, dürfte sowieso klar sein. Ob allen jedoch bekannt ist, dass man Artikel dort sehr einfach beobachten kann, wenn man einen Account hat und angemeldet ist, bezweifle ich. Sehr viel schwieriger ist allerdings die Frage, ob PR-Leute selbst Hand anlegen sollen oder dürfen, um Artikel in der Wikipedia (um-) oder neu zu schreiben. Dass das gewaltig nach hinten losgehen kann, hat sich mehrfach gezeigt. Doch die Beispiele und die Diskussion dazu ist im Wikipedia & PR-Paket.

Damit das Selbstlernen etwas leichter fällt, hier noch ein paar Kontrollfragen:

  • Was sind Voraussetzungen für den erfolgreichen Einsatz von Wikis? (intern und extern)
  • Weshalb könnten Wikis für die Kommunikation von Nonprofit-Organisationen besonders geeignet sein?
  • Wie sind die Risiken eines eigenen Editierens in der Wikipedia einzuschätzen?
  • Was empfiehlt Wikipedia-Gründer Jimmy Wales Agenturen und Unternehmen?

So, nun wünsche ich viel Spaß und hoffe, das Ganze ist ein bisschen nützlich.

P.S.: Beide Pakete dürfen natürlich gern ergänzt werden.

Ähliche Artikel im Textdepot:

Kategorien: Lehre · Wiki
Mit Tag(s) versehen: , , , ,

Google Sites in der Lehre: Praktische Wegwerf-Wikis

31 März 2009 · 5 Kommentare

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:

Kategorien: Lehre · Tools
Mit Tag(s) versehen: , ,

Sites: Das Wiki von Google – erste Erfahrungen

11 März 2008 · 21 Kommentare

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:

Kategorien: Lehre · Wiki
Mit Tag(s) versehen: , , , ,

Sprachproblem: Wikis in internationalen Unternehmen

19 Februar 2008 · 3 Kommentare

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?

Kategorien: Wiki
Mit Tag(s) versehen: , , ,

Gehostete Wikis: Erste Erfahrungen

22 November 2007 · 7 Kommentare

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:

Kategorien: Wiki
Mit Tag(s) versehen: , , , ,