Sites: Das Wiki von Google – erste Erfahrungen

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:

Schlagworte: , , , ,

Über Thomas Pleil

Mein Beruf: Ich lehre Public Relations an der Hochschule Darmstadt und beschäftige mich vor allem mit Online-Kommunikation. Mein Hobby: Schnappschüsse sammeln. Zum Beispiel hier: http://bilddepot.wordpress.com. Mehr von mir im Web: http://about.me/thomaspleil.

22 Antworten zu “Sites: Das Wiki von Google – erste Erfahrungen”

  1. keksler sagt :

    Werden die Leistungen der Studenten bewertet? Wenn ja, wie behält man den Überblick bei vielen Artikeln und noch mehr Versionen zu jedem einzelnen Artikel? Oder findet die Bewertung zu einem bestimmten Zeitpunkt statt?

  2. Barbara Niedner sagt :

    Also vielen Dank für den Bericht! Wäre stark daran interessiert weitere Erfahrungen vom aktiven Einsatz zu erhalten.

    Habe selbst in der Lehre an der Universität der Bundeswehr München mit Studenten eine Zoho Wiki aufgebaut. Zoho ist eindeutig, wie schon mal hier beschrieben, nicht geeignet.

    Allerdings haben meine Studenten einen relativ großen Vorbehalt gegen Google und dessen Macht … gläserner Nutzer etc..

    Ich bin gerade am überlegen, welches System ich im nächsten Trimester einsetzen werde … momentan tendiere ich zu Drupal. Bin mir aber noch nicht ganz sicher. Daher verfolge ich Dein Projekt mit Spannung!

    Parallel zur Gruppeninternen Wiki, gibt es auch einen öffentlichen
    - Blog http://www.web2blogs.de und
    - Podcast http://www.FlirtPodcast.de
    Die Blogs laufen mit WordPress und das klappt mit den Studenten ganz gut. Durch viele Autoren sind die Beiträge halt nicht ganz so einheitlich in der Formatierung.

    Zur Benotung: Bei mir erstellt jeder Student in der Wiki eine eigene Seite, wo er selbstständig protokolliert was er getan hat. Das funktioniert ganz gut. So fördert man auch kollaboratives Arbeiten über Gruppen hinweg. Als Verhaltensbiologin folge ich die These “Gemeinnutz durch Eigennutz” und so motiviert es auch Studenten aktiv bei anderen Gruppen bzw. Themen mitzuwirken.

  3. Thomas Pleil sagt :

    @keksler: Ja, bewerten muss ich. Da habe ich unterschiedliche Ansätze, je nach Lehrveranstaltung: Bei Projektveranstaltungen gehe ich wie Barbara vor und verlange zusätzlich von jedem Studenten noch eine Reflexion zum Projekt und der eigenen Leistung. Aber die Gruppenleistung spielt schon eine wichtige Rolle. Bei Seminaren setzt sich die Note aus mehreren Bestandteilen zusammen (z.B. Blog-Beiträge in den PR-Fundsachen, Kurzreferat + Artikel dazu, Übungsaufgaben). Aufwändig ist das Ganze tatsächlich, aber ich hoffe, es wird den Studenten gerecht.

    @Barbara: Danke für die Hinweise und Einschätzungen – spannende Projekte macht Ihr!

    Deine Erfahrungen mit zoho waren ausschlaggebend, dass ich hierauf nicht gesetzt habe.

    Google als Anbieter: Ja, da habe ich auch etwas Bauchschmerzen. Andererseits ist’s halt sehr bequem, da meine Kollegen und ich bereits den Google Kalender und die Docs nutzen und ich nix installieren wollte….

  4. Matthias sagt :

    Wie sind denn die PBwikis als Alternative zu Google? Da ich die Google Apps tendenziell meide, kann ich selbst nicht direkt vergleichen.

    Erste Erfahrungen in einem Projekt mit pbwiki liegen vor. Auch dort sind in der kostenlosen Basis-Variante praktisch alle hier im Artikel erwähnten Punkte auch gegeben.

    Ein pbwiki ist extrem schnell eingerichtet, verfügt über einen WYSISYG-Editor und kann bei Bedarf aufgerüstet werden: Gegen Entgelt gibt es mehr Speicherkapazität und auch etwas mehr Funktionsumfang.

  5. keksler sagt :

    Wenn ich es richtig verstanden habe, dann dient das Wiki also eher dazu, nicht ständig eine neue Version des Dokuments hochladen zu müssen. Entscheidend ist also der letzte Stand des Dokuments. Gruppenarbeiten sind wahrscheinlich nach Autor getrennte Einzeldokumente, oder?

  6. Thomas Pleil sagt :

    @Matthias: pbWiki ist bestimmt eine Alternative.

    @keksler: Unterschiedlich. Teilweise stimmt das mit dem Ersetzen von Mails. Bei Projekten müssen aber auch Dinge gemeinsam erarbeitet werden – z.B. eine PR-Konzeption. Ein wieder anderer Bereich ist der, in dem ich Material für Lehrveranstaltungen bereitstelle (Ablaufplan, Literatur). Hier können Studenten ergänzen, ihre Referattermine und -themen eintragen und Themenvorschläge machen für einzelne Lehrveranstaltungen (ich habe im vergangenen Semester einen ganztägigen Abschlussworkshop gemacht, dessen Agenda die Gruppe entwickelt hat, das hat sehr gut geklappt).

  7. keksler sagt :

    Ok, wahrscheinlich war ich etwas zu sehr auf trennbare und damit benotungsfähige Beiträge fixiert :-)

    Die Collab-Unterstützung drumherum ist natürlich eine feine Sache, speziell die Versionierung bei Terminansetzungen.

  8. Jo sagt :

    Klasse Artikel. Danke :) Nun hab ich die Sites auch endlich in meinem Google Apps Account entdeckt.

    Findes es ziemlich schade dass der deutsche User da wieder einmal beschnitten wird.

    Ähnlich gmail und IMAP.

    Grüße

  9. Ludwig sagt :

    Hallo, danke für die ausführliche Beschreibung. Scheint eine gute Sache zu sein, vor allem wenn man eh schon ausführlich mit Google arbeitet.

    Mein persönlicher Favorit, leider wieder nur in Englisch, ist http://www.wetpaint.com. Müsste auf den ersten Blick auch das alles können, nur die Integration eben von Google Docs und co. nicht. Viele Grüße

  10. Thomas Pleil sagt :

    Super, danke für den Hinweis. Werde ich bei Gelegenheit mal näher anschauen. Für die nächste Zeit ist die Entscheidung allerdings gefallen…

  11. Christiane sagt :

    Ich hatte im letzten Semester Zoho Projects. Es lief ganz gut, aber ich würde mittlerweile davon abraten. Das Hauptargument dagegen ist, dass es nicht auf einem eigenen Server läuft, außerdem war es zu Projektende nicht mehr verfügbar! Abgesehen von der relativ strikten Mengenbegrenzung, die Windows-Vista-Powerpoint-Präsentationen per se ausschließt.
    Grundsätzlich gilt das Hostingproblem auch für Google Apps bzw. alle anderen ähnlichen Dienste. Drupal dagegen ist sehr mächtig, kann selbst gehostet werden und ist sicherlich nachhaltiger verfügbar. Die Lizenzbedingungen von Google schließlich sind ein weiterer Minuspunkt. Für eine Lehrveranstaltung mögen sie okay sein, aber gewöhnt man sich nicht so an eine Umgebung, dass man sie irgendwann nicht mehr verlassen möchte? Und dann vielleicht doch Inhalte einstellt, die sich mit der Lizenz eigentlich nicht vertragen? Ich würde jedenfalls für das nächste Projektseminar auf Drupal setzen und es so aufbauen, dass es auch für weitere Seminare verwendbar ist.

  12. Thomas Pleil sagt :

    Ja, da spricht sehr viel dafür, Christiane. Möglicherweise werde ich zum Wintersemester einen ähnlichen Weg gehen. Für die meisten Dozenten ist allerdings eine gehostete Lösung besonders attraktiv, da sie entweder selbst nicht die Zeit/Kenntnis haben, ein CMS wie Drupal aufzusetzen oder keinen entsprechenden Support bekommen. Ehrlich gesagt, hätte ich es in den letzten Wochen nicht geschafft, mich um eine Installation zu kümmern, bei einem gehosteten Service beginne ich sofort, Inhalte einzupflegen.

    Die Gegenargumente speziell gegen Google bleiben natürlich bestehen…

  13. Ingo Neitzke sagt :

    Unbedingt anschauen:
    Intranet-Wiki > nuospace.com

  14. Thomas Pleil sagt :

    Sieht auf ersten Blick sehr interessant aus, danke schön für den Hinweis. Werde ich bei Gelegenheit mal probieren ….

  15. Judith sagt :

    Danke für diese ausführliche Beschreibung. Klingt schon sehr interessant, bin schon mal gespannt. Danke.

  16. tom sagt :

    Hallo,

    Wir sind gerade dabei zu entscheiden welche Knowledge-Management Plattform wir nutzen. Sites hört sich auf jeden Fall interessant an und auch mit der Integration zu Google Apps eine echte Alternative.

    Dein Beitrag hat mir echt weitergeholfen.

    Danke,

    Tom

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ photo

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 221 Followern an