Module Guidelines: Vorschläge, Kritik & Mitarbeit

[StudioVerlag]

Die nimmt Dir ja keiner
Du darfst auch behaupten, daß die Erde eine Scheibe ist, und weil noch keiner über den Rand geschaut hat, ist auch noch keiner runtergefallen (der stammt nicht von mir)

Außerdem hat jeder verstanden was Du GEMEINT hast (Habe nur Erbsen gezählt)

@Waldschwein
Warum verschweigst Du den schönen Bunker ?   oder die gequälten Kinderseelen, die in der Villa rumgeistern  
Außerdem: Wo ist die Frau, das Boot, das Auto ?

[Stefek]

Was allerdings (aus meiner Sicht, nur zur Erinnerung...) definitiv nicht der Fall ist, ist, daß das Entwicklerteam WB 2 für tot und abgeschlossen hält. Eher im Gegenteil. WB 2 ist SEHR lebendig und wird das auch bleiben, jedenfalls für die nächsten 2 - 3 Jahre.

Hallo Bianka,
na, das hört sich doch gut an.

Aber ich denke, es ging jetzt hierbei um die Module-Guidelines?

Was mich persönlich angeht - und ich spreche jetzt auch mal aus meiner Sicht, genau wie der andere Post von mir in diesem Thread:

Es wäre einfach für die nächsten 2-3 Jahre trotzdem gut, einiges an "Disziplin" aus der WB 2.x Moduleentwicklung zu machen.
Ich bin mir sogar ziemlich sicher, dass die vernünftigen WB "3" Entwickler genügend Weitblick haben, um einiges an "Schläue" in solche Guidelines unterzubringen, sodass eine spätere Portierung/Übersetzung von Modulen auf das neue CMS möglich ist - in weniger Zeit.
Ich denke, einige Module sind es absolut wert überarbeitet zu werden.
Selbst einige der "am schlechtesten" programmierten Module erfreuen sich einer Beliebtheit, weil sie einen speziellen Dienst erweisen, ein spezielles Extrafeature bringen.

Und: kämen Guidelines mit Weitblick, könnte man sie jetzt schon überarbeiten.
Eine spätere Umprogrammierung würde einfacher gehen.
Und eine "gesunde" Module Liste würde dem Ansehen von WB gut tun.

Übrigens, wie bewertet man ein Modul.
Wann ist es gut?
Ich denke aus Usersicht ist ein Modul gut, wenn es brauchbar ist.
Für Programmierer ist gut manchmal was anderes.

Gruß,
Stefek

[StudioVerlag]

Ich denke aus Usersicht ist ein Modul gut, wenn es brauchbar ist.

Pragmatisch, praktisch, gut, aber eben weil es z.B. auch valide und SICHER sein soll, eben noch nicht ganz rund.
Sicherheit war der Auslöser für den Thread, soweit ich erinnere.
Gruß, Hans>NUL

[Waldschwein]

Übrigens, wie bewertet man ein Modul.

Das muss der Benutzer selbst fällen. Für "das Team" ist eigentlich nur entscheidend festzulegen, ob etwas draufkommt oder nicht, siehe meine Flowchart (da muss ich nicht mehr erklären, da steht alles drin).
Eine allgemeine Bewertung kann und soll es nicht geben. Das wäre nicht nur Unfug, sondern schießt meistens an den Leuten vorbei, zudem sollte jeder eine gewisse Flexibilität haben an dem, was er einsetzt.
Dass die meisten Module nicht mehr weiterentwickelt werden liegt in der Natur der Sache - seht euch mal bei den Großen Module-Plattformen so um, ob jetzt Joomla oder das (wesentlich größer & professioneller organisierte) Drupal, meinetwegen auch curse.com. 

Gruß Michael

[Stefek]

Hallo Michael,

die FlowChart ist schon mal nicht schlecht.
Doch ein solcher "Schaltkreis" wird nie die Frage beantworten, ob das Modul "brauchbar" oder "beliebt" ist, sondern nur, ob es gemäß gewißen willkürlichen Regeln programmiert wurde und keine Fehler ausgibt.

Gruß,
Stefek

[Waldschwein]

Doch ein solcher "Schaltkreis" wird nie die Frage beantworten, ob das Modul "brauchbar" oder "beliebt" ist, sondern nur, ob es gemäß gewißen willkürlichen Regeln programmiert wurde und keine Fehler ausgibt.

Ganz genau.  Mehr machen muss dann die Community. Das Team kann und soll nicht bewerten, ob Module brauchbar und beliebt sind - dafür gibt's ja dann einen Add-on Showcase mit (wie immer nicht aussagekräftigem) Rating, Download-Zahlen etc. Das Team kann und darf nicht mehr als den Rahmen bieten, das Bild muss schon jeder selber malen, höchsten fragen, wie dies und das geht.

Gruß Michael

[doc]

Hi,

hier mal MEIN Versuch einer Definition der Begriffe "Guideline" und "Handbuch" (aus meiner Sicht).

Versuch anhand eines abstrakten Beispiels:
Wenn man sich ein Handbuch als Gebrauchsanleitung eines Autos vorstellt, entsprechen "Guidelines" einem Auto Prüfkatalog z.B. beim TÜV. Wenn das Auto alle im Prüfkatalog festgelegten Tests bestanden hat, bekommt es vom TÜV eine TÜV Plakette. Ansonsten gibt es ein Mängelschreiben und man wird gebeten nach Behebung der Mängel nochmals vorstellig zu werden

Daher muss aus meiner Sicht das WB-Team (z.B. Quality Team) die Guidelines erstellen und nicht die Benutzer, sonst ist das Chaos perfekt. Handbücher hingegen können auch von Leuten erstellt werden, welche sich mit einem Produkt hinreichend vertraut gemacht haben (Designerhandbuch, Entwicklerhandbuch etc.).

Zusammenfassung:
Handbücher erklären die Schritte die nötig sind, um ein Modul oder ein Template für WebsiteBaker zu erstellen (didaktisch). Beim "Designer Handbuch" habe ich mich damals entschieden, die notwendigen Schritte der WebsiteBaker Templateerstelltung auf Basis einer statischen HTML Vorlage zu beschreiben. Diesen Teil könnte man z.B. prima um die Gestaltung eines Menüs mit Hilfe von Showmenü mittels CSS ergänzen. Der Module Primer ging ebenfalls in die Richtung (Handbuch).

Guidelines hingegegen sind Regelwerke, welche formale Aspekte behandeln (siehe Template-Guidelines).

Hier steht u.a. dass ein Add-on nur in den WB Showcase aufgenommen wird, wenn es sich ohne Fehler installieren und deinstallieren lässt (z.B. bei error_reporting E_ALL), wenn in allen Dateien Copyright Hinweise vorhanden sind, keine Benutzereingaben ungefiltert im Browser ausgegeben werden (XSS), oder ungefiltert in SQL Queries verwendet werden (SQL Injection).

Diese Regeln müssen vom WebsiteBaker Team erstellt werden. Daher fände ich es nach wie vor gut, wenn DarkViper seine Vorschläge mal posten würde.

Doc

P.S.: Man kann natürlich auch Handbücher und Guidelines mischen, davon würde ich allerdings abraten.
P.P.S.: Guidelines und Handbücher sind für WB 2.x und 3.x verschieden

[Stefek]

Versuch anhand eines abstrakten Beispiels:
Wenn man sich ein Handbuch als Gebrauchsanleitung eines Autos vorstellt, entsprechen "Guidelines" einem Auto Prüfkatalog z.B. beim TÜV. Wenn das Auto alle im Prüfkatalog festgelegten Tests bestanden hat, bekommt es vom TÜV eine TÜV Plakette. Ansonsten gibt es ein Mängelschreiben und man wird gebeten nach Behebung der Mängel nochmals vorstellig zu werden

Daher muss aus meiner Sicht das WB-Team (z.B. Quality Team) die Guidelines erstellen und nicht die Benutzer, sonst ist das Chaos perfekt. Handbücher hingegen können auch von Leuten erstellt werden, welche sich mit einem Produkt hinreichend vertraut gemacht haben (Designerhandbuch, Entwicklerhandbuch etc.).

Ich mag Docs Allegorie und kann ihm nur zustimmen.
Handbücher, HowTos und Tutorials sind eine andere Hausnummer als Richtlinen (=Guidelines).

Wenn Guidelines als "Grundlage" zur Aufnahme der Moduole in der offiziellen Repository dienen sollen, dann sollten sie auch von einer offiziellen Autorität etabliert werden.

Keins meiner Templates hat sich je um Aufnahme auf der Repository bemüht, weil ich weiß, dass ich bestimmte Guideline Auflagen "verletze" (z.B. ordne ich die css files anders an als empfohlen und anderen Kram, von dem er mir praktischer erscheint auf meine Art). Aber das ist eine bewußte Entscheidung von mir.

Genau so würde es für Module der Fall sein - "Verletzung" der Guidelines, keine Aufnahme.
Wer dann den Anspruch erhebt, sein Modul vorzustellen, sollte sich mit den Guidelines vertraut machen und sie befolgen.

Es kann auch so etwas geben wie _zu_starre_guidelin es_ , die wenig Raum für Eigeninitiative oder Kreativität bieten und es sollte berücksichtigt und eingerichtet werden, dass man Entwicklern ermöglicht, in bestimmten Fällen eine Lockerung/Erweiterung/Revision der Guidelines zu ersuchen - vorausgesetzt der Entwickler ist ein Profi und sein Vorschlag sinvoll, statt nur eine "Umgehung der Regeln aufgrund ihres Nichtverstehens zu versuchen".

Na, sieht mir aus, als wenn hier tatsächlich was Konstruktives herauskommen könnte in diesem Thread.

Gruß,
Stefek

[doc]

Hi,

Keins meiner Templates hat sich je um Aufnahme auf der Repository bemüht, weil ich weiß, dass ich bestimmte Guideline Auflagen "verletze" (z.B. ordne ich die css files anders an als empfohlen und anderen Kram, von dem er mir praktischer erscheint auf meine Art). Aber das ist eine bewußte Entscheidung von mir.

Änderungs- oder Verbesserungsvorsch läge diesbezüglich sind vom aktuellen WB-Team bestimmt gerne gesehen, also nur zu. Auch Chio handelt einiges anders. Also sollte man sich fragen warum, macht das Sinn und sollte man das ganze hier oder da lockern - fertig.

Es macht nur wenig Sinn, Modulguidelines ohne Einblick in die derzeit vorhandenen Resourcen (Teammitglieder), deren Kenntnisstand, möglicher Prozessabläufe und Beschlüssen bezüglich Weiterentwicklung (WB 2.x, WB 3.x) zu erstellen. Daher meine Bitte DarkViper möge doch mal seinen groben ersten Entwurf vorstellen.

Hoffe meine Meinung dazu ist nun etwas klarer rübergekommen. Und nun bin ich auch wieder ruhig

Doc

[Luisehahne]

Danke Bianca,

du sprichst mir aus der Seele. Chio ist übrigens für mich ein hervorragender Fachredakteur.

Dietmar

[Luisehahne]

Ich habe gerade festgestellt, dass ich missxverstanden werde. Für Guidlines gibt es keine Kompromisse. Die legen die Developer fest. Die müssen schliesslich auch für alles den Kopf hinhalten.

Mir ging es nur darum dies in verständlichen Worten zu fassen. Denke da denken wir Coder manchmal um ein paar Ecken. Hier geht es um Gestaltung und wird es verstanden, es gehtnicht um die Richtlinien selber. Ich stelle das bei mir selber fest, wenn ic hetwas versuche zu erklären, setze ich das bei dem anderen voraus, was ich bereits weiss. Und das ist Betriebsblindheit oder wie man das auch nennt.

Dietmar

[Waldschwein]

Hallo!

Dietmar, es geht hier nicht um Sprache.

Irgendwie reden hier alle aneinander vorbei.   Eigentlich haben alle hier Recht, für sich betrachtet. Nur macht sich keiner die Mühe auch nur verstehen zu wollen, was die anderen überhaupt meinen könnten - leider. So kommen wir nicht weiter.

Da mir (zu Recht) vorgeworfen wird, ich schreibe zu viel und zu umständlich, male ich es mal auf.
Bitte seht es so, als ob ich es geschrieben hätte.

Gruß Michael








[gelöscht durch Administrator]

[Stefek]

Das erste Bild lädt nicht grad zum Lesen ein (der erste Eindruck).

Hehe... na, das zweite Bild trifft doch die Sache auf den Punkt.

Hast Du Dein MindMapping Tool neu endeckt? 

[doc]

@Waldschwein: Heureka (Rest siehe PM)

[chio]

Was ICH mir wünschen würde (und vielleicht käme man so schneller mal wohin)

Wie bei FAQs zuerst mal konkrete Fragen stellen, da dann von Sachkundigen beantwortet werden.
NICHT sagen: Das steht schon 30mal im Forum - ja: die _Frage_ steht schon 30x im Forum, aber keine brauchbare Antwort (die Antworten sind oft ungenau, nicht immer von Leuten die _wirklich_ Ahnung haben. usw)

Für mich gehören da u.U. auch Fragen dazu, die vielleicht nicht direkt mit WB zu tun haben, ($_GET überprüfen usw), wo aber letztlich viele der Fehler passieren. Da kann sich ein Guide/Handbuch nicht abputzen, schließlich sind das ja Sicherheitsfragen.

Die Zuordnung von FAQ zu EntwicklerGuide, Handbuch, Wühlkiste kann ja dann später erfolgen.

[Waldschwein]

Hallo!

Ich gestalte schon seit Jahren solche Sachen (doc wird sich noch dunkel erinnern können  ). Übrigens ist das mit Visio gemacht, MSDNAA sei Dank.

Aber mir geht's nicht darum, wer die tollsten Bildchen entwirft, sondern einfach, dass man hier endlich mal versteht, um was es eigentlich geht! Unkoordinierte "jeder macht mal das was er denkt" endet wie so oft in halbfertigen Sachen, die durch die Gegend wandern.

Das kann doch alles nicht so schwer sein - guckt einfach mal links, mal rechts wie es "die anderen" machen, und wieso die gerade Erfolg haben, oder eben keinen. Die Konkurrenz (trifft nicht zu, aber jeder weiß was gemeint ist) zu analysieren ist einer der wichtigsten Bausteine von Management in all seinen Facetten, ob jetzt Marketing, Projekt oder Qualität.
Es genügt eigentlich ein Blick auf die zutreffenden Wikipedia-Artikel, um einen ersten Eindruck zu gewinnen, um was es hier eigentlich geht.

Nochmal: Ich halt wenig davon, dass jetzt jeder in Euphorie ausbricht, am Ende haben wir wieder mal drei FAQ, und alle halbfertig. Das ganze muss koordiniert werden, doch leider findet sich kaum einer dazu, wirtschaftlich zu arbeiten hier. Zu wirtschaftlich arbeiten gehört übrigens auch, seine Freizeit, die hier jeder aufbringt, nicht unnötig zu vergeuden.

Gruß Michael

[Stefek]

@Bianka: Kommt auf den "Mind" drauf an, der dem Burschen gehört, der die "Map" erstellt 


Übrigens, Michael, sollte keine Kritik wegen der ersten Darstellung sein. Ist auf den ersten Blick einfach sehr überladen.
Aber die Ideen sind gut.


Irgendwas stimmt in der zweiten Illustration aber mit der Aufzählung der Addons nicht.

Addons sind (nämlich):
Module

Section Module (aus "historischen" Gründen 'Page Module' genannt)
Admin Tools
Snippets

Templates

Frontend Templates
Backend Themes

Language Files

Language Files

Droplets sind keine Addons, sondern bestenfalls Makros eines der Admin-Tools. Dass es eine Erweiterung darstellt ist klar, aber vieles davon ließe sich auch über eine CODE Section realisieren. Das Thema zu behandeln wäre sinvoll, aber es sollten nicht Droplets mit Addons verwechselt werden.
Ich meine, eine klare Linie sollte gezogen werden.
Das liegt auch im Wesen des Wortes "De-Finition", was ich bereits früher bemängelt habe (klare Definitionen) und was auch der Grund ist, warum Doc's Beitrag #41 mir persönlich gefallen hat.

Jede Bemühung von Seiten der Teams, klare und akkurate Definitionen der WB eigenen und angrenzenden Begriffe bereit zu stellen, wird die Kommunikation und reibungslose Arbeit an all den hier besprochenen Themen und Vorhaben stark verbessern.

Ich spreche jetzt nicht von Begriffen wie "HTML TAG" heißt.... doch wird man feststellen, dass Leute, die mit Webdesign "arbeiten" und solche Begriffe wie tag, element, attribut, markup (nur um ein paar zu nennen), nicht klar definiert haben, werden nicht imstande sein, ein Template zu erstellen. Die komplizierteren Begriffe werden nur noch komplizierter.
Wie ist es dann, wenn Leute sich an den Bau von Modulen machen, ohne die Eifenheiten von WB zu kennen?
Klar, ein Super PHP Coder wird sich nach einer gewißen Zeit vertraut gemacht haben - aber auch nur, weil er nicht anders kann, weil er nicht über einen Begriffskatalog verfügt.
Und hätte es das gegeben, würde Michaels Illustration auch anders ausfallen - denn es stimmt, die Leute haben sich fast alle Tipps selbst erarbeitet und deswegen zählt die Bauernweisheit: "Meinung dort, wo Wissen fehlt" oder anders ausgedrückt: wo klare Definitionen fehlen, gibts Raum für Spekulation.

Auch ein Ziel/Zweck zu definieren ist ein Teil jeder solchen Unternehmung, denn Zwecke sind Richtlinien immer übergeordnet und ohne Zwecke sind Richtlinien etwas, das eher für Mißklang, denn für Ausrichtung sorgt.

Das soll jetzt keine Aussage sein, dass Ziele und Zwecke nicht definiert sind.
Ich bin hier nur im Forum unterwegs.
Ich sag das nur, weil ich weiß, dass man sich hier oft um den Mangel an Definitionen herum im Kreis dreht.

Und jetzt, Kaffeezeit.

Gruß,
Stefek

[Waldschwein]

Hier diskutieren Leute, die aber gleich dazu sagen, daß sie sich nicht aktiv an einer Umsetzung beteiligen wollen, über Dinge, von denen sie glauben, daß "man" sie mal machen müßte. Welchen Sinn hat das eigentlich?

Das ist eine gute Frage, ich weiß es auch nicht. "Man" würde allerdings bedeuten, dass alle zusammen arbeiten müssten. Das ist wohl das Hauptproblem. 
Nach dem Klären einiger interner, organisatorischer Fragen von WB werde ich mich hier allerdings stark machen, eine Lösung zu finden. Gibt's keine vernünftige Lösung zu dem Thema, und bleibt es so wie es jetzt ist, werde ich durchsetzen, den Add-ons Showcase wie er momentan ist einzumotten und auf AMASP umzuleiten.

Gruß Michael

[Waldschwein]

Hallo!

Mein Vorschlag wäre, die _sachlichen_ Punkte aus diesem Thread zu extrahieren und auf dieser Basis weiterzumachen.

Gearbeitet werden kann eigentlich erst, wenn die Leute aktiv werden, die dafür verantwortlich sind, sich bisher aber nicht gemeldet haben. Es wurde nunmal die Struktur gewählt, die es gibt, und die muss man akzeptieren, oder eben nicht. Auch wenn es so aussieht - die letztendliche Entscheidung steht woanders, nicht hier. Drum bringt die öffentliche Diskussion nichts.
"Hinter den Kullissen" werden allerdings genügend Fäden gezogen, es dauert halt. Es braucht langen Atem, hab ich ja bei der Webseite gemerkt.

Gruß Michael

[Stefek]

Hallo Michael,

so sehe ich es auch.

Wie schon oben geschrieben, ist für mich persönlich, der primäre Schritt einer jeden Unternehmung die Definition ihres Zwecks.
Von da an kann man weiter nach unten ordnen.

Und sehr wohl hat Gedankenaustausch einen beitragenden Charakter, was auch den Siegeszug der Diskussionsforen im Web erklärt.

[deleted fragment]

[StudioVerlag]

"Hinter den Kullissen" werden allerdings genügend Fäden gezogen, es dauert halt.

Na toll, das ist der alte Stil, nur daß es jetzt alle machen.
Das ist selbsterklärend. Da kann ich mir jegliche Polemik sparen.
Macht weiter so.

[Waldschwein]

Gut, dann sage ich es mal nett:
Wir machen es so, wie wir es machen, nicht wie du es uns sagst. Wenn es dir nicht passt, gehe. Und mir wäre lieber eher früher als später, es gibt sogar noch Leute, die was auf dich halten hier.

@Bianca: Schade. Ist wohl aber besser so. Wenn ich's auch tun soll bitte sagen.

Gruß Michael

[StudioVerlag]

Gut, dann sage ich es mal nett:

Das hatte ich nicht vorausgesehen. Versau mir nicht meinen Vorsatz  

Wer Polemik braucht, bekommt sie halt.

Welch Geistes Kind, oder welch Kellergeist.

Zu bestimmten offenen Kommunikationsproze ssen gehören natürlich u.a. auch einige soziale Kompetenzen.
Die kann man sich, bis auf's Kaffeetrinken, bei solch einer Auffassung natürlich sparen.
Dann klappt's auch mit IT'lern, bei denen das auch nicht so ausgeprägt daherkommt, wie nicht nur eine Studie hierzu belegt. Hast ja auch schon an anderer Stelle bewiesen, daß Du Dich bei Kompetenzen zu sehr aus dem Fenster lehnst Wer behauptet, daß Fakten je nach Lehrstuhl beliebig aussehen können, hat keine Ahnung von Wissenschaft und erst recht nicht vom Wissenschaftsbetrie b. Den unbedarften Forenlesern kannst Du natürlich so einen Blodsinn unwidersprochen auftischen. Leuten vom Fach nicht. Sei froh, wenn (D)ein Arbeitgeber diesen Quatsch nicht liest.
Etwas weniger ist halt manchmal etwas mehr.
Gruß, Hans>NUL

[Stefek]

Hallo Michael,

eventuell könnte ich mich einbringen, es kommt aber wirklich auf die Formulierung der Zwecke bestimmter Aktivitäten drauf an.

Wenn es um Guidelines an sich geht, werde ich keine Fachkraft darstellen.
Aber wie von BianKa oben angedeutet, ist es manchmal hilfreich, wenn jemand der nicht unter etwaiger Betriebsblindheit "leidet" drauf schaut.

Es ist aber kein Versprechen. Ich habe nicht viel Zeit mit zu bringen.
Ich bin zuversichtlich, dass sich das ganze auch ohne mich positiv entwickelt und habe daher keinen "Handlungszwang".

Werner (DarkViper) ist ein Mann von Fach, und ich konnte in seinen Beiträgen immer einen roten Faden mit genügend Fachkenntnis und verhältnismäßig ausgeprägtem Sinn für Verständlichkeit beobachten.

Eben wie Doc, würde ich mich über einen Einblick in seine Ausarbeitungen freuen.

@Hans>NUL(L)
Die Problematik mit einer öffentlichen Definition ist, dass man das ins unendliche führen würde.
Es ist leicht Aussagen zu machen, wenn "die anderen das machen".
Du stellst oft hohe Ansprüche an Webstandards, zurecht, wie ich finde, doch wenn Du Dich einbringen willst, kannst Du es auch innerhalb eines geschloßenen Kreises machen.


Gruß,
Stefek

[StudioVerlag]

doch wenn Du Dich einbringen willst, kannst Du es auch innerhalb eines geschloßenen Kreises machen

Gut angemerkt. Dem widerspreche ich ja nicht prinzipiell.
Jeden Furz rauszuposaunen stört möglicherweise auch den inneren Fortgang (Die Kinder schreien   ).
Für lange Zeit gab es aber überhaupt keine "Nachricht aus dem Bunker"  
Erst länger anhaltende Bohrerei hat es bis zu solch einem Thread gebracht.

Man kann es natürlich auch weniger forsch forden und sich bescheiden mit dem Wunsch nach etwas mehr an Kommunikation, was auch ursprünglich meine Intention war. Einfach, weil die, die WB einsetzen, wissen wollen wo es lang geht. Viele wollen ihre Arbeit vorausschauend und auch nachhaltig gestalten. Das war, wenn ich rückblickend auf die Reaktionen/Kommentare meiner Anwender und der IT'ler schaue, nicht möglich. Wenn hier mehr Infos kämen, wären einige sorgenfreier.

Von mir aus "geschloßener Kreis", aber nicht so, daß -wie lang gespflegt- die Anwender mit neuen unbekannten "Überraschungen" beglückt werden, aber die Fragen nach "aktuellem Thema/siehe Topic" ausgespart werden. Mir ist schon bewußt, daß die Entwickler hier nicht mit Doppelaufgaben belastet werden dürfen. Aber dafür gibt's doch jetzt das Kommunikationszentr um  

Gruß, Hans>NUL