skip to content

Archiv

Module

Es wäre Zeit, die Websitebaker-Module genauer zu betrachten.

Das „All Modules and Snippets Project“ AMASP hat viele Module ans Tageslicht gebracht, die sonst in den Untiefen des Website Baker Forums verloren gegangen wären. Aber es hat auch was anderes gezeigt: Nicht alle Module sind wirklich gut.

Das AMASP hat sich zur Aufgabe gemacht, alle Module und Snippets zu listen. Nicht: zu checken. Das wäre schlichtweg zu viel verlangt. Vielmehr werden die Modul-Autoren animiert, ihre Module selbst auf dem aktuellen Stand zu halten.

Hier liegt schon ein Teil des Problems: Für Module, die nicht zum „erweiterten Kern“ von WebsiteBaker gehören, fühlt sich niemand so recht zuständig. Oft nicht einmal deren Autoren.

Woher Module kommen

Ein Großteil der Module entstand daraus, dass jemand eine bestimmte Funktion auf seiner Website haben wolle, sie programmiert hat und anschließend wieder der Community gratis zur Verfügung gestellt hat.
Ein häufiger Fallstrick dabei: Das Modul wurde für eine bestimmte Aufgabe gemacht und der Entwickler kennt es in und auswendig. Ich nehme mich hier an der eigenen Nase: Alle Seiten, auf den ich zb "Topics" einsetze, haben einen weißen Seitenhintergund – inklusive zb dieser hier. Ich habe nicht daran gedacht, dass es anders sein könnte.
Wenn ein Modul aber mal draußen ist, sind einem die Hände gebunden: Es soll ja kompatibel bleiben. Die schnelle Änderung ist nicht mehr drin, es wird mühsam. Und das für Gottes Lohn.

Bei den Top3 CMS: Joomla, Typo3, Drupal gibt es nicht nur ein paar Hundert Module, sondern gleich ein paar Tausend. Das heißt nicht zwangsläufig, dass mehr Nadeln im Heuhaufen sind - sondern dass der Heuhaufen größer ist.
Bei Joomla gibt es zB. Massen von Modulen, die das lokale Wetter anzeigen – würden, wenn nicht die Betreiber des Wetterdienstes die API inzwischen geändert hätten.

Copy&Paste Inzest

Viele Module basieren auf einem anderen Modul – klar: Man muss das Rad nicht immer neu erfinden. Nun hatten aber manche der älteren Module schon ihre Schwächen, die oft mal mitübernommen wurden. Lange Zeit war zb das Gästebuch das einzige sinnvolle Modul zur "Interaktion". Und News das einzige, das selbst Seiten erzeugte. Und "Bookmarks" das einzige, das Dinge in Gruppen zusammenfassen konnte. Ein Fehler in "Bookmarks" wurde zb in "Team" und "Members" übernommen. Ein kleiner Fehler in "News" steckte lang im wesentlich jüngeren "Bakery".
Besonders das "Gästebuch" wurde für alle möglichen Module als Vorlage herangezogen, obwohl das Gästebuch permanent umgemodelt wird. Klar: Alle Module, die auf dem Gästebuch beruhen, können nicht auf dem aktuellen Stand sein.

Qualitätsoffensive?

Traurig – aber wahr: Viele Module sind veraltet. Manche lassen sich nicht mehr deinstallieren. Manche machen Probleme bei der Suche. Manche sind ein Frickelwerkchen, in dem jeder Standard fehlt. Die Autoren haben in der Zwischenzeit 5 Kinder und schlichtweg andere Hobbies.

Nur: wer soll deren Arbeit übernehmen und fortsetzen? Ein Team zur Qualitätssicherung wird langfristig scheitern: Programmierstile und eigene Ansichten prallen zu sehr aufeinander; statt ein Modul zu verbessern ist es oft weniger Arbeit, gleich von vorne zu beginnen => Noch ein Modul...
Und überhaupt: Wo anfangen? Zeit, andere Wege zu finden?

Evaluierung!

Welche Module sind wichtig? Welche sind brauchbar? Wo würden ein paar Handgriffe reichen, und schon geht das Teil wieder? Und: Wo ist Hopfen und Malz verloren?

Bewertungssysteme (wie StarRating) sind wenig objektiv und leicht fälschbar. Andererseits: Who cares? Wer wird ein lange vergessenes Modul pushen? Die Masse macht es, alle Fälschungsversuche gehen in einer breit angelegten Evaluierung unter (Google beweist das immer wieder ;-)

Als Ort der Austragung würde sich einmal mehr das AMASP anbieten: Dem AMASP fehlt zum Glück der "offizielle Anstrich", eine Kommentarfunktion mitsamt StarRating wäre schnell eingebaut und zumindest für begrenzete Zeit auch pfleg- und wartbar.
 

Back

Kommentare:

29.01.2010

Michael Tenschert

Hallo!

Du hast übrigens den wichtigsten Aspekt vergessen in deinem Artikel: AMASP ist privat, nicht "offiziell". ;-) Das macht es nicht besser und auch nicht schlechter, nur sollte dabei auch erwähnt bleiben, dass das Problem der WB Module die offizielle Add-ons-Seiten sind. Und daran hängt sehr viel mehr, als die technische Seite - leider. Gäbe es denn auch bloß 5 Leute, die sich dafür verantworlich sehen würden, hier aktiv sich in einen ausführenden QM-Add-ons-Team einzuspannen lassen und alles durchzugehen wäre man schon viel weiter. Doch es gibt schlicht niemand, der das möchte. ;-)

Gruß Michael

29.01.2010

doc

Naja,

laut der offiziellen Teamliste hat das QM-Team derzeit 4 Mitglieder. Ist also nicht weit von den von Dir geforderten 5 Leuten entfernt.

Doc

29.01.2010

Michael Tenschert

Das QM-Team hat aber nichts mit dem Testen von Modulen zu tun, sondern mit dem Entwickeln der Leitlinien, worauf das Testen basiert.

Gruß Michael

30.01.2010

doc

Naja, wenn es erstmal Leitlinien gibt, finden sich bestimmt auch Leute die Module, Templates etc. testen. Es gab vor nem Jahr einige Meldungen (>4) fürs "Test-Team".

Stimme aber Chio zu. Wird Zeit bei den Add-ons die Spreu vom Weizen zu trennen, die vorhandenen zu evaluieren, in Kategorien einzuteilen. Lieber wenige gute, statt viele schlechte Module.

Die Downloads (über die Zeit betrachtet) und Aktivität in den verlinkten Modulthreads geben einen groben Überblick über Beliebtheit und Akzeptanz, sowie Support von Entwicklern. Diese Kriterien können aber eine Bewertung, Vorsortierung und Tests nicht ersetzen.

Um das "klonen" und die Übernahme von Fehlern aus anderen Modulen einzudämmen, wäre ein aufgebohrtes "Hello World" Modul nicht schlecht, welches die typischen Schritte und Anwendungsfälle (Formdaten, DB, Ausgabe, Settings ...) erklärt.

Doc

30.01.2010

Chio

Nun ja: "Lieber wenige gute, statt viele schlechte Module" – da haben wir schon das erste Problem. Was ist "gut"? Für den einen muss ein Modul mit DTD "Strict" klarkommen, alles andere ist Mist. Für den anderen ist egal, ob das Ding überhaupt validen Code auswirft - Hauptsache es tut was es tun soll. Wer entscheidet das? Jeder hat seine persönlichen Vorstellungen, was ein "gutes" Modul ist.

Ich fürchte, dass sich ein Team schon an dieser Frage zerwirft, noch bevor irgendwas Konkretes rauskommt.

Ich würde es für besser halten, mit einer Art Punktesystem zu arbeiten, und so mit der Zeit eine Reihung heraus zu bekommen.

Ein "aufgebohrtes "Hello World" Modul" wäre tatsächlich nicht schlecht, es sollte aber etwas tiefgreifender sein. Und dazu Guidelines, was wie zu machen ist. Do’s and Dont‘s

31.01.2010

doc

[quote author="chio"]Jeder hat seine persönlichen Vorstellungen, was ein "gutes" Modul ist.[/quote]
Yepp. Meine Vorstellung: Modul muss sich bezüglich Sicherheit und Coding Empfehlungen and die (noch nicht vorhandenen) Add-on Guidelines halten.

Darüber hinaus darf ein Modul im Betrieb keine Warnungen/Fehler erzeugen (PHP error level an WB Core angepasst). Die Modulausgaben sollten min. CSS 2 und XHTML 1.0 Trans. konform sein (Standardeinstellung der WB Backend Themes) und den W3C Validator ohne Fehler passieren.

Modulausgaben sollten im aktuellen Firefox und in z.b. IE + Opera (letzten 2 Majorversionen) zumindest nicht auseinanderfallen.

Die Guidelines sollten die Messlatte höher legen als heute, dabei aber keine allzu grossen Hürden in den Weg stellen. Wichtig wäre in dieser Beziehung halt ein aufgebohrtes und konsequent ausgearbeitetes "Hello World" Modul.

Doc

Kommentar

Name:

E-Mail (required, not public):

Webseite:

Kommentar :

Up
K