……….
Am Beispiel des Portalprojekts e-teaching.org zeigt sich, wie eng Konzeption, Projektkontext und technische Realisierung verwoben sind. Mit der inhaltlichen Neuorientierung durch den Einbezug des Instituts für Wissensmedien wechselten gleichzeitig die Ansprüche an die
haltlich als auch organisatorisch in einem frühen Stadium, wodurch die genauen Anforderungen schwer konkretisierbar waren. Die ungenauen technischen Bedarfe spiegelten die inhaltlich noch unentschiedene und offene Konstruktion wieder. Trotz inhaltlicher Unklarheiten wurde von der Projektleitung die Entwicklung eines Fachkonzeptes angestrebt, das technische und gestalterische Anforderungen fixieren sollte.
Auszug aus einer E-Mail der Projektleiterin an Projektmitarbeiter in der Stiftung und am Institut für Wissensmedien: „… ist mir bewusst geworden, dass kein Weg an einem detaillierten Konzept vorbeiführt und wir unsere Auftragnehmer nicht einfach wurschteln lassen können. Dies gilt nicht nur für die IT Infrastruktur, sondern auch für das Webdesign. [....] Die zeitliche Verzögerung dafür müssen wir in Kauf nehmen. Arbeitspakete für die nächsten zwei Wochen sind damit die strategischen Entscheidungen und die Definition von Details - also mühsame Kleinarbeit. Der Vorteil von detaillierten Storyboards ist, dass wir auf diesen Folien auch schon den Originaltext (so wie wir Ihn auf dem Portal realisieren wollen) verfassen können und damit die redaktionelle Arbeit anlaufen kann.“ [7.1.2003]
Anstatt der anvisierten zwei Wochen dauerte die Erstellung des Konzepts insgesamt über zwei Monate. Im Januar und Februar 2003 wurde in enger Kooperation zwischen der Bertelsmannstiftung und dem Institut für Wissensmedien ein Fachkonzept für die technische Infrastruktur sowie die gestalterische Umsetzung erstellt. Die textliche Dokumentation erwies htlich einer räumlich verteilten Zusammenarbeit über institutionelle Grenzen hinweg. Insgesamt technische Infrastruktur. Während ursprünglich der Kauf von Einzelnutzungslizenzen des IBT-Servers der Firma time4you vorgesehen waren, sollte nun eine möglichst offene und flexible Lösung gewählt werden. Dabei kristallisierte sich die Verwendung der Open Source Produkte ZOPE und Plone heraus, da der Applikationsserver ZOPE auch am Institut für Wissensmedien als hausinternes Informationssystem eingesetzt wurde.
Im Frühjahr 2003 befand sich das Projekt sowohl in
sich nicht nur als zeitaufwändiger Prozess, sondern stellte auch hohe Anforderungen hinsic
wurden mehr als zehn Versionen des Fachkonzepts ausgetauscht. Der E-Mail-Verkehr mit Bezugnahme auf die Erstellung belief sich auf knapp einhundert E-Mails.
Abbildung 42: Versionshistorie Fachkonzept (Titelblatt des Dokuments)
Auf der Basis des Fachkonzepts wurden im März 2003 von 13 verschiedenen Firmen, die über ausgewiesene Vorerfahrungen mit dem CMS Plone verfügten, Angebote eingeholt. Nach einer Auswertung der Angebote wurde auf einen bereits bestehenden Kontakt zum Zentrum für Lehrerbildung (ZfL) an der Universität Bielefeld zurückgegriffen. Das ZfL wurde mit der Umsetzung des Redaktionssystems auf der Basis der Open Source Produkte ZOPE/Plone betraut. Das Fachkonzept bildete die Grundlage des Vertrags. Aus Sicht der Projektleitung sollte es als Kompass die technische Umsetzung steuern. Auf Arbeitsebene gestaltete sich dieser Prozess deutlich anders. Bereits in einem ersten Treffen einer Projektmitarbeiterin aus Tübingen und dem für die Programmierung und technische Umsetzung verantwortlichen Mitarbeiter des ZfL wurden zentrale Vorgaben zur Inhaltsorganisation im Fachkonzept grundlegend umgestellt.
Es zeigte sich rasch, dass das starre und sehr differenzierte Fachkonzept als Grundlage der technologischen Entwicklung ungeeignet war und sich diese in kürzester Zeit von der Textvorlage entkoppelte. Unmittelbar wurde beispielsweise die im Fachkonzept vorgesehene Gliederung der redaktionellen Texttypen aufgegeben. Eine rekursive Struktur ersetzte die bis dato vorgesehene hierarchische Gliederung des Content. In der Folge erwies sich die Genese der technischen Infrastruktur als ein dynamischer, komplexer sozialer Aushandlungsprozess, der eine intensive Abstimmung zwischen Redaktion und Technik erforderte. Hierzu wurden im weiteren Verlauf Listen geführt, die offene Punkte und anliegende Entwicklungsschritte unkompliziert integrieren konnten.
Auszug aus einer Gesprächsvorlage vom Juli 2003 mit dem Titel Offene Punkte / Next Steps Redaktionssystem: „Dokumentation / „Nutzerhandbuch“: Wann? Content Objekt Literatur: Ist der Vorschlag vom 22.7. brauchbar? Wann könnte ein entsprechendes Literaturobjekt zur Verfügung stehen? […] Workflow: Kann ein Dokument, sobald es geöffnet ist, für andere zum Bearbeiten gesperrt werden? Wie können konkurrierende Zugriffe geregelt / vermieden werden?
(Rollenkonzept? – vgl. ursprünglichen Redaktionsprozess) [Datei vom, 29.07.2003]
Im August 2003, nach einer knapp einjährigen Vorlaufzeit, konnten zum ersten Mal online Inhalte eingepflegt werden. Hierzu wurde zunächst eine Übergangs-URL verwendet. Damit war die technische Entwicklung jedoch keinesfalls abgeschlossen. Vielmehr ergaben sich aus der Evaluation und der redaktionellen Arbeit fortlaufend neue Anforderungen an die technische Betreuung und Entwicklung.
kte wie Texte, Bilder oder Dateien nicht an das Layout gekoppelt, sondern strukturiert und mit Metainformationen versehen Innerhalb eines Redaktionssystems werden die einzelnen Inhaltsobje
in einer objektorientierten Datenbank gespeichert. Plone stellt zu diesem Zweck eine Vielzahl von Content-Objekten bereit, wie z.B. Dokument, Bild, Datei, etc. Das Redaktionssystem verwaltet die Objekte in der ZOPE eigenen Datenbank. Die gewünschten Zielformate werden über Transformationsskripte (Zope Page Templates) generiert. Jedes neue inhaltliche Format bedingte somit auch eine technische Begleitung. Diverse Contentobjekte wurden speziell für die Zwecke des e-teaching Portals definiert, wie z.B. Steckbrief, Referenzbeispiel, Glossarbegriff, Literatureintrag, Pop-up Fenster. Gleichermaßen mussten die Design-Änderungen jedes Mal technisch abgestimmt und implementiert werden.
Als zentrales Kommunikationsmittel zwischen Redaktion und Technik diente eine Mailingliste.
Der hohe kommunikative Aufwand bei der Entwicklung zeigt sich in der Zahl von über 1.200 E-Mails, die im Zeitraum von Juni 2003 bis Dezember 2004 über den Verteiler versendet wurden.
Eine wichtige Erfahrung dabei war, dass einmal installierte und etablierte Kommunikationswege nur schwer zu ändern sind: Für eine bessere Strukturierung der Kooperation – insbesondere bei der Fehlerbehebung („Debugging“) wurde nach ca. einem dreiviertel Jahr Projektlaufzeit ein Forum als so genannter „Bug Collector“ eingerichtet. Dieses Forum bot zwar eine höhere Übersichtlichkeit, nichtsdestotrotz wurde es nur ca. 3 Wochen aktiv genutzt, dann wurde wieder auf die besser etablierte Form der Mailingliste zurückgegriffen.
Als weitere Artefakte, die den Entwicklungs- und Nutzungsprozess strukturieren sollten, sind Benutzungsleitfäden zu nennen, die im Projektverlauf entwickelt und in gewissen Abständen
Anleitungen
also in Bezug auf Effizienz und Nutzerzufriedenheit essentiell, aktualisiert wurden. Ein erster, noch recht knapper Leitfaden wurde im August 2003 erstellt und im ca. halbjährlichen Turnus aktualisiert und erweitert. Ende 2004 wurde den externen Projektpartner ein Leitfaden zur Verfügung gestellt, der speziell auf Ihre Redaktionssicht als Hochschulredakteure zugeschnitten war. Die Problematik der fehlenden oder mangelhaften Dokumentation für Nutzer ist die Kehrseite der hohen Flexibilität und Adaptionsfähigkeit von Open Source Produkten. Unvollständige, fehlende oder nicht zielgruppengerechte
sind ein entscheidendes Hindernis für den Gebrauch der technischen Infrastruktur im von den Entwicklern intendierten Sinne. Häufig sind sich Nutzer des Funktionsspektrum nicht bewusst und verwenden Funktionen entweder gar nicht oder anders als vorgesehen, woraus sich wiederum Entwicklungsbedarf ergibt, der bei einer genauen Dokumentation und Schulung nicht nötig gewesen wäre. Es ist
genügend Zeit für die Erstellung von Schulungsmaterialien und Nachschlagewerken
einzuplanen. Eine besondere Herausforderung stellt dabei die Aktualisierung und Anpassung der Dokumentationsmaterialien an eine sich dynamisch wandelnde Infrastruktur dar.