DadA goes DadAWeb 3.0 - Projektrelaunch, der Dritte!

Jetzt aber ... im dritten Anlauf der große Durchbruch!?

Vorbemerkung

Vielleicht ist es wirklich utopisch, was wir uns mit dem Projekt des DadAWeb 3.0 vorgenommen haben. Aber Fortschritt ist die Verwirklichung von Utopien, meint Oscar Wilde.

Doch von echten Fortschritten kann im Projekt "DadAWeb 3.0" leider nicht die Rede sein. Eher bewegt sich das Projekt im Kreis. Die traurige Realität ist, dass sieben Jahre nach der Initialisierung des Projektes und vier Jahre nach dem zweiten Projektrelaunch das Projekt DadA 3.0 immer noch nicht wie geplant realisiert werden konnte. Immer noch gibt es keine webbasierte Onlinedatenbank, mit der sich die Inhalte der DadA-Presse- und Literaturdokumentation nicht nur nutzen, sondern auch von den Usern selber pflegen ließen. Immer noch nicht gibt es eine integrierte Web-Plattform für die redaktionellen, bibliothekarischen und Datenbankinhalte des DadAWeb.

Mangels echter Fortschritte ist es Zeit für eine kritische Bestandsaufnahme der bisherigen Projektentwicklung und für die Suche nach alternativen Realisierungsmöglichkeiten. Dies geschieht in dem hiermit beginnenden dritten Projektrelaunch, von dem wir hoffen, dass er für das Projekt DadA 3.0 endlich den Durchbruch bringt. Wir sind immer noch hoffnungsfroh, denn wie sagt das Sprichwort? Es sagt: "Aller guten Dinge sind drei"!

Jochen Schmück, im Oktober 2017

Bilanz der bisherigen Entwicklung (Fazit des 2. Projekt-Relaunches)

hier die bisherigen Versuche zur Realisierung des Systems - insbesondere zu dem Versuch einer Lösung auf Basis des Systems Joomla+Fabrik-Extension - und die Gründe ihres Scheiterns kurz dokumentieren.

Kriterienkatalog für eine Lösung zur Realisierung des DadAWeb 3.0 (Vorschlag zur Diskussion)

Die angestrebte Lösung soll

1. analog zu den (offline gepflegten) alten DadA-Dokumentationen den Aufbau und die Verwaltung einer in frei definierbaren Datenfeldern differenzierten Onlinedatenbank ermöglichen. Für DadA-L entsprechen diese Datenfelder z.B. den RAK (Regeln der der Alphabetischen Katalogisierung). Angestrebt ist ein System von differenziert strukturierten und untereinander vernetzten Contents (s. Contentplanung für DadA 3.0). Durch einen Mausklick auf den Autorennamen „Bakunin, Michail“ soll beispielsweise zum einen die Biografie-Seite zu Bakunin als Suchergebnis angezeigt werden, aber es sollen auch gleichzeitig alle Schriften von oder über Bakunin im Suchergebnis aufgelistet werden.
2. zeitnah erfolgen und dies zu einem vertretbaren Arbeits- und finanziellen Aufwand. An dem Mediawiki-System haben Markus und Jochen monatelang herumexperimentiert, ohne dass wir dadurch irgendwie der Realisierung des DadAWeb 3.0 wesentlich näher gekommen wären. Auch die im 2. Projekt-Relaunch unternommenen Anstrengungen zur Realisierung des Projektes auf Basis unterschiedlicher Systeme, die sich zuletzt auf die Lösung "Joonmla+Fabrik-Extension" focussiert haben, hat bislang zu keinem echten Durchbruch in der Realisierung von DadA 3.0 geführt. Die nun im 3. Relauunch angestrebte Lösung sollte innerhalb von 6 Monaten eine funktionsfähige Demo-Site und innerhalb von 12 Monaten den Launch der Live-Site ermöglichen.
3. zukunftssicher sein. Also keine selbst programmierten oder exotischen Spezial-Systeme (wie z.B. das nur in Deutschland im Unibereich genutzte Literaturverwaltungsystem litw3), die in zehn Jahren evtl. nicht mehr existieren, sondern stabile und internationale bewährte Content-Management-Systeme wie Mediawiki, Joomla! oder Wordpress (Drupal und TYPO3 wurden ausgeklammert, weil beide Systeme als nicht besonders anwenderfreundlich gelten, s. die Beiträge und Vergleichstest in Hintergrundwissen).
4. möglichst nur mit den eigenen Kernfeatures und -funktionen der für die Lösung verwendeten Software betrieben werden können. Externe Erweiterungen (wie z.B. die Fabrik-Extension für Joomla) bedeuten immer erhöhte Sicherheitsrisiken und sie werden auch nicht selten von einem auf den anderen Tag eingestellt. Bei den Features und Funktionen des Kernprogramms kann man davon ausgehen, dass sie auch künftig existieren und auch weiter optimiert werden.
5. sowohl für den aktiven als auch den passiven User so anwenderfreundlich wie nur möglich sein. Mediawiki z.B. ist für die meisten Nutzer eindeutig zu „sperrig“. Wordpress und Joomla dagegen punkten in Sachen Benutzerfreundlichkeit.

Die fünf Hauptkriterien bei der Auswahl des geeigneten Systems sind:

1. frei definierbare und vernetzbare Datenbank-/Content-Strukturen
2. Gute Usability/Anwenderfreundlichkeit
3. Sichere Zukunftsperspektiven
4. Datensicherheit und Datenschutz
5. System-Leistung/-Performance

Contentplanung: Die vernetzten Datenbankinhalte des DadAWeb 3.0

Das DadAWeb-Portal beinhaltet redaktionelle, bibliothekarische und Datenbankinhalte. Im Datenbankbereich finden sich folgende DadA-Dokumentationen (die grün markierten sind die bereits existierenden Dokumentationen):

1. DadA-A, Archivalien (NEU): Erfassung von Nachlässen und musealen Exponaten wie z.B. Briefwechsel, Tagebücher, digitale Dokumente, Fotos, Filme, Audioaufnahmen, Plakate, Aufkleber usw. usf. Siehe als Beispiel die Datenbank der Archialien des IISG, Amsterdam.
2. DadA-B, Biografien, Autoren, Personen (NEU): Biografische Infos (siehe als Grobmuster die aLibro-Autorenseiten, aber in der DadA natürlich strukturierter als bei aLibro.
3. DadA-E, Fachaufsätze (essays): siehe DadA-Literaturdokumentation, DadA-Sekundärliteratur (siehe als Muster die Dokumentation von Fachaufsätzen/Sammelbeiträgen in GESIS/Sowiport). Das „E“ in DadA-E leitet sich ab vom engl. Begriff „Essay“ = Aufsatz.
4. DadA-F, Forschungs- und Publikationsvorhaben (NEU): Siehe die Rubrik "Forschungsprojekte" im gegenwärtigen DadAWeb.
5. DadA-L - Literatur in Büchern (Monografien): siehe DadA-Literaturdokumentation, DadA-Sekundärliteratur & aLibro-Titelsystematik (zu den geplanten Features der neuen DadA-L siehe die Demo des neuen DadA-L unter dem DadAWeb 3.0)
6. DadA-O, Organisationen (NEU): Infos zu großen Organisationen wie z.B. die FAU, aber auch zu kleinere informellen Vereinigungen, in denen sich Personen (1) vereinigt haben oder die als Institution bei der Herausgabe von Publikationen in Erscheinungen treten
7. DadA-P: Periodika (Zeitschriften, Schriftenreihen), siehe DadA-Pressedokumentation
8. DadA-S: Standorte, Archive und Bibliotheken (NEU): Diese können dann über die DadA-L und DadA-P ihre Bestände dokumentieren und zur Ausleihe anbieten.
9. DadA-T, Termine (Veranstaltungen) (NEU): (erst einmal) mit dem Schwerpunkt auf Bildungs- und Kulturveranstaltungen.
10. DadA-V: Verlage (NEU): Siehe als Beispiel die Verlagsseiten im DadA-Portal oder auch die aLibro-Verlagsübersicht. Hier bündeln sich wiederum die von diesen Verlagen veröffentlichten Publikationen.

Anforderungen an das Frontend (die Anwenderoberfläche des Programms):

Nicht registrierte User

1. Kommentarfunktion zu den bestehenden Titeln (Einträgen): Der nicht registrierte User soll eine einfache und bequem gestaltete Möglichkeit haben, Kommentare zu den bestehenden Dokumenten einzustellen, z.B. für Titel-Korrekturen.
2. Dokumenten-Erfassungsmöglichkeit: Gerade bei der DadA-L sollte auch der nicht registrierte User die Möglichkeit haben, durch ein einfach gestaltetes Formular neue Titel für die DadA zu erfassen.
   WICHTIG: Gut wäre hier ein zusätzliches Tools wie Zotero, mit dem dann die bibliografischen Daten durch Eingabe der ISBN-Nr. online abgefragt und per Mausklick in die DadA-L importiert werden könnten. [Hier können wir vielleicht auf den Erfahrungen mit der von Markus programmierten Mediawiki-Extension SMWBibHelper aufbauen]. Es gibt bereits eine fertige OPAC-Extension - oBiblioOPAC for Joomla! -, die sich vielleicht dafür nutzen ließe.
3. Bewertungsfunktion: Dies NUR für DadA-L, um dem User die Möglichkeit zu geben, Titel zu bewerten, was Nutzern die Suche nach Literatur erleichtert, die von anderen Usern als gut bewerte wurde.

Registrierte User (Autoren; Redakteure)

1. Korrekturmöglichkeit: Registrierte und als zuverlässig eingeschätzte Autoren sollten die Möglichkeit haben, Korrekturen in bestehenden DadA-Dokumenten vorzunehmen (allerdings werden diese Korrekturen vermutlich nicht wie in einem Wiki dokumentiert, aber vermutlich lässt sich eine Benachrichigtungsfunktion per E-Mail integrieren, die über eine durchgeführte Veränderung des Dokumentes informiert).

Nutzungsrechte

Bei allen hier diskutierten Systemen können die Rechte der User differenziert gestaltet werden. In Anlehnung an die unter Joomla und Wordpress genutzte Rechteverwaltung sollten für DadAWeb 3.0 in etwa die folgende vier großen Rechtegruppen bestehen:

1. Nicht registrierte User: Können die Kommentar- und Bewertungsfunktion. Zudem können sie neue Einträge (in allen DadA-Dokumentationen?) über eine anwenderfreundliche Erfassungsmaske einreichen, die allerdings von einem Redakteur freigeschaltet werden müssen.
2. Registrierte User (Autor): Haben alle Rechte der passiven User, Zusätzlich können sie aber ihre eigenen eingestellten Titel verändern und auch in den dafür freigegebenen anderen redaktionellen Seiten des DadAWeb aktiv werden.
3. Registrierte User (Redakteur): Betreuen bestimmte Themenbereiche und schalten Neutitel frei. Setzen die Korrekturhinweise zu bestehenden Titeln um, die über Üser-Kommentare kommen.
4. Admin/Sysop: Entwicklung, Projektmanagement, Technik & User-Support

Anforderungen an die Datenbanktechnik

Das neue System sollte über standardisierte Daten-Import- und Exportfunktionen (am besten im CVS-Format) verfügen, damit zum einen die alten Offline-Datenbanken der DadA problemlos ins neue Online-System importiert und andererseits künftig auch die Datenbank/en des neuen Systems per Export auch wieder in andere gängige Datenbanksysteme überführt werden können.

Finanzierung

Um im 3. Relaunch nun endlich den Durchbruch zur Realisierung des Projektes DadAWeb 3.0 zu erzielen, sollten wir versuchen, schwierige Programmieraufgaben, die die Projektentwicklung ausbremsen, nach außen zu vergeben und durch Spezialisten erledigen zu lassen. Das kostet natürlich Geld, das dem Projekt mangels Einnahmen nicht zur Verfügung steht. Folgende Finanzierungsmodelle könnten für die Finanzierung des Projektes genutzt werden:

1. Projektförderung: z.B. durch die Rosa-Luxemburg-Stiftung
2. Social Crowd-Funding: z.B. durch Crowd-Funding-Portale wie StartSomeGood

Vier Modelle zur Realisierung von DadA Online / DadAWeb 3.0

Eine Einschätzung von Jochen Schmück, die als Beitrag zur Diskussion über die weiteren Entwicklungsöglichkeiten des DadA-Projektes gedacht ist.

Quick and Dirty

Import der bislang offline gepflegten DadA-Dokumentationen (DadA-P und DadA-L) in ein pflegeleichtes Online-CMS (wie Joomla! oder WordpPresss) bzw. Wiki (wie Mediawiki). Das wäre quasi eine Fortsetzung der bislang bestehenden statischen HTML-Version des Ur-DadAWeb, nur eben im Rahmen eines CMS/Wikis und mit dem Unterschied, das dann (z.B. beim Wiki auf der Diskussions-Seite) User direkt ihr Feedback (Korrektur- und Ergänzungsvorschläge) zu den Dokumenten geben könnten. Recherchen in den Inhalten der DadA-Dokumentationen sind bei diesem Modell nur über die integrierte Volltext-Suche des jeweiligen CMS möglich.

Der Vorteil:

Diese Lösung lässt sich innerhalb kürzester Zeit mit geringem Kostenaufwand realisieren. Erforderlich dafür ist nur ein dem jeweiligen CMS entsprechendes Datenimport-Tools wie es z.B. für Mediawiki mit der Extension Data Transfer (für die Formate CVS und XML) vorliegt. Für Joomla und WordPress gib es vergleichbare Tools/Erweiterungen. Da mit dem DadAWeb-Wiki bereits eine solche Online-Plattform existiert, die zugleich auch hochwertige Contents (wie das "Lexikon der Anarchie") beinhaltet, wäre es naheliegend, die DadA-Dokumentationen in das bestehende Wiki des DadAWeb zu importieren.

Der Nachteil:

Als Online-Datenbank lässt sich die DadA dann aber nicht nutzen, weil keine echten Datenbankstrukturen existieren, die z.B. bei feldbezogenen Suchen (z.B. Beispiel: Suche alle Titel mit Erscheinungsort: Berlin) ermöglicht. Auch die Pflege der DadA-Dokumente würe nicht optimal, weil immer die Gefahr besteht, dass bei Korrekturen oder Ergänzungen versehentlich die Datenbank-Feldkennungen der DadA zerstört werden, was den Re-Import in eine echte Datenbankumgebung dann später erschwert.

System, das für eine Lösung dieses Modells in Frage kommt

• Mediawiki (Wiki) - Test zurückgestellt

Quick und Selfish

Import der bestehenden DadA-Dokumentationen in eine reine Online-Datenbank (wie z.B. datenbanken24 oder baseportal). Dort können die DadA-Dokumentationen in einer echten Datenbankumgebung gepflegt und auch für spezielle Datenbank-Recherchen genutzt werden. Eine integrierte Plattform, auf der redaktionelle, bibliothekarische und Datenbank-Inhalte angeboten werden, ist mit dieser Lösung jedoch nicht möglich. Allenfalls ließe sich die damit realisierte DadA-Onlinedatenbank per Frame in ein redaktionelles System (wie z.B. das bestehende Wiki des DadAWeb) einbetten.

Der Vorteil:

Auch diese Lösung lässt sich zeitnah umsetzen. Die Daten befinden sich bei diesem Modell in einer echten Datenbankumgebung, was den Aufwand für Import und Export sehr gering hält. In einer solchen Datenbank können auch datenbankspezifische Recherchen durchgeführt werden.

Der Nachteil:

Eine wirklich einfache und schnelle Lösung dürfte nur mit den kommerziell angebotenen webbasierten Datenbanksystemen (wie z.B. (wie z.B. datenbanken24) möglich sein. Diese verursachen aber hohe laufende Kosten, denn solche Onlinedatenbank-Lösungen kosten zwischen 3,99-50,00 EUR/Monat. Die als OpenSource-Systeme angebotenen Lösungen dürften einen nicht unbedeutenden Entwicklungs- und Wartungsaufwand erforder. Da redaktionelle und bibliothekarische Inhalte auf der einen Seite und die Datenbankinhalte auf der anderen Seite über zwei verschiedene Systeme gepflegt werden, erhöht dies für das DadAWeb-Gesamtprojekt zusätzlich den Arbeitsaufwand und die Kosten der Systemadministration.

Systeme, die für eine Lösung dieses Modells in Frage kommen

Beste kommerzielle Systeme:

• datenbanken24 - kommerzielles System auf Leihgebührbasis, ab 24,00 EUR/Monat
• baseportal - kommerzielles System auf Leihgebührbasis, ab 3,99 EUR/Monat (Das System wurde vor Jahren schon mal getestet. War ganz OK, aber eben nur eine auf den Datenbankbereich isolierte Lösung.)

Beste OpenSource-Systeme:

• Grocery CRUD (Open Source): Reine Onlinedatenbank ohne Schnickschnack
• Limbas (Open Source): relativ ansprechend, scheint kommerziell ausgerichtet, DadA-kompatible Referenz-Site)

und weitere Alternativen:

• Cataface (PHP, MySQL) – Open Source
• AppGini (PHP, MySQL) – kommerz., Lizenz: 79,90 € - wirkt ganz nett
• DaDaBIK (PHP, MySQL) – kommerz.., Lizenz: wirkt primitiv
• VFront (PHP, MySQL) – wirkt sehr primitiv
• Portofino – ansprechende Features, unklar, wie das installiert werden soll.
• Bonita BPM
• Symphytum
• Crudin
• nuBuilder – sehr spartanisch im Frontend

Die mit einer solchen webbasierten Datenbank realisierten DadA-Dokumentationen könnten in das bestehende DadAWeb-Wiki über eine der folgenden Extensions als iFrame-Lösung "integriert" werden:

• IDisplay (stable), Mediawiki, > 1.12
• IFrame Page (beta), Mediawiki > 1.19
• Iframe (Widget) + Widgets-Extension

Easy and Pragmatic

Import der bestehenden DadA-Dokumentationen in ein anwenderfreundliches CMS wie Joomla! oder WordPress. Um in einem solchen eher auf redaktionelle Inhalte ausgerichteten System die DadA-Dokumentationen als Onlinedatenbank nutzen zu können, müssten allerdings in dem CMS zusätzliche Datenbankstrukturen und –funktionen eingebaut werden, wofür spezielle Erweiterungen existieren (so gibt es für Joomla! z.B. die von uns immer noch getestete Erweiterung Fabrik). Am einfachsten dürfte inzwischen die Realisierung dieses Modells mit Hilfe des CMS Joomla! ab Version 3.7 sein, bei dem mit dem seit Mai 2017 existierenden Programm-Feature der Custom Fields die Möglichkeit besteht, Inhalte in echten Datenbankstrukturen zu erfassen und zu pflegen und auch datenbankspezifische Such-, Filter- und Listen-Funktionen zu nutzen.

Der Vorteil:

Die Dokumentationen der DadA würden sich bei diesem Modell zusammen mit den redaktionellen und bibliothekarischen Inhalten des DadAWeb in einem integrierten System befinden. Das erleichtert den systemadministrativen Pflegeaufwand des DadAWeb 3.0 inkl. der DadA-Onlinedatenbank. Eine solche "Lösung aus einem Guss" hat für die User einen deutlich höheren Nutzwert als die ersten beiden Lösungen. Die User können in einem solchen System die DadA-Dokumentationen nicht nur für Recherchen nutzen, sondern sie können sich aktiv an ihrem Aufbau und ihrer Pflege beteiligen. Gleichzeitig können sie auf dieser Plattform auch die redaktionellen Inhalte nutzen und mit gestalten und sich in freien Arbeitsgruppen organisieren und untereinander austauschen.

Der Nachteil:

Im Vergleich zu den ersten beiden Lösungen ist bei diesem Modell der Arbeitsaufwand deutlich höher. Nach unseren bisherigen Erfahrungen macht es kaum Sinn eine solche Lösung über externe Erweiterungen zu dem für das System genutzten Content-Management-System (wie z.B. die Erweiterung "Fabrik" für das CMS Joomla!) zu realisieren. Bei externen Erweiterungen besteht immer die Gefahr, dass sie von der Entwicklung des eigentlichen CMS „abgehängt“ und dann nicht mehr weiterentwickelt werden (wie das im Fall der Fabrik-Extension seit Einführung des Features der Custom Fields im Joomla-Kernprogramm vermutlich der Fall sein wird). Da jedoch der Aufwand für die Entwicklung eines solchen integrierten Systems selbst bei einem anwenderfreundlichen CMS wie Joomla! auch nicht gerade trivial ist, müssen, um eine baldige Realisierung zu erzielen, einige der Arbeiten nach außen an Experten vergeben werden. Das erhöht die Entwicklungskosten eines solchen Systems.

Systeme, die für eine Lösung dieses Modells in Frage kommen

• Joomla!, 3.7 inkl. Custom Fields (CMS) - Test läuft!
• WordPress (CMS/Blogsystem) und die Erweiterung "Advanced Custom Fields, Lizenz der PRO-Version: 25,00 $ - Test zurückgestellt

Clever and Perfect

Import der bestehenden DadA-Dokumentationen in ein CMF (Content Management Framework), das in seinen Contentstrukturen, Features, Funktionen und Webdesign-Templates frei konfigurierbar ist. Mit einem solchen CMF lässt sich quasi ein perfekt auf die eigenen Anforderungen zugeschnittenes CMS entwickeln. Lange Zeit galten TYPO3 und Drupal als CMF-Systeme, die diesen Anforderungen am besten entsprachen. Allerdings haben sich beide Systeme als nicht sehr anwenderfreundlich und ressourcenhungrig erwiesen. Inzwischen gibt es aber mit dem clever gestalteten CMF/CMS ProcessWire eine Lösung, die nicht nur den Anforderungen nach einem in seinen Contentstrukturen, Features, Funktionen und Webdesign-Templates frei konfigurierbaren System entspricht, sondern die zudem auch noch anwenderfreundlich gestaltet ist.

Der Vorteil:

Mit diesem Modell ließe sich ein System entwickeln, das passgenau den spezifischen Anforderungen des DadA-Projektes und seiner Dokumentationen als auch denen der redaktionellen und bibliothekarischen Inhalte entspricht. Da ein solches frei konfigurierbares System kaum noch Ballast an nicht benötigten Programm-Features und -Funktionen besitzt, kommt dies der System-Performance zugute. Dementsprechend bietet ein solches System für die mittel- und langfristige Entwicklungsperspektive es DadAWeb-Projektes deutlich bessere Optionen als alle zuvor genannten Lösungen.

Der Nachteil:

Im Vergleich zu den drei anderen bisher beschriebenen Lösungen erfordert dieses Modell in der Entwicklungsphase vermutlich einen höheren Einarbeitungssaufwand. Um dieses Modell in einem vertretbaren Zeitrahmen zu realisieren, müssen sicher einige Entwicklungsarbeiten an externe Spezialisten (für PHP, SQL und jQuery) vergeben werden, was die Entwicklungskosten für dieses System erhöht.

System, das für eine Lösung dieses Modells in Frage kommt

• ProcessWire 3.X (CMS/CMF) - Test unter Version 3.0.62 läuft!

Diskussionsvorschlag für die Projekt-Roadmap: Was ist wann geplant und wer macht was?

Die Projektplanung unterteilt sich in die folgenden Arbeitsschritte

1. Diskussion und Bestandsaufnahme der bisherigen Projektentwicklung
2. Diskussion und Festlegung des Kriterienkataloges für die neue Lösung
3. Recherche nach geeigneten Systemen, die bisher noch nicht im 2. Projekt-Relaunch berücksichtigt wurden.
4. Test der in die engere Wahl genommenen Systeme .
5. a) Datenimport und –export
6. b) Systemperformance bei hohem Datenbestand (am besten einen Test mit 10.000-25.000 Datensätzen durchführen und dann prüfen auf:
   • Reaktionszeiten bei systeminternen Suchen
   • Speicherzeiten bei der Erfassung neuer Titel
   • Speicherplatzverbrauch
7. c) Anwenderfreundlichkeit des Systems
8. Nach Auswahl des geeigneten Systems Installation und Betrieb einer internen Beta-Version
9. Launch (Start) des Livesystems

Recherche / Hintergrundwissen

Systeme, die für eine Lösung dieses Modells in Frage kommen

Die von Jochen recherchierten und für das Projekt in Frage kommenden Systeme wurden bereits oben den jeweiligen Modellen für eine Lösung zugeordnet.

Hier evtl. weitere Systeme zur Prüfung erfassen.