Schlagwort-Archive: CMS

Drupal als einfaches Learning Management System

Es gibt eine Reihe kostenloser Open-Source-Lösungen für Lernumgebungen zum eLearning im Internet. Die größte und wahrscheinlich auch umfangreichste Lösung ist Moodle. Moodle ist allerdings sehr anspruchsvoll, was den Ressourcenbedarf angeht. Außerdem ist es für kleine Lernumgebungen überdimensioniert. Ein einfaches Redaktionssystem erfüllt oft viele Ansprüche und lässt sich mit geringeren Ressourcen betreiben.
Vieles spricht für WordPress: es ist schnell erlernt, es gibt zahllose Erweiterungen für jeden Zweck und es lässt sich fast überall betreiben.
Screenshot von Drupal
Für interaktive Umgebungen scheint mir aber das freie System Drupal besser geeignet. Es erfordert ein wenig mehr Einarbeitung als WordPress, bringt jedoch einige interessante Funktionen von Haus aus mit. Der Schwerpunkt von Drupal liegt auf dem Community-Building. Man kann zu jedem Inhalt ein Forum hinzufügen, so dass Diskussionen und Kommentare zu jedem Lerninhalt geführt werden können.
Drupal ist ein klassisches Redaktionssystem zum Erstellen von Webseiten, während der Schwerpunkt von WordPress auf Weblogs liegt. In Blogs gibt es normalerweise keine Hierarchie, alle Beiträge liegen auf der gleichen Navigationsebene. Die Beiträge werden nicht im Zusammenhang in einer bestimmten Reihenfolge gezeigt, sondern umgekehrt chronologisch. Das kann man natürlich nach Belieben ändern, Drupal erlaubt das aber von Haus aus. Das Buchmodul von Drupal erleichtert es, Inhalte in eine lineare Reihenfolge zu bringen, so dass der Lernende den Stoff nac einem bstimmten System durcharbeiten kann.
Vieles andere ist integriert oder lässt sich nachrüsten: Benutzerverwaltung mit Rollen, zeitgesteurtes Veröffentlichen, Blogs, die Einbindung von RSS-Feeds, Umfragen/Fragebögen usw.
Auch das Einreichen von Aufgaben und die Rückmeldung durch den Lehrenden sollte sich realisieren lassen.
Der große Vorteil von Drupal gegenüber zum Beispiel Typo3 ist die vergleichsweise einfache Erlernbarkeit und Anpassbarkeit. Außerdem verbraucht es weniger Ressourcen als Moodle und ist stärker auf den Austausch und Benutzer mit unterschiedlichen Rollen ausgelegt als WordPress.Drupal ist ein Framwork für Community-Building, so dass angemeldete Nutzer ihre Diskussionen, Blogs oder eigene Beiträge innerhalb des Systems abgeben können, ohne dass das System erweitert werden muss.

Drupals Stärken werden leider schnell unterschätzt. Ein Problem des Systems ist, dass es im Gegensatz zu WordPress out of the box nicht besonders benutzerfreundlich ist. Ich glaube, sehr viel mehr Leute würden das System einsetzen, wenn es fertig vorfonfigurierte Systeme z.B. für Redakteure gäbe. So ist die Einarbeitungszeit doch ein wenig höher, weil die Funktionen teilweise gut versteckt sind. Zum Beispiel gibt es out of the box keinen graphischen Texteditor. Die Funktion zum Hochladen von Bildern muss in einigen Inhaltstypen wie Büchern erst eingeschaltet werden.
Drupal gilt als Linux der Content Management Systeme, aber das trift auch auf MODx oer Typo3 mit seinem TypoScript zu. Im Vergleich ist Drupal einfacher.

Zugänglichkeit – warum handgemacht heute nicht mehr der beste Weg ist

Ich bastele seit ungefähr sieben Jahren an Webseiten herum. Meine ersten Gehversuche machte ich mit dem WYSIWYG-Editor NVU. Ich habe tatsächlich bekommen, was ich gesehen habe: eine nicht gerade hübsche Website mit grausigem Code. Besonders gut hat mir gefallen, dass mitten im Text sinniges Zeug wie <if support empty paras><endif> auftauchte. Jahre später fand ich zufällig heraus, dass das Word-eigenes Markup ist, welches beim Rüberkopieren in den Quellcode gelangte und natürlich nur im Internet Explorer sichtbar war.
Macromedias Dreamweaver bot schon einige Möglichkeiten mehr. Parallel dazu lernte ich HTML und CSS, so dass ich das geteilte Fenster des Dreamweaver zu schätzen lernte. Oben sah man die Website, unten den Quellcode, so dass man gezielt den Quellcode anpassen und die Änderungen oben sehen konnte. Die beiden Mankos des WYSIWYG kann aber vermutlich kein visueller Editor aufheben: Zum einen die Produktion schlechten Codes und zum anderen die fricklige Unterstützung von CSS, die für die Trennung von Struktur und Layout aber notwendig ist. Die Zeit, die man mit WYSIWYG sparen mag, verbringt man anschließend für die Verbesserung, Reparatur und Säuberung des Codes.
Ich habe also meine nächsten Websites mit Texteditoren gebastelt. Für Blinde sicher die angenehmste Art des Arbeitens. Leider sehr fehleranfällig, wenn man irgendwelche Klammern vergisst, muss man oft ewig nach der Ursache eines Problems suchen. Andererseits kennt man seinen eigenen Code so genau, dass Anpassungen problemlos und schnell möglich sind.
Nun ist aber auch dieser Zug abgefahren. Zum einen kommt heute keine anständige Site ohne PHP und JavaScript aus – was beides echte Programmierkenntnisse erfordert, zum anderen gibt es ganze Content Management Systeme, die wesentlich flexibler sind als die handgestrickte Website.
Heute gibt es mächtige Frameworks für Website-Entwickler, die wichtige Funktionen zusammenstellen, die vielfach getestet und frei verwendbar sind. Und ganz nebenbei sind sie barrierefrei. Ob YAML oder JQUERY, wer solche Frameworks einsetzt, spart viel zeit und Nerven. Da selbstgestrickte Skripte in JavaScript und PHP zudem häufig ein Sicherheitsrisiko darstellen, sollte man auf deren Einsatz verzichten. Es sei denn, man weiß, was man tut. Dass die Skripte dafür sorgen, dass alle Browser abgedekct sind, ist ein netter Haupteffekt.
Das Gleiche gilt für CMS wie Drupal oder WordPress. Sie sind von Haus aus barrierearm und bieten einen weiten Spielraum für Gestaltung und Erweiterung. Ein weiterer unschlagbarer Vorteil besteht darin, dass Inhalte, die einmal in Datenbanken gespeichert wurden sich wesentlich einfacher überführen lassen als unstrukturierte Inhalte. Ich will allerdings nicht verheimlichen, dass die Einarbeitungszeit in ein CMS oder ein Framework recht lang sein kann.
Andererseits bringen viele Open-source-CMS Webstandards und Standards der Barrierefreiheit in die Welt, ohne dass die Website-Bauer dies überhaupt in Betracht gezogen haben. Bis heute sehe ich täglich Websites, die auf korrekte Strukturierung in HTML verzichten. Irgend etwas läuft schief, wenn WordPress oder Yahoo schon WAI-ARIA implementieren, während andere Websites nicht einmal Überschriften und Listen korrekt auszeichnen. Doch auch des Blinden Liebling erfreut sich noch immer großer Beliebtheit: Tabellenlayouts mit Spacer-GIFs.
Für Lerneffekte ist es sicher sinnvoll, sich ein eigenes CMS mit Suchfunktionen und allem Luxus selbst zusammenzubauen. Auch wer seine Seite statisch halten möchte – das könnte es noch geben – braucht weder Dynamik noch CMS. Dem ganzen Rest möchte ich die Verwendung von Frameworks und JQUERY ans Herz legen.

Update: Ich muss ein wenig zurückrudern, Joomla zeichnet auch keine Überschriften korrekt aus.

Drupal – das Allround-CMS ohne Chance

Grupal ist im Prinzip eine feine Sache. Ein Allround-CMS, das im Gegensatz zu anderen Systemen sowohl schlank als auch flexibel ist.
Drupal hat sich auf breiter Fläche nie durchgesetzt und wird das meiner Ansicht nach auch auf absehbare Zeit nicht tun. Man kann ein aufgebohrtes WordPress problemlos als kleines CMS benutzen. Man kann aber auch nur Blogs damit führen.
Mit Drupal kann man von Haus aus eine simple Website bauen, mehr geht nicht. Sprechende URLs, Meta Tags, WYSIWYG-Editor, was anders wo Standard ist, muss in Drupal über Module eingebunden werden. Dabei werden die Module in einem anderen Rhythmus aktualisiert als das CMS selbst. Drupal ist ein schlankes System und damit auch sehr sicher. Das gilt aber nicht unbedingt für die Module, ohne die man keine größeren Projekte aufziehen kann. Spannend wird es dann, wenn mehrere Module aktiviert werden müssen, damit das eigentliche Modul funktioniert, welches man benutzen möchte.

Die deutsche Community mag unheimlich nett sein, sie ist aber auch vergleichsweise winzig. Es gibt einen einzigen Podcast mit vier Ausgaben, der offenbar schon einige Jahre alt ist. Die alten Hasen in der Webentwicklung warnen gerne vor TYPO3, die Einstiegshürden seien zu hoch. Was nicht heisst, dass sie bei Drupal niedrig wären. Wer sich in der Logik des Systems zurecht findet, ist den Rest der Zeit damit beschäftigt, passende Module für sein Produkt zu suchen.
Für Webentwickler und Designer mag es sich durchaus lohnen, sich in Drupal einzuarbeiten. Der Otto-Normal–Website-Betreiber möchte aber nicht mit den Feinheiten des CMS konfrontiert werden, vor allem dann nicht, wenn einige seiner Schritte sich nicht rückgängig machen lassen.

Bei recht vielen Webanwendungen ist die deutschsprachige Community nicht groß genug, um auf alle Fragen auch Antworten zu bekommen. WordPress ist die große Ausnahme. Bei Piwik – einer Webanalyse-Software – sieht es schon sehr schlecht aus. Und Drupal wird ebenfalls nicht so stark promoted. Wer also des Englischen nicht mächtig ist, sollte sich von Drupal lieber fern halten.

Das große Manko von Drupal ist meiner Meinung nach der Mangel an fertigen Distributionen.
Was bei Drupal tatsächlich fehlt, sind fertig geschnürte Pakete, die auf bestimmte Aufgaben zugeschnitten sind. Die benötigten Module müssten bereits im Installationspaket enthalten sein. Im Gegensatz zu TYPO3 hat Drupal allerdings nicht einmal eine installierbare Testumgebung.

Für mich ähnelt Drupal einem neu gebauten Haus, dass ohne Heizung und Stromversorgung daher kommt. Man kann zwar darin wohnen, aber wirklich bequem ist es nicht. Im Winter ist es zu kalt, im Sommer ist es zu warm und für jede Verbesserung, die man vornehmen möchte, muss man ewig nach dem richtigen Werkzeug suchen.
Für Drupal gilt daher: ganz oder gar nicht. Wer des Englischen nicht hinreichend mächtig ist und viel Zeit hat, sich hier einzulesen, eine Testumgebung aufzusetzen und viel auszuprobieren und herum zu spielen, für den ist Drupal nichts.