wiki:Podcast-Wiki-Physik/Systemfrage

Die Frage nach dem PodcastWiki-System

Ende August 2014 wurde im Rahmen eines neuen zeitgemäßen Podcast-Wiki-Layouts die Systemfrage, also die Frage nach dem PWP-betreibenden System (derzeit SemanticMediaWiki) gestellt. Dabei geht es vor allem auch darum, wie die PWP-Website für die PWP-Mitarbeiter möglichst einfach bearbeitet werden kann, und irgendwie die Features abdeckt, die wirklich gebraucht werden, statt welcher, die nicht gebraucht werden (wie Diskussionen an Videos). Im Team ist man sich ziemlich einer Meinung: Es soll minimalistisch sein.

Bevor Pro- und Contras aufgelistet werden, hier erst einmal kurz die Entstehungsgeschichte der PWP Next Generation im Jahr 2011.

PWP Next Generation mit MediaWiki

Die PWP Next Generation ist im Rahmen des Relaunches des PWP-Projektes mit neuem Team 2011/12 entstanden. Kurz zuvor wurde der POTT gelauncht, sodass sich die Historie dazu auch im POTT finden lässt. So war PWP vorher als statische HTML-Seiten in ILIAS gepflegt und hatte, wie in #17 moniert, folgende Probleme aufgewiesen:

  • PWP hatte kein Design mit Wiedererkennungswert
  • Flash-Videoplayer nicht mehr zeitgemäß (HTML5-Videoplayer damit's auf Mobilgeräten auch geht war an der Zeit)
  • Es gab keinen abbonierbaren Video-Podcast (RSS)
  • Die Liste ließe sich auch beliebig fortsetzen: Keine HD-Videos, inflexibel, keine brauchbaren langlebigen URLs (sondern kryptische ILIAS-Lernmodul-Adressen) und daher im Internet quasi unsichtbar, usw.

Es war dann klar: Eine eigene Website muss her, mit eigenem individuellen Design für PWP (weil das ILIAS-Design uns damals nach ziemlichem Einheitsbrei erschien), und natürlich einem eigenen System. In #216 hat Sven 2012 noch abgewägt zwischen

  • Was minimalistischem selbstgemachten, zB mit Django (oder PHP)
  • Einem Open-Source-Video-CMS, z.B. MediaCore
  • Dem HRZ-Streamingserver (kenn ich nicht weiter)
  • …oder MediaWiki

Ich hab mich am Ende für MediaWiki entschieden, weil ich damit im studentischen Umfeld (konkret: BioKemika) bereits gute Erfahrungen gemacht habe: Seiten sind ohne technische Vorkenntnisse bearbeitbar und das System ist sehr gut anpassbar. Als ich Intsars Photoshop-Design in HTML umgesetzt habe, war das Skinning auch sehr angenehm machbar. Natürlich haben mir meine MediaWiki-Kenntnisse sehr geholfen, mittels MediaWiki-Templates und dem Plugin Widgets einen HTML5-Videoplayer einzubinden.

Die Eigenschaften der neuen Software auf MediaWiki-Basis sind auch auf Podcast-Wiki-Physik/Next Generation zusammengefasst und sollen hier kurz beschrieben werden:

Semantic MediaWiki

Jeder Wiki-Seite können sehr leicht Attribute zugewiesen werden, die dann aus anderen Seiten abgefragt werden können. Auf diese Weise entstehen Videoauflistungen nach Kategorien, in denen ein Vorschaubild, ein Videotitel und ein Untertitel von jedem passenden Video angezeigt werden. Auf diese Weise entsteht auch der RSS-Feed. Mit der Semantic MediaWiki-Extension (SMW) wurde das Wiki-System quasi um das ergänzt, was eine eigene Lösung wie auf Django-Basis als Zentrum aufweisen könnte: Eine Art Datenbank, für jedes Video eine Anzahl von Feldern die man ausfüllen kann, bloß etwas versteckter. Dass es sich defakto jetzt wirklich um eine Datenbank handelt, sieht man, wenn man auf die tabellarische Auflistung Alle_Videos geht, aber auch für ein einzelnes Video exemplarisch auf der Hilfeseite zu SMW in der PWP, PodcastWiki:Semantic_Mediawiki, dargestellt.

Die Vorteile von SMW gegenüber einer echten Datenbank sind, dass es flexibler ist: Man kann einfach neue Felder hinzufügen (wie wir z.B. mit verschieden großen Vorschaubildern auch gemacht haben), was bei sowas wie Django (also RDMS) während der Produktivphase schwierig ist (Stichwort Schemamigration). SMW verhält sich damit ein bisschen wie NoSQL-Datenbanken, von denen wir seit einem Dreivierteljahr für UniPhi einige zu zähmen versuchen - hier wurde also einiges an Entwicklungsarbeit für ein funktionierende Schema aufgewandt. Ein Beispiel: Zum neuen System sollten auch immer Untertitel (Transkriptionen #168 vor allem zwecks SEO) kommen. Sie sind derzeit technisch noch nicht vorgesehen, lassen sich aber leicht in das Produktivsystem anhand eines Videos einbauen. Dafür muss die Codebasis (MediaWiki) nicht umprogrammiert werden!

SEO, Caching und Hosting

Die derzeitige Hosting-Lösung ist ein Kompromiss: Wir verwenden als Content Delivery Network (CDN) das ITP, also direkt unsere 10TB elearning-Volume. Das ist bequem, weil niemand Gigabyte-große Videouploads machen muss, und gleichzeitig verwirrend, weil man sowohl die Video-Ordnerstruktur als auch die PodcastWiki hat, die dafür ein Frontend ist. Also: Die Videos werden nur per Einbindung (wie bei einem HTML <img src="http://example.com/ganz/woanders">-Tag) reingeladen und sind nicht in der PWP hochgeladen. Hingegen kann man in der PodcastWiki Bilder hochladen. Die Unterstüztung von Bildern in der PWP ist grandios, Thumbnails, Versionierung, Platz für Bildrechte usw. ist alles eingebaut. Man kann automatisch über 22 Millionen Medien aus den Wikimedia Commons einbinden, also jedes Bild aus der Wikipedia.

Mediawiki kümmert sich auch um eine gescheite Seitenauslieferung. Dazu gehört eine Komprimierung der Assets mit dem RessourceLoader oder ein gesundes Caching. MediaWiki wird auch ziemlich Up-to-Date gepflegt und gibt uns einige gute SEO-Features, z.B. dass der Content ganz oben ist, mit Überschriften gut gearbeitet wird, Keywords angegeben werden, hübsche URLs benutzt werden können. Ganz ehrlich: Bei der Google-Suche nach podcast wiki physik der 1. Platz. Bei podcast physik immerhin 6. Platz. Das liegt auch daran, weil sich die Domain genau liest als podcast wiki physik uni frankfurt.

Wiki und Öffentlichkeit

PWP ist technisch eine Wiki, was uns erlaubt, mit einfachem Syntax (kein HTML nötig) Seiten zu schreiben. Zwar wird PWP bislang nur im Youtube-artigen Umfang mit Inhalt befüllt, allerdings eignen sich die Seiten gut für umfangreichen strukturierten Content, wie vielleicht in der PWP-Hilfe als Beispiel dargestellt wird. Wikis erlauben es, jede Bearbeitung rückgängig zu machen und vor allem Einblick zu nehmen in jede jemals gemachte Bearbeitung. Auch ist in einer Wiki transparent, wer was gemacht hat und wie die Seiten unter der Haube strukturiert sind. So kann ich auf der Seite Attribut:Länge nachlesen, dass die Videos ein Attribut Länge aufweisen und sehe sofort alle PWP-Videos auch mit Längenangabe. Das ist eine Seite, die wir nicht beabsichtigt haben zu veröffentlichen, sondern die einfach nebenbei vom System angefertigt wird. Ich sehe das als Feature: Die PWP-Seite ist transparent und lässt sich von Besuchern beliebig lang durchforsten. Hier kann man drüber streiten, ob das Overload ist oder nicht, aber der POTT ist nach genau dem gleichen Prinzip aufgebaut (das Journal lässt sich drei Jahre lang zurückklicken, weist also ausführliche Infos für jeden der 1000 Tage auf. Absoluter Overload, aber auch ein potentiell brauchbares Abfallprodukt eines Wikisystems).

Entwicklungsbedarf neues System

Da derzeit wieder drüber diskutiert wird (#927, #782), ob wir ein neues System installieren oder nicht, versuch ich mich mal gar nicht an einer Pro- und Contraliste, sondern versuche die Features aufzulisten, die das neue System bräuchte, um das alte zu ersetzen.

Zunächst könnte man an ein Minimalsystem denken und alle Komfort-Features, die die SMW bietet, außenvor lassen. Wir bräuchten dann:

  • Eine Datenbank wo Videos mit Eigenschaften aufgelistet werden. Sowas lässt sich mit Django recht leicht machen. Man kriegt freilich nicht so leicht Revisionierung (Wiki-Prinzip), wenn also Daten zerschossen werden, sind sie kaputt.
  • Einen Bereich für statischen Inhalt. Also Seiten wie PodcastWiki:Über_PodcastWiki. Dafür gibts auch ein Django-Plugin.
  • Ein System für Portale/Kategorien. Portale sind Auflistungen von Videos nach Kriterien. Derzeit lässt sich das alles in beliebige Wiki-Seiten schreiben, aber dafür bräuchte man dann ein System, was Videos nach Kategorien auswählt und darstellt. Gerade für die Hauptseite, die ja derzeit zB die neusten Videos aus allen Kategorien darstellt, ist das schwierig.

Das Design wäre dann als Skin/Template per HTML anpassbar. Videos würden nach wie vor beim ITP gehostet. Das System besticht durch seine Einfachheit: Der Django-Admin (Screenshots hier) ist per Default wirklich ausgesprochen simpel. Dafür skaliert das System nicht hinsichtlich neuer Features, z.B. Seiten mit beliebigen Inhalten, mehreren Videos auf einmal. Auch die Datenfelder sind fix und können nicht leicht erweitert werden (s.o.).

Ein System, was alle Features des derzeitigen Systems abdecken würde (aber irgendwie leichter zu bedienen wäre, das sei die Arbeitshypothese), müsste zusätzlich noch anbieten:

  • Revisionierungs-Funktionen, also die "Undo-Capability". Damit das wartbar bleibt, brauchen wir ein abstrakteres Datenbankschema. Und das ist die Kehrseite von Django, komplexere Datenbankschemata lassen sich nicht mehr idiotensicher bearbeiten. Vor diesem Problem stand UniPhi ein halbes Jahr lang.
  • Dynamische Seitenelemente, um Portale und vor allem die Startseite so flexibel wie derzeit zu bearbeiten. Im Text eingebettete Anfragen wie liste die neusten 3 Kurzinterviews auf müssen sich auswerten lassen.
  • Caching, Optimierung: Zwar ist eine Lightweight-Lösung a priori schneller, aber desto mehr Datenbankabfragen je Seitenrendering gemacht werden müssen, je eher lohnt sich eine Investition in eine Caching-Infrastruktur. Und das wird schnell komplex, wenn die Seite aus verschiedenen dynamischen Bauteilen besteht.
  • Medienverwaltung, etwa Bilderupload, Einbindung von Thumbnails.

Am Ende baut man halt ein System nach wie das, was derzeit schon existiert, was dann aber nicht die Features eines wirklichen Wiki-Kerns aufweist. Das MySQL-Datenbankschema von MediaWiki weist dutzende Tabellen auf, dazu kommen nochmal die Semantic Database tables. Bis wir so viel Komplexität nachgebaut haben, geht bei unserer Entwicklungsgeschwindigkeit ein ganzes Jahr drauf. In Anbetracht der Probleme, die wir gerade beim Entwickeln eines neuen Systems mit vielen Features (UniPhi) hatten, bedeutet das zahlreiche Entwicklungsstunden. (Meine persönliche Meinung: Die sind besser darin investiert, die MediaWiki-Funktionen zu verstehen und dokumentieren, ein gutes Design und guten Content zu machen)

Alternative A: Processwire (Steffen, am 2.9.2014)

Ich bin vor kurzem auf http://processwire.com gestoßen und meine am Ende einer langen Suche angekommen zu sein. Ich kenne noch nicht jeden Winkel des Systems, daher sind meine Aussagen sicherlich begrenzt. Aber das was ich bisher kennengelernt habe finde ich sehr, sehr, sehr fein! Sehr!

Processwire kann man schon fast als Framework bezeichnen. Es ermöglicht es dem Programmierer für die Nutzer / Redakteure / Kunden ein einfaches zu bedienendes Backend zu erstellen ohne dabei aber irgend eine Art von Struktur vorgegeben zu bekommen, außer: Die einzige Struktur ist ein "Seitenbaum" oder schlicht eine Hierarchie, deren Knotenpunkte aber als Seiten bezeichnet werden, aber nicht unbedingt als solche behandelt werden müssen.

z.B.:

Homepage
  |--Videos
  |      |-- Aktuelles
  |      |       |-- [...]
  |      |-- Interviews
  |      |       |-- [...]
  |      |-- Vorlesungen
  |      |       |-- [...]
  |      |-- FP-Videos
  |      |       |-- [...]
  |--Artikel / Blog
  |      |-- Eintrag 1
  |      |-- Eintrag 2
  |      |-- [...]
  |--PraktikaPortal
  |      |--AP1-Beschreibungen
  |      |       |-- [...]
  |      |--FP-Material
  |      |       |-- [...]
  |--ÜberUns                      // statische Seite
  |--Wasauchimmer                  // statische Seite
  |--Tags*                          // für kategoriesierung, lässt sich aus suche und (vorder)seite ausblenden
  |      |-- sonne*
  |      |-- mond*
  |      |-- sterne*
  |      |-- [...]

So könnte z.B. die Podcast-Wiki Struktur aussehen.

Jeder Seite / jedem Knotenpunkt sind eigene Seitenvorlagen zuweisbar. Man kann das auch beschränken, sodass Redakteure nur bestimmte Vorlagen für bestimmte Kategorien benutzen können. Wie Videoseite nur für Videos, Artikelseiten nur für Artikel, etc … Dann: Um Seiten zu kategoriesieren kann man einen Knoten bauen ala "Tags" bzw. "Kategorien". Deren Kinder'seiten' dienen dann als Sammelbox aller Kategorien und Tags, die man so benutzen möchte. Bearbeitet man dann eine Seite, kann man dieser ein Feld zuweisen aus der man die Tags oder Kategorien dann auswählen kann. Stichwort: Felder. yay!

Im Backend lassen sich die einzelnen templates der Seiten anlegen und mit Feldern versehen. Feldern wie z.B. Textfeld, Textarea, Checkbox, Images, Date, etc … Die Werte der Felder lassen sich dann einfach in der zum template korrespondeirenden .php-Datei per $page→title oder $page→images→SomeFilterMethod→First(4) auslesen.

Gleichzeitig sind die Felder für Redakteure sehr schön bedienbar. Bilder lassen sich per drag&drop ins Textfeld laden. Es gibt ein Modul für Thumbnails, die man per GUI aus einem Bild schneiden kann … etc etc … Es lässt sich sogar das Layout, wie sich die Felder im Backend dem Redakteur präsentieren, einstellen.

Hier: http://processwire.com/demo/ gibt es eine Demo-Seite. http://processwire.com/videos/ hier kann man sich ein paar Videos anschauen.

Zu angesprochenen Anforderungen:

Alternative B: Ghost (Thomas, am 2.9.2014)

Ghost ist quasi das komplette Gegenteil von ProcessWire. Ghost ist für Benutzer und nicht für Entwickler. Das heißt, es wird ein System vorgegeben und man kann wenig anpassen. Dafür sieht das Interface einfach traumhaft aus und jeder Depp kann es bedienen.

Ghost basiert nicht auf PHP sondern auf Node.js. Es ist leichtgewichtig, effizient und schnell. Inhalte werden in Markdown (bzw in einer leicht erweiterten Version von Markdown) geschrieben. (Keine ätzenden WYSIWYG-Editoren.) Beim Erstellen von Inhalten gibt es einen exzellenten live preview, der auch auf Tablets funktioniert. Templates werden in handlebar geschrieben.

Großer Nachteil ist, dass die Software erst ein Jahr alt ist. Viele geplante Features sind einfach noch nicht implementiert. Auf der Liste stehen zum Beispiel Ghost apps (etwas dollere Plug-ins) und Version Control für die Inhalte.

Den momentanen Stand der Podcast-Wiki-Seite könnte man aber, soweit ich das sehe, schon jetzt in Ghost umsetzen. Das Templating-System ist ziemlich flexibel. Für so etwas wie "Ähnliche Videos" hat sogar schon jemand was gebastelt: link.

Ghost besitzt weder dynamische Seitenelemente (dafür aber eine umfangreiche JSON API, so dass man solche Elemente in Javascript schreiben kann) noch besondere Medienverwaltungswerkzeuge.

Für das, was Podcast-Wiki im Moment macht, ist Ghost allerdings meiner Meinung nach ausreichend und wäre intuitiver als MediaWiki.

Alternative C: What You See is What You Get (WYSIWYG) (Sven, am 07.10.2014)

Bei Wikipedia gibt es mittlerweile den Visual Editor. Hier kann man zB den Artikel "Physics" in der SimpleWP verändern (Simple weil einfache englische Sprache, die erstbeste Installation wo ich den Visual Editor gerade in Aktion fand). Gerade auch das Bearbeiten von Vorlagen (Videoeinbindung) wird damit sehr einfach.

Last modified 3 years ago Last modified on Oct 7, 2014 3:37:24 PM