CMS Journal
Nr. 31
21.01.2009
Service
Metadaten
Hinweise
Weitere Artikel aus dem cms-Journal Nr. 31 finden Sie auf dem edoc-Server der Humboldt-Universität zu Berlin unter http://edoc.hu-berlin.de/cmsj/31
Copyright
Dieser Artikel ist ein Open Access Artikel und steht unter der Creative Commons Lizenz BY (siehe...).

Zope und Plone an der Humboldt-Universität


Katrin Lányi
lanyi@cms.hu-berlin.de

Abstract

Die Entwicklung von Zope wurde an der Humboldt-Universität von Beginn an aufmerksam verfolgt. Doch der breite Erfolg kam erst mit Plone. Und dennoch: Ganz unumstritten ist sein Einsatz bis heute nicht!


Der Einsatz von Zope hat an der Humboldt-Universität eine lange Tradition. Schon 1998 wurde das zu der Zeit fast unbekannte System in einzelnen Bereichen eingesetzt. Ca. zwei Jahre später wurde Zope nach Evaluierung der damals verfügbaren kostenfreien Content-Management-Systeme auch vom zentralen Webteam zur Pflege der universitären Hauptseiten ausgewählt. Durch den hohen Einarbeitungsaufwand in die Handhabung des Systems konnte es sich jedoch nicht sehr stark verbreiten. Im Prinzip gab es nur drei Sites, die wirklich unter Zope liefen. Hinzu kamen kleinere Tools, die einzelnen Bearbeitern das Schreiben von HTML-Code abnehmen sollten. Diese Dinge hätte man zweifellos auch mit PHP, das zu der Zeit stark verbreitet war, lösen können. Der große Durchbruch kam 2001 mit Plone. Seither hat sich die Welt der Webseitengestaltung stark verändert:

  • Viele Institute haben ihre eigenen Webserver aufgegeben und nutzen stattdessen die zentralen Zope/Plone-Server. Gleichzeitig wird die inhaltliche Verantwortung für die Institutswebseiten immer mehr dezentralisiert, was den Kommunikations- und Schulungsauf-wand insbesondere bei Änderungen und Migrationen stark erhöht.
  • Das Corporate Design der Universität hat sich über die Nutzung der zentral entwickelten Templates weitgehend durchgesetzt. Der blaue Navigationsbalken – etwas ungewöhnlich auf der rechten Seite platziert, damit die Köpfe der Brüder Humboldt nicht aus dem Bild herausschauen – bildet das unverkennbare Charakteristikum der HU-Seiten. (siehe Abb. 1: unterschiedliche Layouts, aber mit Wiedererkennungswert)
  • Barrierefreiheit ist bei der Nutzung von Plone für den Einzelnen kaum noch ein Thema.
  • Die Anzahl der Bearbeiter ist sprunghaft angestiegen − kaum die Hälfte hat noch fundierte HTML-Kenntnisse und leider können die modernen WYSIWYG-Editoren, die für Plone zur Verfügung stehen, dieses Defizit keineswegs ausgleichen.

Inzwischen ist Plone an der ältesten Berliner Universität etabliert. Die ca. 1400 aktiven Bearbeiter(innen), verteilt auf etwa 70 Zope/Plone-Instanzen, schätzen die intuitive Bedienbarkeit des Systems, das Inhalte, Stichwortverzeichnisse, Navigation und News-Übersichten ohne HTML-Kenntnisse erstellen lässt. Die Universitätsleitung begrüßt den erzielten Wiedererkennungswert der Institutsseiten, die trotz unterschiedlicher Gestaltung ein deutlich geschlosseneres Bild bieten als noch vor einigen Jahren. Tausende von HTML-Seiten wurden dazu nach Plone überführt.

image

Abb. 1: Webseiten der Institute

Für viele wichtige externe Systeme, wie die Adressdatenbank der HU1, das E-Learning-System Moodle 2, den zentralen Veranstaltungskalender, die verschiedenen LDAP-Server und die Einrichtungs- und Gebäudeübersichten, sind bereits Schnittstellen zu Plone geschaffen worden. Andere zur Forschungsdatenbank3 und zu HIS-LSF4 werden folgen.

Viele kleinere Produkte wurden entwickelt, um den Anforderungen an moderne Webgestaltung mit Blogs, Foren, Annotationen und Wikis genügen zu können. Eine Übersicht über die im Einsatz befindlichen HU-Produkte findet man auf den Seiten der Zope/Plone-Dokumentation der HU 5.

Um die vielen Inhalte von 70 Instanzen auch bei 3 Millionen Zugriffen pro Tag noch performant ausliefern zu können, ist durchdachtes, restriktives Caching erforderlich. 10 Server, LoadBalancer und Squid sind dafür im Einsatz. Derzeit werden ca. 490.000 Objekte bei einer durchschnittlichen Objektgröße von 29,42 KB und einem Cache-Füllstand von 48% im RAM des Clusters gehalten. Die Cache-Hit-Rate beträgt ca. 92 %. Und dennoch gilt die Optimierung des Cachings hier nach wie vor als technisches Schwerpunktthema, denn noch ist die Performance im Bearbeitungsmodus nicht zufrieden stellend und löst immer wieder Grundsatzdiskussionen aus. Da dieses Problem nicht nur an der HU auftritt, entstand schon frühzeitig der Gedanke, die Zope nutzenden Hochschulen besser miteinander zu vernetzen. Und so hat sich im Jahr 2007 der Arbeitskreis „Zope/Plone an Hochschulen“ gebildet, in dem übergreifende Themen gemeinsam diskutiert werden können. Teilnehmerinnen sind neben der HU Berlin die Universität Bonn, TU Dresden, Universität Freiburg, Universität Gießen, Universität Koblenz-Landau, Universität Magdeburg, Universität Marburg, die TU München und die Universität der Bundeswehr München. Gerade hinzugekommen ist ein Teilbereich der Medizinischen Hochschule Essen, der dabei ist, Plone einzuführen. Auf den Workshops in Berlin und München ging es dabei um Themen wie den Einsatz von Plone in Lehre und Forschung, die Integration externer Systeme, insbesondere der von vielen Hochschulen genutzten HIS-Systeme, um die Personalisierung von Inhalten und die unterschiedlichen Hosting-Konzepte. Die im Vorfeld des letzten Workshops durchgeführte Umfrage zum Zope-Einsatz an den Hochschulen brachte einmal mehr zum Vorschein, dass insbesondere die personelle Ausstattung der Plone-Teams an den meisten Hochschulen äußerst mager ist. Offensichtlich wird der Personalbedarf für die Betreuung eines Systems, das einer ganzen Universität zur Verfügung steht, regelmäßig stark unterschätzt. Umso wichtiger ist es, die Kräfte zu bündeln und Redundanzen zu vermeiden. Idealerweise könnte sich hier die Deutsche Zope User Group (DZUG) insbesondere bei den Themen Dokumentation, Schulung und Integration von Standardsoftware (für die Hochschulen sind das vor allem die Systeme der HIS GmbH) stärker einbringen und eine koordinierende Funktion übernehmen. In Berlin läuft derzeit die etwas aufwändige, aber lohnenswerte Migration auf die Plone-Version 2.5, die noch voraussichtlich bis Mitte 2009 andauern wird. Alle vor Ort entwickelten Produkte müssen dabei an die neue Zopeund Plone-Version angepasst werden. Alle Inhalte müssen exportiert, durch Skripte nachbearbeitet und anschließend wieder importiert werden. Nur das garantiert saubere neue Instanzen. Und da sich alte und neue PloneOberfläche geringfügig voneinander unterscheiden, müssen alle Nutzer eine Umstiegsschulung angeboten bekommen – bei der in diesem Jahr sehr spärlichen Personalausstattung oft ein Kraftakt. Inhaltlich spielt daneben das Thema „Kollaboratives Arbeiten“ eine zentrale Rolle. Hier geht es um die Unterstützung von weltweit agierenden Arbeitsgruppen, die gemeinsam Inhalte ablegen und bearbeiten müssen. Die Wünsche der Nutzer betreffen:

  • den Zugriff auf Plone-Ordner und die Ablage von Dokumenten mit Hilfe des Windows Explorers und anderer WebDAV-Tools,
  • den Zugriff auf Plone-Objekte mittels ODBC, um Daten auch in Office-Produkten nachnutzen zu können,
  • die Bearbeitung der Dokumente mit leistungsfähigen WYSIWYG-Editoren und möglichst auch offline,
  • eine Versionsverwaltung der abgelegten Dokumente,
  • die Bereitstellung von Blog-, Wiki- und Kommentierungsfunktionalitäten sowie
  • eine leistungsfähige Terminverwaltung in Plone inklusive des Terminaustauschs mit anderen Terminkalendern.

Was Plone zu diesen Themen zu bieten hat, beschreibt der Artikel „Kollaboratives Arbeiten mit Plone“ im gleichen Heft. Eines jedoch muss bei der Weiterentwicklung von Plone klar im Vordergrund stehen: die Stabilität. Noch nagen manche Effekte, wie sich scheinbar grundlos festfahrende Instanzen oder auch die Auslieferung falscher Sprachkataloge, an der Akzeptanz eines ansonsten guten und leistungsfähigen Systems.

Von Zeit zu Zeit werde ich gefragt, ob ich mich heute wieder für Plone entscheiden würde. Nun, eine Frau sagt niemals „ja“, allerhöchstens „vielleicht“.

 

Anmerkungen