Wir empfehlen:


DadA goes DadAWeb 3.0 - Projektrelaunch, die Zweite!

Aus DadAWeb
Version vom 24. Oktober 2017, 16:03 Uhr von WikiSysop (Diskussion | Beiträge) (WikiSysop verschob die Seite DadA goes DadAWeb 3.0 - Projektrelaunch nach DadA goes DadAWeb 3.0 - Projektrelaunch, die Zweite!)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Vorbemerkung zum Projektrelaunch

"Fortschritt in eine Richtung kommt nicht ohne Aufhebung der Möglichkeit zum Fortschritt in andere Richtung zustande."
 Paul Feyerabend, Erkenntnis für freie Menschen (1978)


Jetzt aber ... jetzt geht's wirklich los!

Nachdem das Projekt DadAWeb 3.0 vor allen aufgrund der technischen Realisierungsschwierigkeiten in den letzten drei Jahren kaum von der Stelle gekommen ist, haben sich die Projektinitiatoren im September 2013 für einen Relaunch - also einen Neustart - des Projektes entschieden.

Das ursprünglich für die Realisierung des DadAWeb-3.0-Portals ins Auge gefasste Wiki-System Mediawiki mit der Erweiterung (Extension) Semantic Mediawiki wurde von uns über einen längeren Zeitraum hinweg getestet und hat sich für unser Vorhaben als nicht geeignet erwiesen.

Mediawiki ist als ein eher redaktionall ausgerichtetes Wiki-System, wie es auch hier für das Lexikon der Anarchie genutzt wird, durchaus ein sinnvollles System. Die Wikipdia, die ebenfalls auf Mediawiki basiert, verdeutlicht das. Allerdings lässt die Anwenderfreundlichkeit des Systems immer noch zu wünschen übrig, was sich am deutlichsten daran zeigt, dass die meisten Autor_innen des DadAWeb uns ihre Aktualisierungen für ihre Beiträge oder ihren neuen Beiträge per E-Mail schicken, statt sie selber auf den DadAWeb-Seiten einzustellen. Als Grund führen die meisten an, dass ihnen die Wiki-Syntax zu kryptisch ist.

Obwohl ich ein großer Fan von Wiki-Systemen bin, muss ich doch eingestehen, dass das Wiki-System Mediawiki für ein Projekt, wie das DadAWeb 3.0, bei dem unterschiedliche Dokumentationen (Biografien, Literatur, Presse usw.) mit ihren feldstrukturierten Datensätzen vernetzt werden sollen, bislang ungeeignet ist. Das muss nicht so bleiben, denn die Wikipedia-/Mediawiki-Community unternimmt gegenwärtig große Anstrengungen, um das System auch für feldstrukturierte Inhalte zu öffnen, um dadurch Anschluss an die Entwicklung des Semantischen Webs zu bekommen. Doch gegenwärtig sind die von Mediawiki hier angebotenen Lösungsansätze für ein Projekt, wie wir es mit dem DadAWeb 3.0 planen, für die/den Endanwender_in (und auch für die Entwickler) nicht akzeptabel.

Deshalb haben wir uns für einen Relaunch des Projektes und für die Suche nach alternativen Lösungsmöglichkeiten entschieden, die ich im folgenden als Diskussionsgrundlage für alle am DadAWeb 3.0 Beteiligten und Interessierten nun im Folgenden skizzieren und dokumentieren will.

Jochen Schmück, im September 2013


Inhaltsverzeichnis

PROJEKT-KONZEPTION

Anforderungen an den Relaunch des Projektes DadAWeb 3.0

Kriterienkatalog für eine Lösung

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 ich monatelang herumexperimentiert, ohne dass wir dadurch irgendwie der Realisierung des DadAWeb 3.0 wesentlich näher gekommen wären. Die nun angestrebte Jetzt-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 CM-Systeme wie Mediawiki, Joomla! oder Wordpress (Drupal und TYPO3 klammere ich erst einmal mal aus, weil beide Systeme als nicht besonders anwenderfreundlich gelten, s. die Beiträge und Vergleichstest in Hintergrundwissen).
  4. auf existierenden und möglichst in der Praxis bewährten Komponenten und Erweiterungen basieren (so wenig Eigenentwicklung wie nur möglich!). K2 z.B. ist eine seit Jahren und mehreren Joomla-Generationen bewährte CCK-Komponente, hinter der inzwischen eine große Anwender-Community steht. FlexiContent dagegen ist neu und hat bislang nur wenige Anwender, was dann auch die Möglichkeit des Supports durch die Community einschränkt.
  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 Contentstrukturen (CCK)
  2. Usability/Anwenderfreundlichkeit
  3. Zukunftsperspektiven
  4. Datensicherheit
  5. System-Leistung/-Performance


Contentplanung: Die vernetzten Contents der DadA 3.0

Das DadAWeb-Portal beinhaltet im Datenbankbereich der DadA folgende Dokumentationen (die grün markierten sind die bereits existierenden Dokumentationen):

  1. DadA-A, Archivalien (zur Erfassung von Nachlässen und musealen Exponaten wie z.B. Briefwechsel, Fotos, Plakate, Aufkleber usw. usf.): NEU, s. 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, Events, Veranstaltungen (erst einmal) mit dem Schwerpunkt auf Bildungs- und Kulturveranstaltungen.
  4. DadA-F, Forschungs- und Publikationsvorhaben. Siehe die Rubrik "Forschungsprojekte" im gegenwärtigen DadAWeb.
  5. DadA-L - a) 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-L - b) Literatur in Fachaufsätzen: siehe DadA-Literaturdokumentation, DadA-Sekundärliteratur
  7. DadA-O: NEU, Organisationen (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
  8. DadA-P: Periodika (Zeitschriften, Schriftenreihen), siehe DadA-Pressedokumentation
  9. DadA-S: NEU, Standorte (Archive/Bibliotheken): Diese können dann über die DadA-L und DadA-P ihre Bestände dokumentieren und zur Ausleihe anbieten.
  10. DadA-V: NEU, Verlage = s. 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. 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.
  3. 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.

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


Die Projekt-Roadmap: Was ist wann geplant

Die Projektplanung unterteilt sich in die folgenden Arbeitsschritte

  1. Recherche nach geeigneten Systemen - ist abgeschlossen.
  2. Test der in die engere Wahl genommenen Systeme - hat begonnen.
  3. a) Datenimport und –export
  4. 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
  5. c) Anwenderfreundlichkeit des Systems
  6. Nach Auswahl des geeigneten Systems Installation und Betrieb einer internen Beta-Version
  7. Launch (Start) des Livesystems



Recherche / Hintergrundwissen

Anwenderberichte/Anwendungsbeispiele:

System-Vergleiche und -Beschreibungen


Fazit der bisherigen Recherchen

Der Vergleich der bisher theoretisch in die engere Wahl genommenen Systeme Drupal, Joomla! und Wordpress auf Basis der berücksichtigten Anwenderberichte und Systemvergleiche hat ergeben, dass Joomla! zur Zeit die besten Erfolgsaussichten für eine baldige Realisierung des DadAWeb 3.0 verspricht. Das aus diesen Gründen:

  1. Es ist neben Wordpress das anwenderfreundlichste CMS
  2. Im Gegensatz zu dem in den Contentstrukturen eher schlicht gestrickten Wordpress lassen sich mit Joomla komplexe Contentumgebungen schaffen
  3. Die für Joomla entwickelten CCK-Extensions sind ausgereifter und vielfältiger anwendbarer als die für Wordpress entwickelten Lösungen. Insbesondere Fabrik und Seblod machen nach den theoertschen und praktischen Tests einen guten, weil erfolgversprechenden Eindruck. Die Extension ZOO wurde, weil sie kommerzeilel Lösung ist, bislang nicht getestet. Der Vorllständigkeit halber sollte aber auch sie noch mit im Test berücksichtigt werden, denn kommerzielle Premiumsupport-Angebote haben fast alle der getesteten Extensions.



TEST DER SYSTEME

Um möglichst schnell einen Überblick über die als Lösung für das Projekt DadAWeb 3.0 sich anbietenden Systeme zu bekommen, wird der Test methodisch wie folgt durchgeführt:

  1. Recherche und theoretische Analyse der für das Projekt DadAWeb 3.0 für sinnvoll erachteten Systeme. Besonders berücksichtigt werden dabei Anwenderberichte, Systemvergleiche und Demo-Installationen.
  2. In die engere Wahl genommene Systeme werden durch Installation und Einrichtung einer Testanwendung in ihren Features und Funktionen auf ihre Tauglichkeit der das Projekt DadAWeb 3.0 geprüft.
  3. Zeigen sich bei diesem Praxistest Unvereinbarkeiten mit den Anforderungen des Projektes DadAWeb 3.0, so wird (fürs Erste) der Test abgebrochen, um das nächste System zu testen, mit dem man dann hoffentlich weiter kommt. Beispiel: K2 machte auf den ersten Blick einen guten Eindruck. Dann aber stellte sich im praktischen Test heraus, dass K2 keine numerischen Feldformate kennt, was ein gravierender Mangel ist. Deshalb wurde an dieser Stelle der Test abgebrochen, um als nächstes das System Fabrik zu testen, das in seinen Datenbankfeatures deutlich ausgereifter zu sein scheint als K2.
  4. Möglicherweise haben die anderen getesten Systeme noch gravierendere Mängel als die das Systems, bei dem man relativ früh den Test abgebrochen hat. Dann heißt es eben zurück und den Test ahn der Stelle fortzusetzen, an dem man ihn abgebrochen hat, um die Möglichkeiten zur Lösung des Problemes zu prüfen, welches zum Abbruch des Tests geführt hat.


Testverlauf

  • 30.09.2013: Test der Systemlösung Joomla + K2
  • 01.10.2013: Installation und Konfiguration der Extension in einer Joomla-Testinstallation verlief ohne Probleme. Einrichtung feldbasierter K2-Kategorien ist sehr einfach (wenn man sich vorher die Demo mit der Website der "Christian Cowgirls" "reingezogen" hat). Die Datenpräsentation ist im Layout etwas statisch (Kasten mit den zusätzlichen Datenfeldern ist immer unten), das ließe sich aber durch Umprogrammieren der K2-Tenmplates sicher zurechtbiegen. Grundsätzlich macht das K2 - zumindest im Backend - einen gut durchdachten und aufgeräumten Eindruck.
  • 02.10.2013: Vorläufiger Abbruch des Tests, da K2 keine numerischen Datenfelder kennt. Das ist erst einmal ein No-Go. Weiter geht's mit dem intensiven Vergleich von Sobi2 mit Fabrik, beides keine echten CCK-Systeme. Aber beides auch Systeme, mit denen man im Joomla-Framework eine feldstrukturierte eigene Datenbank-Lösung realisieren kann. Falls wir keine alternative Lösung finden, die von Hause aus, den Ansprüchen des DadAWeb besser entgegen kommt, müssen wir nochmal üdarüber nachdenken, wie sich das fehlende numerische Feldformat "umschiffen" ließe (z.B. Nutzung des Datumsfeldes für das Erscheinungsjahr bei DadA-L).
  • 03.10.2013: Test der Systemlösung Joomla + SobiPro 1.1. Installation hat in den Kern-Komponenten und-Plugins klappte nur über das TMP-Verzeichnis. Allerdings vermisst Sobi Tidy HTML auf dem Server. Tidy HTML ist tatsächlich nicht auf dem Server installiert und ist offensichtlich vom Provider her auch nicht in nächster Zeit für die Serverumgebung vorgesehen. Deshalb Abbruch des Tests und Fortsetzung mit der FABRIK-Extension.
  • 03.10.2013: Test der Systemlösung Joomla + Fabrik 3.0.8. Installation klappte erst einmal nicht. Abruch mit Scriptfehler. Fehler 500 sowohl bei Version 3.0.8 als auch Version 3.0.7. Vermutlich war das Installations-Gesamtpaket (Komponente, Module und Plugins) zu groß und damit zu speicherintensiv. Eine andere Ursache könnte evtl. auch sein, dass die Installation statt durch den nativen Joomla-Installkationsassistenten durch den Akeeba-Installationsassistenten durchgeführt wird (mit Setzen von Wiederherstellkungspunkten). Bei Gelegenheit - also bei der nächsten Installation, die mit Fehler 500 abschmiert - prüfen. Es gibt da auf der Seite "Eweiterungen: Installieren" unten einen Link, mit dem man zum Standard-Joomla-Installationsassistenten umschalten kann.
    Hier mit Erfolg durchgeführte Lösung des Installationsproblems: Gesamtpaket (Komponente, Module und Plugins) auspacken und einzeln installieren. Die Komponente und alle (insgesamt 59!) Module und Plugins ließen sich so installieren.
  • 04.10.2013: Doch die Freude über die gelungene Installation von Joomla + Fabrik 3.0.8 sollte nur kurz währen. Aus irgendeinem Grund ließ sich dann das System doch nicht betreiben. Es ließen sich keine Formulare abspeichern. Deshalb noch einmal eine komplette Neuinstallation der Fabrik-Extension auf Basis einer ebenfalls frischen Joomla-Installation. Dort klappte dann auch die Komplett-Installation über das TMP-Verzeichnis (also Komponente, Module und Plugins) in einem Schwung. Danach ließ sich auf dem System auch eine Testanwendung für DadA-L einrichten, die bislang reibungslos funktioniert.
  • 04./05.10.2013: Nachts dann auch der Durchbruch beim Einrichten der Datenbank (Elemente, Formulare und Listen). Siehe "DadAWeb-Menü" links. Nun aber kommen die ersten bibliografischen Probleme:
    • Erscheinungsjahr kann bei Nutzung des Feldformates date vermutlich nur in der Form TT-MM-JJJJ genutzt werden. Das kann man pragmatisch umschiffen, indem Erscheinungsjahr 1968 als 01.01.1968 erfasst wird. Aber dafür müsste man eigentlich eine elegantere Lösung finden. Markus fragen.
    • 2. und 3. Autor: Wenn die in der gleichen Datenbankspalte erfasst werden wie der 1. Autor gibt es Schwierigkeiten mit den bereits durch den 1. Autor belegten Feldnamen (first_name und second_name). Diese können mehrfach verwendet werden, aber nur in anderen Formularen (z.B. "Contact us" und DadA-L), nicht aber in ein und dem selben Formular. Günter + Markus fragen, welche Lösung sie sehen.
  • 07./08.10.2013: Test der Extension Seblod, die neben K2 zu den beliebtesten CCK-Lösungen gehört. Installation funktionierte ohne Probleme. Aber die Extension ist extrem komplex gestaltet. Ich habe fast zwei Tage gebraucht, eine einfache Testdatenbank DadA-L anzulegen. Vom Handling her ließ es sich mit Fabrik einfacher arbeiten. Deshalb anhand von Anwenderberichten nochmals eine Vergleichsprüfung von Fabrik im Vergleich zu Seblod durchführen. Hier die Foren-Diskussion zum Thema beider Awnendergruppen:
  • 10.-13.10.2013: Test der Extension Seblod. Manuelle Erfassung der Titel ist etwas ausgebremst bei Speichervorgtängen (und das bei nur 5 Titeln). Insgesamt ist das System etas "störrisch". Immer wieder muss man den Cache löschen, um die Templates zur Bearbeitung der Titel angezeigt zu bekommen. Auch der Import "flutscht" nicht so gut wie bei der Fabrik-Extension, die mir insgesamt "aufgeräumter" und dadurch leichter zu bedienen und auch flotter ind er Performace vorkommt. Beide Systeme sollten noch mal im Härtetest von ca. 10.000 Titel gegeneinander antreten.


JOOMLA! - dieses CMS wird z.Z. getestet!

Das weltweit wegen seiner Anwenderfreundlichkeit beliebte CMS kann für jeden nur denkbaren Zweck durch Extensions angepasst werden.

Bibliografische Extensions unter Joomla

Bibliotheks-/Büchersammlungen Extensions bei Joomla. Die rein bibliografischen/bibliothekarischen Extensions haben den Nachteil, dass sie nicht für andere Contentbereiche des DadAWeb - also z.B. für den Bereich Biographien - genutzt werden können. Aber sie können Anregung für die Umsetzung der bibliografischen Bereiche im Rahmen einer frei definierbaren CCK-Variante geben.

StorePapers

Wird aber anscheinend noch von niemanden genutzt.

BookLibrary Basic

Meine Präferenz aufgrund theoretischer Recherchen 1. Demo: kommerzielle eBook-Bibliothek (engl.) 2. Demo: Fachbibliothek Pazifik-Klima-Portal (engl.) 3. Demo: öfftl. Kinderbibliothek (span.)

Alexandria Book Library

1. Demo: http://joomla15.neodemo.net/library.html

MediaLibrary Basic

Ist offensaichtlich nur eine für andere Medien (z.B. CD’s, Videos usw.) und um einen Onlineshop erweiterte Fassung von BoobLibrary.


CCK-Extensions für Joomla

Im Bereich der sog. Content Construction Kits (CCCK) hat es bei Joomla in letzter Zeit große Fortschritte gegeben und inzwischen existieren hierzu diverse Extensions, die Joomla um die Möglichkeit zur Einrichtung frei definierter Contentstrukturen erweitern. Für das Projekt DadAWeb 3.0 bietet die CCK-Lösung einen deutlich bessere Perspektive als die rein bibliografische/bibliothekarische Lösung. Siehe hierzu den Vergleichstest dreier Joomla-Extensions.


SEBLOD - diese Extension wurde getestet und zurückgestellt.!

Scheint neben K2 zu den beliebtesten CCK-Systemen unter Joomla zu gehören.

CCK Seblod für Joomla - Grundlagentutorial - 1. (Enführung)


FABRIK - diese Extension wird z.Z. getestet!

Macht von allen getesteten Systemen bislang den besten Eindruck ! Testseite: Joomla + Fabrik 3.0.8

Fabrik is a highly Flexible Joomla! component for building custom web applications. Create beautiful forms to allow your users to enter data, then display the data in lists, map, calendars, timelines, charts and more!

Our innovative engine manages your database relationships for you, and our fine grained access control settings ensure that each user has access to just the right sections of your app.


SOBIPRO - diese Extension wurde getestet und zurückgestellt!

Alternativ zu den genannten CCK-Extensions sollte vielleicht auch das gute alte SOBI getestet werden. Zwar ist SOBI eher eine Directory-Komponente, die aber sehr flexibel für alle möglichen Zwecke konfigurierbar ist und eine große Entwickler- und Anwender-Community hat. Sobi wird als Sobi2 und SbiPro angeboten. Letzteres ist die jüngste komplett neu programmierte Komponente, die von den Features und Funktionen deutlich mehr als das alte Sobi2 bietet, das sicher auch nicht mehr lange gepflegt werden wird.

Referenz-Sites


K2 - diese Extension wurde getestet und zurückgestellt!

"K2" ist eine sog. "Content Construktion Kit"-Lösung für Joomla, ein alternatives Content-Framework, das sich in Joomla einbettet und ein eigenes - stark erweitertes - System zur Verwaltung von frei strukturierten Inhalten schafft. Die Entwickler werben für "K2" mit dem Slogan: "K2 brings the good parts from Drupal and Wordpress into Joomla!". Schön wär's! Denn dann wäre das für das Projekt DadAWeb 3.0 das ideale System.

Falls K2 doch zu "sperrig" sein sollte, was einige Anwender beklagten, sollte versucht werden, beim Hersteller von ZOO die kommerzielle Lösung inkl. Support gesponsert zu bekommen, indem das Projekt DadAWeb 3.0 als Referenzprojekt für den Bereich Sozialwissenschaften entwickelt wird.

Referenz-Sites: Joomla + K2


ZOO

Eine kommerzielle, aber anscheinend sehr benutzerfreundliche CCK-Lösung für Joomla. Könnte u.U. eine anwenderfreundliche Alternative zu der K2-Lösung sein.


FlexiContent

Offensichtlich mächtiges offenes System. Zahlreiche Erweiterungen für Import, Filter usw.


Form2Content

Frei definierbare feldbasierte Artikel

  • Demo Movie Database: http://demo.form2content.com/ (login: demo/demo)
  • Fazit: macht auf den efrsten Blick einen guten Eindruck – TESTEN, wenn K2 nicht überzeugt



Webdesign: OpenSource Joomla-Templates

JA Brisk (responsive)

Besonders schön ist, dass das Template voll mit K2 kompatibel ist!

LightBreeze-Red (non-responsive)


WORDPRESS

Das weltweit populäre Blogsystem, das durch Plugins für verschiedene Anwendungszwecke angepasst werden kann.

Bibliografische Module (Plugins) für Wordpress

OpenBook Book Data

Book Review Modul: book-review-library

Book Review Modul: book-review

CCK-Module für Wordpress

Advanced Custom Fields

  • URL: http://wordpress.org/plugins/advanced-custom-fields/screenshots/
  • Downloads: 1.271.414. Autor hat bislang nur 1 Plugins (nämlich book-review) entwickelt
  • Kommentar: (Zitat:) Advanced Custom Fields is the perfect solution for any wordpress website which needs more flexible data like other Content Management Systems. Wird häufig mit den CCK-Features von Drupal verglichen.

Datenimport nach Wordpress

Zum Procedere siehe am Beispiel des Imports von Joomla-Content: How to Import Joomla Content Using the WP Importer Plugin

Wordpress-Referenzseiten

  • nozegraze.com: Das ist die, die den Artikel „How to Use Custom Fields for …“ geschrieben hat und für 35$ auch ein Review-Plgin anbietet.
  • KinderbuchLotse: www.kibulo.de (wurde inzwischen eingestellt)



MEDIAWIKI / SEMANTIC MEDIAWIKI

Mediawiki mit der Extensions Semantic Mediawiki wurde über einen längeren Zeitraum hinweg getestet und hat sich dabei für das Projekt DadAWeb 3.0 als nicht geeignet erwiesen. Später hier die Erfahrungen und Testresultate erfassen.

Kurzfazit: Mediawiki ist super als ein reines Wiki-System. Aber für ein Projekt, wie das DadAWeb 3.0, bei dem unterschiedliche Dokumentationen (Biografien, Literatur, Presse usw.) mit ihren feldstrukturierten Datensätzen vernetzt werden sollen, ist das Mediawiki bislang noch ungeeignet. Von der Perspektive her (insbesondere was die Entwicklung des Semantic Mediawiki angeht) sieht es nicht schlecht aus, aber gegenwärtig ist das System für den Endanwender (und auch für den Entwickler) nicht zumutbar.

Mediawiki - auf ein Neues . . . ?

Ein User hat uns auf der Diskussionsseite auf das Wikipedia/Wikimedia-Projekt Wikidata und die Mediawiki-Extension Wikibase "hingewiesen, die auf die Integration von erweiterten strukturierten Datenbankstrukturen für mediawikibasierte Wikis abzielen. Ich schaue mir das mal näher an. Wenn diese Lösung Sinn macht, also auch für den Endnutzer, dann ist Mediawiki und die Wiki-Perspektive natürlich wieder "im Rennen". Schön wär's.


DRUPAL

Das Drupal-System läuft hier nur aus Vergleichsgründen am Rande mit. Einerseits bringt Drupal rein theoretisch gute Voraussetzungen für eine Lösung mit, da es von zu Hause aus CCK-fähig ist, sowie durch spezielle für den Bereich Bibliografien entwickelte Plugins, die es in der ausgereiften Form für kein anderes CMS gibt. Andererseits ist Drupal als System offensichtlich sehr anspruchsvoll, was die Systemresourcen angeht, es ist zudem träge in der Performance, und was das eigentliche KO-Kriterium ist: Drupal ist extrem anwenderunfreundlich (auch für den Entwickler), siehe hierzu: When is Drupal not the right choice? und Wordpress nach Drupal und wieder zurück.

Bibliografische Module

Drupal-Referenzseiten

Abgerufen von „http://dadaweb.de/index.php?title=DadA_goes_DadAWeb_3.0_-_Projektrelaunch,_die_Zweite!&oldid=14553“