Hanuman

Beschreiben Sie die angestrebten technischen Ziele Ihres Projektes

Zunächst halten wir eine Begriffsdefinition für notwendig. Wir vermeiden im Zusammenhang mit Hanuman bewusst den Begriff Content Management System, da wir das Projekt nicht in diesem engen Zusammenhang sehen. Hanuman soll kein Expertensystem sein, sondern eine selbsterklärende Software, die jeder bedienen kann. Der Begriff Web-Publishing-System scheint uns eher angemessen und vereint die verschiedenen Begrifflichkeiten, unter denen im Web publiziert wird: “klassische” Websites, Blogging, Micro-Blogging, Livestreaming und kollaboratives Erstellen von Dokumenten/Seiten im Web. Hanuman unterscheidet nicht zwischen diesen Publikationsformen, sondern stellt flexible Werkzeuge zur Verfügung, die dem jeweiligen Einsatzweck angepasst werden können. Web Publishing ist nicht nur das Bereitstellen von Inhalten, sondern bietet auch die Tools, um über die publizierten Inhalte zu kommunizieren.

Projektziel ist also die Umsetzung eines einfach zu handhabenden Web-Publishing-Systems mit innovativem Backend und Interface, das aktuelle Web- und Accessibility-Standards erfüllt.

Features

• Innovatives accessibility- und webstandardskonformes Interface (d.h. nicht nur publizierte Inhalte, sondern das System selbst hält sich an diese Richtlinien)
• basierend auf PHP, Datenbankunabhängig
• Mehrsprachigkeit
• ACL basierte granulare Zugriffsrechte, Userverwaltung
• klar vom Design getrennte objektbasierte, verschachtelbare Content-Typen … diese ermöglichen die automatisierte Erstellung von maschinenlesbaren Formaten (Semantic Web, Microformats, RSS, JSON etc.)
• Dezentralität und Synchronisierbarkeit (API), Offline-Modus
• Import/Export Funktionen
• Full Text Search & Semantic Search
• Versionierung
• Templates & Themes
• Zugriffsstatistiken
• Caching
• Berücksichtigung neuester Entwicklungen wie z.B. “realtime RSS”
• Trackback, Ping-Services
• Unterstützt “Cool URIs for the Semantic Web” (http://www.w3.org/TR/cooluris/) / Permalinks für Microcontent

Worin liegt die Innovation gegenüber anderen Publishing Systemen?

Die aufgeführten Features sind freilich zu einem Grossteil Standardfunktionen, die man von einem Web Publishing System erwarten kann. Die meisten dieser Funktionen werden auch bereits von einem der zugrunde liegenden Projekte (PhpWiki, dazu später mehr) unterstützt. Das ermöglicht uns, dass wir uns in der Umsetzung auf die wirklich innovativen Features konzentrieren. Das ist vor allem der Content-Editor und die Art, in der Content-Objekte definiert und bearbeitet werden sowie die Dezentralität des Systems. Natürlich eignet sich Hanuman z.B. auch als Blogging- oder jede andere Art von gängiger Publikationsplattform, wenn Inhaltstypen, die der jeweiligen Art des Publizierens entsprechen, angelegt werden. Wir möchten an weiteren möglichen Einsatzszenarien die Vielseitigkeit des Systems aufzeigen. Wichtig ist anzuführen, dass Hanuman die erklärten Funktionalitäten im Kern unterstützt, sodass weder für die Einrichtung und schon gar nicht für die Benutzung dieser Systeme Programmierkenntnisse notwendig sind. Für individuelle Anpassungen sind HTML/CSS-Kenntnisse klarerweise von Vorteil.

Fallbeispiel 1: Internetauftritt eines Theatervereins

Die Webseite besteht aus einem Bereich mit (1) Neuigkeiten, von der Struktur her ähnlich einem Blog mit Kommentarfunktion. Aktuelle und vergangene Aufführungen von (2) Theaterstücken werden mit Inhaltsbeschreibungen, Mitwirkenden, Terminen und Fotogallerien aufgelistet. Die (3) Vereinsmitglieder werden mit Foto und Kurzbiographie angeführt. Soweit nichts Neues.

Mit Hanuman wird die Seite eines Vereinsmitglieds zu dessen Profilseite, die er/sie selbst aktualisieren kann. Beim Anlegen eines neuen Theaterstücks werden Mitglieder ihren Rollen zugeordnet und automatisch verlinkt, Aufführungstermine werden als Events angelegt. Durch die Verknüpfung solcher Inhaltsobjekte scheint auf der Profilseite eines Mitglieds auf, in welchen Stücken es mitgewirkt hat. Die Terminauflistungen auf der Website werden automatisch mit Mikroformaten angereichert und können beispielsweise im iCal-Format abonniert werden. Aufführungsorte werden georeferenziert und sind als KML verfügbar. Fotos von Aufführungen und Proben werden in Alben Theaterstücken zugeordnet, Mitglieder können in den Fotos “getagged” werden. In Kommentaren zu Theaterstücken können Bewertungen abgegeben werden, die als hReview-Mikroformat publiziert werden.

Die Publikation von diesen maschinenlesbaren Formaten erfolgt automatisiert, d.h. von Benutzern/-innen ist ein Verständnis des technischen Hintergrunds nicht notwendig. Das Zurverfügungstellen dieser Formate hat verschiedene Effekte. Suchmachinen etwa nehmen zunehmend darauf Rücksicht und können Suchergebnisse damit strukturierter darstellen. Auf die Inhalte der Seite kann nicht nur direkt mit dem Browser zugegriffen werden, sondern auch mit anderen Programmen und Web-Applikationen, die diese Formate unterstützen (z.B. Kalender, Geo-Browser).

Das flexible Interface erlaubt das dynamische Auswählen von bestehenden bzw. das Erstellen von neuen Content-Objekten im jeweiligen Kontext des Hauptobjekts. Beim Anlegen eines neuen Theaterstücks werden beispielsweise bestehende Mitglieder zugeordnet und neue Termine erstellt sowie ev. sowohl bereits hochgeladene als auch neue Bilder hinzugefügt. Das alles, ohne je die Seite für das Anlegen des neuen Theaterstücks verlassen zu müssen.

Den Mitgliedern können unterschiedliche Rollen und Befugnisse zugeteilt werden, z.b. dürfen alle Kommentare veröffentlichen, aber nur bestimmte dürfen News-Einträge schreiben oder Theaterstücke anlegen.

Die Definition von solchen Content-Objekten (z.B. ein Theaterstück) muss dabei nicht aufwändig programmiert werden, sondern erfolgt innerhalb des Systems mit einem einfachen Interface. Content-Objektdefinitionen und Templates werden im wikibasierten Backend gespeichert. Das erlaubt eine ungeahnte Flexibilität in der Erstellung und Bearbeitung von komplexen Inhaltsstrukuren. Dadurch entsteht kein statischer Internetauftritt, sondern eine lebendige, stark vernetzte Seite.

Fallbeispiel 2: Dezentrales Microblogging Netzwerk

Unterschiedliche Hanuman Installationen (Instanzen) koennen ueber Server hinweg auf verschiedenen Wegen (RSS, pubsubhubbub, JSON-Proxies) miteinander kommunizieren (Das spielt in erster Linie beim Offline-Support und den Synchronisierungsfähigkeiten eine Rolle, hat aber noch weiteres Potential, wie das folgende Beispiel verdeutlichen soll).

Ein einzelner Publisher (P1) veröffentlicht mit Hanuman Inhalte. Diese koennen andere (P2) wiederum kommentieren und abonnieren (man kopiert dabei nicht einen speziellen RSS-Feed o.ä., sondern einfach die URI des gewünschten Inhalts). Hinweise auf Updates und neue Kommentare auf der Seite von P1 scheinen ab nun automatisch in P2s Hanuman-Instanz auf und P2 kann auf diese wieder reagieren. Egal ob er das in seiner oder P1s Instanz tut, P1 wird ebenfalls ueber Kommentare und Reaktionen seiner Abonnenten informiert. Vergleichbar ist dieser Ansatz mit Projekten wie laconi.ca (http://laconi.ca/) oder eher noch noserub (http://noserub.com/). Es können auch Nicht-Hanuman-Inhalte abonniert werden (z.B. via RSS), eine so enge Verschränkung wie zwischen Hanuman-Instanzen ist dann allerdings nicht möglich. Eine denkbare Erweiterung für eine tiefere Integration wären Plugins für andere Systeme wie z.B. Drupal oder Noserub, dies geht jedoch über den momentanen Projektumfang hinaus. Was nicht ausschliesst, dass solche Module mit dem erfolgreichen Aufbau einer Entwicklercommunity nicht bald entstehen können. Durch die Gliederung von Content-Objekten in Microcontent-Elemente können sich Benutzer/-innen auch direkt auf diese beziehen. So ist es möglich, nicht nur ganze Einträge, Seiten oder Artikel zu kommentieren, sondern auch direkt einzelne Absätze oder Bilder.

Pflichtenheft / Workpackages

Hanuman wird in objektorientiertem PHP programmiert.

WP1: Standard-Web-Publishing-Funktionen

Dieses Workpackage beinhaltet die Anpassung an die Anforderungen von Hanuman von in PhpWiki bereits existierenden Funktionalitäten, die wir zu den Standardfeatures eines zeitgemässen Web Publishing Systems zählen: Datenbankabstraktionslayer, Offline-Support, Synchronisation, Import/Export, Volltextindizierung, Benutzersystem und Zugriffsrechte, Mehrsprachigkeit, Log File Analysis / Zugriffsstatistiken, Caching.

Die Import/Export-Schnittstelle soll die Möglichkeit bieten, einfache Backups zu erstellen, wir schaffen aber auch die Grundlage dafür, dass Inhalte aus und in andere Publishing-Systeme transferiert werden können.

WP2a: Content-Objekt Klasse

In diesem Work-Package wird die Schnittstelle zum Wiki-Backend geschaffen. Die Schnittstelle sorgt dafür, dass abstrakte und konkrete Content-Objekte im Backend als wiki-konforme semantische Relationen und Attribute performant gespeichert, geladen, aktualisiert und gelöscht werden können. Von abstrakten Content-Objekten können konkrete Instanzen erstellt werden, die die tatsächlichen Inhalte enthalten. Weiters werden Inhalte validiert und Zugangsberechtigungen überprüft. Ausgehend von Content-Objekt-spezifischen Definitionen werden Permalinks generiert (z.b. ausgehend vom Titel oder aus einer Kombination von Content-Elementen).

Content-Objekt-Definitionen bestehen aus einzelnen (Micro)Content-Elementen (im Wiki-Backend semantische Relationen) und Metadaten (im Wiki-Backend semantische Attribute). Content-Elemente sind in der Art “Text”, “Richtext”, “Checkbox”, “Datum”, “E-Mail” definiert, können aber auch selbst Content-Objekte sein. Dadurch werden komplexe Inhaltsstrukturen möglich, die trotzdem in Microcontent-Elemente zerlegbar bleiben. Ein Content-Element kann beispielsweise das Content-Objekt “Bild” referenzieren, dieses wiederum besteht selbst aus den Elementen “File” (referenziert die Bilddatei), “Text” (für etwaigen Titel und Beschreibung, die z.B. in Listendarstellungen dargestellt werden oder “inline” in den Attributen “alt” und “long_desc” des img-Tags verwendet werden), “Tags” (für folksonomy-artige Stichwortkategorisierungen) und Metadaten (z.b. die EXIF-Daten des Bildes, Zugriffsrechte).

WP2b: Form Klasse

Die Form Klasse bietet für einzelne Microcontent-Elemente die entsprechende Interface-Funktionalität. Sie ist eng verschränkt mit dem Mootools-basierten Frontend. Prinzipielle Aufgabe ist die dynamische Generierung des User Interfaces ausgehend vom jeweiligen Content-Objekt.

WP3: API

Die API von Hanuman basiert darauf, dass einzelne Microcontent-Element und Content-Objekte via Permalinks / URIs in verschiedenen Formaten aufgerufen werden können. Je nach Format stehen unterschiedliche Funktionalitäten zur Verfügung. Formate haben die selbe Schreibweise wie Dateiendungen (z.B. .html, .json, .rss etc.). Diese Permalinks verweisen jedoch nicht auf tatsächliche Dateien am Server, sondern via das Apache-Modul mod_rewrite auf Content-Objekte im Wiki-Backend, die “Dateiendungen” dienen zum Aufruf der jeweiligen API-Funktionalität.

In der Arbeit mit Hanuman in der Editier-Oberfläche kommt hauptsächlich die RESTful API (in Kombination mit JSON) zum Einsatz. Damit steht via Javascript-Aufrufen die komplette Funktionalität der Content-Objekt Klasse zur Verfügung (z.B. Erstellen und Editieren von Content-Objekten). Weitere Kernfunktionalitäten sind die Möglichkeit zum Aufruf von Content-Elementen in den Formaten Atom/RSS, XML, KML, iCal/ics, vCard/vcf, wenn der Kontext des Elements dies erlaubt, sowie die für das Semantic Web relevanten Interchangeformate.

Die Spezifikation der Hanuman-API erlaubt eine gezielte Erweiterung. Je nach Anwendungsfall sind z.B. verschiedene Display-Formate sinnvoll (z.B. Plain-Text, PDF).

In Kombination mit den Synchronisierungfunktionen von PhpWiki ist die API ausschlaggebend für die Dezentralität des System, sowohl bezogen auf Features die Wartung betreffend (z.b. Backup, Import/Export) als auch anwendungsbezogene Funktionalitäten (Remote-Comments, Decentralized Social Networking). Die in WP1 beschriebene Import/Export-Funktionalität bezieht sich eher auf den Wartungsbereich. Die Hanuman-API dagegen bietet die Grundlage für Import/Export auf Content-Objekt-Ebene (Stichwort realtimeRSS, Lifestreaming).

Bei Projektstart werden wir verschiedene Möglichkeiten für die sichere Authentifizierung via API reevaluieren (wie z.B. Oauth), zum jetzigen Zeitpunkt scheint es uns nicht sinnvoll, uns in diese Richtung festzulegen, da dieses Gebiet eine recht junge Entwicklung darstellt und sich in unseren Augen kein zufriedenstellender offener Standard durchgesetzt hat.

WP4a: Template Klasse

Templates kommen für die Gestaltung von Content-Objekten in Frage und können für verschiedene Kontexte angelegt werden, z.B. für die Darstellung als einzelnes Objekt (die alle Informationen enthält), für die Darstellung in Auflistungen (in der z.B. nur der Objekt-Titel oder ein Bild-Thumbnail zum Einsatz kommt) oder unterschiedlichen Endgeräten. Zudem können sie für die Formatierung von maschinenlesbaren Formaten eingesetzt werden.

Die Template Klasse ist die Schnittstelle zwischen der Smarty Template Engine und der Content-Objekt-Klasse.

WP4b: Frontend / Javascript Framework

Das Mootools-basierte User-Interface nutzt hauptsächlich die RESTful API und ist eng verschränkt mit der Form-Klasse für die Darstellung von Interface-Elementen.

Der Javascript-Code ist analog zur Content-Objekt-Klasse so abstrakt gehalten, dass auf die unterschiedlichsten Content-Objekte eingegangen werden kann.

Das Mootools-Projekt hat eine lebendige Community und wir können auf einige Module (z.b. Batch-Upload von Dateien, WYSIWYG-Editor) zurückgreifen, die über den Kern von MooTools hinausgehen.

WP4c: Frontend / Interface Design

In diesem Work Package geht es unabhängig von der technischen Umsetzung um die Entwicklung des User Interfaces und Bedienkonzeptes, natürlich auch in Bezug auf ein ästhetisches Design, in erster Linie aber in Richtung Usability und Accessibility. Alternative Oberflächen werden für Endgeräte und Schnittstellen abseits der klassischen Desktop/Browser-Umgebung entwickelt.

WP5: Content-Objekt Creator/Editor

Analog zum Content-Editor wird ein visueller Editor zum Anlegen und Editieren der Content-Objekt-Definitionen erstellt. Dieser soll es auch Einsteigern/-innen ermöglichen, von Grund auf mit Hanuman Projekte ohne Programmierkenntnisse zu entwickeln. Mit diesem Editor können massgeschneiderte Inhaltsstrukturen erstellt werden, die über die Standard-Objekte, die Hanuman zur Verfügung stellt, hinausgehen. Grosser Wert wird dabei auf ein “Unified Interface” gelegt, d.h. die Benutzeroberfläche soll sofort ähnlich vertraut sein, wie der Content-Editor oder andere interaktive Elemente im Frontend. Dieses Workpackage nutzt die Funktionalitäten der bisherigen und wird daher erst zu einem späteren Zeitpunkt im Projektverlauf entwickelt.

WP6: Dokumentation

Neben Inline-Dokumentation im Code und laufende Protokollierung im Versionierungssystem (vorr. Subversion) verwenden wir phpDocumentor (http://www.phpdoc.org/) für die prinzipielle Code-Dokumentation. Referenz-Implementierungen, Demos und Tutorials runden die Dokumentation ab. Die Dokumentation erfolgt laufend während des gesamten Projektverlaufs.

WP7: Online-Aktivitäten

Den Projektverlauf (auch Slides/Photos/Videos von Vorträgen) dokuementieren wir in einem Blog, Programm-Code und Dokumentation sollen Online verfügbar sein. Zudem spielt sich ein Grossteil der beschriebenen Marketingaktivitäten online ab.

WP8: Wissenschaftliche Publikationen

Ziel ist es, die Erkentnisse in der Entwicklung von Hanuman zu formalisieren und darauf aufbauend wissenschaftliche Arbeiten zu publizieren. Wir planen im Laufe des Projektjahres zumindest bei einer A-Konferenz wie z.B. HT2011 einzureichen.

WP9: Öffentlichkeitsarbeit / Marketing

Dieses Workpackage überschneidet sich teilweise mit den Online-Aktivitäten. Zudem fallen in diesen Bereich die Erstellung eines Brandings und der erwähnten Marketingmaterialien, sowie die Präsentation des Projektfortschritts auf Barcamps, Konferenzen und ähnlichen Veranstaltungen.

---

Hanuman Project Concept ist lizensiert unter Creative Commons Attribution-Share Alike 3.0 Austria License.