Community-Plattformen und Contentmanagement – Teil 2/3

Contentmanagement: Der zweite Teil widmet sich technischen Fragen des Zusammenspiels beider Systeme und der technischen Integration von horizontalen und vertikalen Contents.

I. Zusammenfassung der bisherigen Kernthesen von Teil 1

Bei Communities ist es sinnvoll zwischen Original- und AddOn-Lösungen zu trennen. Originals bilden von Beginn an eine strategische Einheit von Community-Elementen und Content-Angebot. Sie besitzen meist eine für diesen speziellen Fall maßgeschneiderte Software. Bei AddOn-Projekten wird ein separates Community-Angebot an ein bereits bestehendes Angebot angeschlossen.

Die erfolgreichen „Web 2.0 Vorzeige-Modelle“ sind meist Originals. AddOn’s werden dagegen vom User häufig als (schlechte) Kopie der Originals empfunden. Nicht selten sind sie genau deshalb weniger erfolgreich.

Eine weitere Kernthese ist die Unterscheidung von vertikalen und horizontalem Contentmanagement:

Vertikales Contentmanagement beschreibt das klassische System „Redakteur liefert Inhalte für User mit einem CMS“. Horizontales Contentmanagement ist UGC entsprechend der Formel „User liefern Inhalte für andere User auf Basis einer Community-Software“.

Eines der wenigen erfolgreichen Beispiele für AddOn’s ist die schwedische Tageszeitung expressen.se . Deren Case-Study dient für diesen Beitrag als Leitfaden.

II. Technische Integration & Contentmanagement

1. Grundsätzliche Strukturen

Kommt es bei einem AddOn-Projekt zum ergänzenden Aufbau einer Community, stellt sich die Frage, ob und wie weit man beide Systeme bzgl. Front- und/oder Backend vereint.

Vorab gilt es festzuhalten:

Man kann bei AddOns selbstverständlich beide Systeme nahezu vollständig trennen bzw. getrennt lassen. Dies ist zum Beispiel der Fall, wenn ein Unternehmen einen bereits etablierten Blog inklusive Technik und Usern „einkauft“. Ähnlich liegt der Fall bei Third-Party-Blogs oder auch bei meist kleineren Blog-Satelliten, die um das Kernangebot als selbständige Einheiten aufgebaut werden. Hier stellt sich die Frage nach der Integration anders oder gar nicht.

Bei expressen.se bestand dagegen von Anfang an das Ziel, möglichst viele Synergien zwischen Community und Homepage, also zwischen vertikalem und horizontalem Content zu ermöglichen.

Der Kauf eines bereits etablierten Blog-Anbieters hätte zwar direkt am Start an einen viel mehr registrierte User ermöglicht sowie darauf aufbauend einen höheren Traffic vermuten lassen (mancher namhafter Mitbewerber von Expressen hat es auch genau so gemacht). Dies hätte aber eine möglichst homogene Integration aller Systeme in strategischer und technischer Hinsicht voraussichtlich erschwert. Zudem wäre dann eine eigene maßgeschneiderte Gesamtlösung kaum möglich gewesen.

a. Community-Strategie / Szenarienbildung

Um die Herausforderung einer integrierten Variante technisch zu lösen, galt es zunächst eine Community-Strategie zu entwickeln und anschließend die vorhandene und die zukünftige technische Struktur mit denn neu entstehenden Schnittstellen zu analysieren bzw. zu definieren.

Struktur vor Einführung der XCAP-Community-Software

Struktur nach Einführung der XCAP Community-Software mit Kommentar- und Blog-Modul

Finale Struktur inklusive aller Zusatzmodule

Blau markiert sind die vertikalen, rot die horizontalen Infrastrukturen.

Bei expressen.se waren für den Anfang zwei UGC-Hauptbereiche mit Schnittstellen für das Zusammenspiel von horizontalen und vertikalen Inhalten geplant:

1. Die Artikel-Kommentierung
2. Der Blogg

In beiden Fällen kommt es frontendseitig zum Zusammentreffen von vertikalen und horizontalen Inhalten – allerdings in jeweils reziprokem Verhältnis:

– Im ersten Fall werden die vertikalen Inhalte um horizontale Inhalte ergänzt.
– Im zweiten Fall ist es genau umgekehrt: Hier führen die horizontalen Inhalte und die vertikalen Inhalte sind eher untergeordnet.

b. Frontend (Contentmanagement)

Technisch führt dies zur jeweils unterschiedlichen „Führungsrolle“ von jeweils einem der beiden Systeme: Entweder führt die Communty-Software oder das CMS. Das jeweils andere System ist je nach Bereich untergeordnet.

Solche kombinierten Szenarien sehen meist wie folgt aus:

1 Über ein und das gleiche Frontend werden Daten aus verschiedenen Datenquellen angeboten

2 Eines der beiden Systeme liefert die Hauptinhalte

3 Das jeweils andere System liefert Nebeninhalte

4 Während die vertikalen Daten regelmäßig über keinen Rückkanal verfügen, muss der horizontale Bereich frontendseitig die Möglichkeit beinhalten, Inhalte vom User zu generieren.
Bei der Artikel-Kommentierung ist es das bisherige CMS, das die Hauptinhalte liefert. Beim Blog von expressen.se ist es genau umgekehrt.

Bei expressen.se werden also beide Varianten parallel eingesetzt:

1 Zuerst wurde mit der Artikel-Kommentierung ein integriertes Frontend geschaffen, das überwiegend Daten aus dem vertikalen CMS beinhaltet.

2 Zudem wurde mit dem Blog ein Angebot geschaffen, das überwiegend durch die Community-Software generiert wird.

3 Beide Systeme beziehen aber jeweils Informationen des anderen Systems und integrieren diese ins eigene Frontend.
In beiden Fällen ist die Art der technischen Integration von Inhalten unterschiedlich gelöst.

Ein Blick auf die Frontend-Oberfläche der Artikel-Kommentierung erläutert das Zusammenspiel beider Elemente aus Sicht des Users.

Die blau markierten Elemente der Artikel-Kommentierung sind vertikale Contents. Der rot markierte Bereich skizziert das Eingabeformular und die bereits zum Thema geposteten Kommentare (beides Elemente horizontalen Contentmanagements).

Die Struktur beim Blog ist entsprechend der Art von Inhalten anders:

Hier kommen nahezu alle Inhalte mit Ausnahme des Headers direkt aus der Community-Software XCAP. Es überwiegen bei weitem die horizontalen Contents. Vertikale Inhalte sind selten.

c. Technische Umsetzung

Vorab: Speziell für die Artikel-Kommentierung benötigt man grds. keine spezielle Community-Software. Der technische Vorgang, Usereingaben zu erfassen und einem bestimmten Artikel zuzuordnen ist kein Hexenwerk.

Manche CMS bieten eine solche Kommentierungsmöglichkeit bereits mit an. Im Grunde würde sogar ein schlichtes PHP-Skript ausreichen, um Kommentare einem Artikel zuzufügen.

Einer der wichtigen Gründe, warum beide Varianten mit der gleichen Software-Kombination verwirklicht wurden, liegt in der Spezialisierung und damit in einer der Besonderheiten der Community-Software XCAP:

– XCAP verfügt über einen Rulemanager
– XCAP verfügt über eine automatisierte Inhaltskontrolle

Zunächst zum Rulemanager. Dieser ermöglicht die zeitliche und inhaltliche Kontrolle bzw. Freigabe von User-generierten Inhalten nach Zeit, Userrechten oder Laufzeit von Inhalten (dazu näher in Teil 3).

Ebenfalls damit verbunden ist eine innovative, aber technisch aufwändige Inhaltskontrolle. Eine solche Funktion ist bei User genierten Inhalten aller Art wenn schon nicht unbedingt notwendig, so doch wenigstens sehr empfehlenswert.

Insofern profitiert die Artikel-Kommentierung als quantitatives Minus gegenüber dem umfangreichen Blog von den technischen Features der Community-Software. Mit ein und der gleichen XCAP Lizenz konnten damit alle Funktionen für beide Varianten eingesetzt werden.

Nicht zuletzt ist diese Lösung auch aus Sicht der User zu begrüßen. So können alle von ihnen erstellten Inhalte – egal ob als Kommentar oder Blog-Beitrag – einheitlich verwaltet werden. Gleiches gilt für Login-Informationen und ggf. auch für Reklamationen von Inhalten des Users, die das System nicht veröffentlichen möchte und ablehnt.

 

2. Frontend- und Backend-Integration für Contentmanagement

Die Frage, wie diese beiden Ergebnisse technisch im einzelnen Fall erzielt werden können, hängt häufig von den Präferenzen bzw. den technischen Standards des Betreibers ab. Wird – wie im Fall von XCAP – die Community-Software auf Basis von JSPs erstellt, wird für eine vollständige Backendintegration ein CMS notwendig, das seinerseits auf JSP basiert.

Variante 1: Echte Backend-Integration (z.B. beide Systeme in JSP oder PHP)

Diese Variante zeichnet sich durch potenziell hohe Synergiemöglichkeiten aus. Andererseits führt diese maximale Integration zu wechselseitigen Abhängigkeiten.

Dazu Peter Bjorkman, Chefentwickler von Josh: „You can integrate XCAP in the customer’s java code. The result is a very tightly integrated solution but creates dependencies between the products that are not desired.“

Aus Sicht von CMS-Herstellern wird diese Variante sicherlich zu favorisieren sein, wenn sie die Entwicklung eines eigenen Community-Moduls planen, das vollständig in das CMS integriert ist. Insbesondere die gemeinsame Verwendung von Klassen-Bibliotheken und die exakte Definition von Schnittstellen versprechen Vorteile bei Kosten und Versionspflege. Auch die Performance wird dadurch in vielen Fällen optimiert werden können, weil die Daten ohne Schleifen innerhalb des Systems ausgetauscht werden können.

Umgekehrt führt dieser systeminterne Vorteil für CMS-Hersteller meist zur nahezu ausschließlichen bzw. isolierten Anwendbarkeit des Community-Moduls Systems innerhalb des eigenen CMS.

Genau das war der Grund, warum sich Josh dazu entschlossen hat, XCAP als neutrales System zu entwickeln, das mit CMS aller Art co-existieren kann und folglich mit einer Vielzahl vertikaler CMS kombierbar bleibt, aber auch vollständig in ein anderes System integrierbar ist – vorausgesetzt es basiert auf JSPs.

Dazu Andreas Stroeberg, CEO: „In earlier days of the web, the trend has been to create systems that are closed, proprietary and specialized. Integrating systems has been cumbersome and time-consuming. When developing XCAP, one of the main goals has been to create a platform that easily can coexist with other software, where information can be submitted and distributed in any fashion. Customers have very different platforms, demands and ambitions which must guide the type of solution they receive.“

Viele Community-Systeme folgen dieser offenen Strategie aus ähnlichen Gründen wie Josh. Andererseits resultiert daraus die Notwendigkeit der Schaffung anderweitiger technischer Schnittstellen. Ein zusätzlicher Grund für diesbezügliche Schnittstellen ist die häufig begrenzt flexible IT-Standardisierung innerhalb von Konzernen und größeren wie mittleren Unternehmen.

Variante 2: HTML-Integration

Als Basis einer frontendseitigen Datenintegration bietet sich zunächst die Möglichkeit, jeweils fertige HTML-Schnipsel in das Frontend des jeweils anderen Systems zu integrieren. Auf die Frage, welches Backend das jeweils andere System nutzt, kommt es hier nicht an. JSPs und ASPs und/oder PHP lassen sich beliebig kombinieren.

Wie nahezu alle (halb-)statischen Lösungen bietet diese Variante eine hohe Performance sowie hohe Stabilität. Andererseits korreliert sie mit dem klassischen Nachteil fehlender Flexibilität.

Variante 3: XML als Austauschformat

Die gewiss flexibelste Variante ist der Datenaustausch via XML. Dabei reichen die Möglichkeiten des Austauschs von Direktzugriff auf die jeweilige Datenbank des anderen Systems über einen Zugriff der Systeme untereinander bis hin zur Austauschwährung von XML innerhalb eines komplett integrierten Systems (vgl. Variante 1).

Dazu nochmals Peter Bjorkman, Josh: CMS, XCAP and XML are the key to create a flexible, open, easily maintained and stable solution. The information can be published in any channel (web, print, mobile, TV) and gives the content provider complete control over design. Publishing multiple communities (for example a sports community and a music community) is simple, the same code base and servers can be used by simply changing the design – the information is the same. RSS/Atom/OPML feeds can be used allow the end users to subscribe to content. The API could be opened up to the public using Web Services so that external developers could use the functions which would give greater reach and better functionality (see Google).

Gerade die für Web 2.0 so bedeutenden Abonnement-Dienste wie RSS und Mobile-Schnittstellen der Community-Software lassen diese Lösung als die beste erscheinen.

Ob und welche Variante im konkreten Fall einschlägig ist, hängt aber nicht nur davon ab, was die (vermeintlich) beste Lösung ist, sondern welches System sich bei einer Kosten/Nutzen-Betrachtung sowie den Zeit- und Sicherheitsvorgaben am besten realisieren lässt.

Insofern verwundet es nicht, wenn bei expressen.se eine „sowohl/als auch Lösung“ gefunden wurde:

– Die Integration der Kommentierung erfolgte im Wege von Variante 1 (vollständige Integration).
– Der Blog wurde gemäß Variante 3 umgesetzt (Austausch via XML).

3. Weitere technische Features

a. Ajax

Im Zusammenhang mit dem Schlagwort „Web 2.0“ darf die Integration von Ajax innerhalb einer Community-Lösung nicht fehlen. Innerhalb von expressen.se wurde die Integration von Ajax zunächst bei der User-Registrierung vorgenommen.

Der rot markierte Bereich nutzt XCAP die Vorteile von Ajax, die vor allem darin liegen, dass die Seite als solche bei der Registeriung nicht erneut geladen werden muss. Auch in Zukunft werden weitere Ajax-Elemente integriert werden.

b. Datenbankanbindung und Cache-Optimierung

Es erstaunt nicht, dass expressen.se bei den Community-Elementen auf eine MySQL-Datenbank zurück gegriffen hat.

Selbst Websites mit Millionen Datensätzen vertrauen der Stabilität von MySQL. Von Kosten ganz zu schweigen.

Peter Peter Bjorkman, Josh: „XCAP is currently using MySQL but can be configured use any database. The reason MySQL is used is that it is cheap, stable, fast, simple and in many ways, a web standard. Communities (as opposed to traditional CMS) are very database intensive – every page request could result in many reads and probably a few writes to the database. To prevent this we rely heavily on intelligent caching schemes.“

Der letzte Punkt war auch aus Sicht von expressen.se entscheidend:

Per Thelin, CTO von expressen.se : „One big advantage that we have by using Polopoly as our CMS is that no pages are completly cached only fragments/objects of the page are cached. Other systems on the market usually caches the whole page and makes it static for all users (they do this with variuos technics like rewersed proxys). So we are able to have user generated and content unique to every user on all pages. But as I said before this is also only made possible by XCAP:s own caches to handle the load.“

Die Tatsache, dass intelligente Caching-Systeme von hoher Relevanz sind, liegt auf der Hand. Gleichsam verwundert es nicht, wenn die Firma Josh genau aus diesem Grund nichts über die Details des Caching-Prozesses verrät.

Zum Abschluss des technischen Teils hat Andreas Stroeberg, CEO von Josh aber zumindest die Zustimmung zur Veröffentlichung dieser Gesamtübersicht gegeben.

III. Ausblick auf Teil 3

Der dritte Teil des Beitrags wird sich vor allem mit Workflowfragen beschäftigen. Dabei wird es neben der Rolle des Moderators vor allem auch um den Rulemanager und die Contentkontrolle der von Usern veröffentlichten Beiträge gehen. Hier gelangen Sie zum dritten Teil.

Falls Sie den ersten Teil noch nicht gelesen haben können Sie diesen, hier nachlesen.

Zurück zu Contentmanager.de