Wofuer? [was: Re: CMS fuer Skolelinux]
Prescriptum:
So, mir ist jetzt mal nach Luftablassen...
(D.h. wird mal wieder länger; also beim Antworten bitte besser nur
Stichpunkte herausgreifen und mein Blabla großzügig löschen.)
@David: nimms bitte in keiner Weise persönlich; es ist nur zufälliger-
weise gerade deine Mail, welche die [richtigen] Stichworte liefert.
David C. Weichert schrieb:
heute hatten wir ein kleines Arbeitsfrühstück bei Kurt, wo es unter
anderem auch um die Einführung eines CMS für Skolelinux.de ging.
Gut, daß ich davon mal wieder nichts mitbekommen habe.
Dann hätt ich mir das Zusammentexten hier sparen können(?).
Im Augenblick sind das alles statische Webseiten.
Das sind ja grade mal ein Dutzend statische Seiten gegenüber hunderten
("dynamischen") im Wiki.
Dafür ein CMS? Ich glaub', ich steh' im Wald.
Als Kandidaten stehen z.
Zt. Drupal, Typo3 und ein angepasstes MoinMoin im Raum. In 14-21 Tagen
soll ein Treffen des CMS-Technik-Teams über die bis dahin gesammelten
Erfahrungen berichten, um dann vielleicht schon zu einer Entscheidung zu
kommen. In diesem Zusammenhang würden wir auch gerne Eure Vorschläge
aufnehmen.
Ich verlege daher meine Antwort auf die Mail
http://www.skolelinux.de/pipermail/user/2005-October/004148.html
hierher, weil mir das passender erscheint.
David C. Weichert schrieb:
>
> Mir würden einige Dinge auf den Nägeln brennen, die der Lösung bedürfen.
> Ob sich dies im Rahmen eines Arbeitswochenendes machen lässt, weiss ich
> nicht.
>
> Im wesentlichen geht es um 2 Themenkomplexe:
>
> 1) Webseiten von Skolelinux.de/Debian-Edu.org
>
> 2) Dokumentation für Skolelinux Sarge
>
> zu 1) Wir haben Leute, die gerne am Design und Content der Webseiten
> mitwirken wollen, aber kein CMS. Alles, was bisher geht, ist Inhalte im
> Wiki zu versenken, damit haben sehr viele ein Problem, weil sie Inhalte
> nicht (wieder-)finden. Damit Design, Content, etc. entwickelt werden
> können, brauchen wir ein Web-CMS und ein kleines schlagkräftiges
> Redaktionsteam. Ziel an einem Arbeitswochenende sollte sein:
>
> a) ein CMS auf Skolelinux aufsetzen
>
> b) das Team mit dem CMS soweit bekannt machen, dass damit gearbeitet
> werden kann und dass die Aufgabenbereiche abgegrenzt sind und durch den
> Workflow abgebildet sind.
Ich bin von "wir brauchen ein CMS" immer noch nicht überzeugt.
Die Arbeit liegt woanders (s.u.).
Oder wir nehmen gleich Typo3; weil: was das nicht kann, daß kann dann
auch kein anderes CMS.
Aber auch da müssen die u.a. Punkte erst abgearbeitet werden, bevor
was Benutzbares herumkommt.
- Design -
Wer Design machen möchte, soll das doch tun und mal was designen.
Ich hab da noch nix gesehen. Wo sind die Mockups?
Und die Umsetzung in ein CMS/was-auch-immer kommt doch sowieso erst
*danach*.
Ich sehe nicht, wofuer ein CMS vonnöten ist, um erstens Designarbeit zu
leisten und zweitens Design umzusetzen.
Und ich sehe auch nicht, was es bringen soll, jetzt das eine oder andere
CMS herzunehmen und dann darin planlos rumzurühren, nur um zu sehen, was
man denn designmäßig damit machen kann und/oder wie das konkret geht.
Design, welches diese Bezeichnung auch verdient, kommt auch ohne dynamisch
generiertes Flash oder was-auch-immer-für-Spezialitäten aus, sondern läßt
sich auf jedes einigermaßen flexible XYZ umsetzen; egal ob das XYZ nun
Wiki, CMS, Makefiles oder sonstwie heißt.
Natürlich ist es auch ein Punkt, daß einem die Besucher/Nutzer der Seite
nicht davonlaufen, weil die Anmutung eine Zumutung ist.
Wer meint das Wiki-Theme ist grottig, der soll zumindest mal vortreten und
es sagen.
Es gibt ein ganzes Dutzend 'schönere' Stile für MoinMoin als das aktuelle.
Man müßte nur mal eins einspielen. ...Als Standard wohlgemerkt; denn wenn
man angemeldet ist, kann man sich sowieso sein eigenes wählen (...und zwar
nicht nur die im Auswahlfeld -- da gibts auch ne extra Zeile für zusätzliche
CSS-Dateien in den persönlichen Einstellungen).
Wem das aktuelle nicht paßt, der kann sich ja mal einfach auf die Suche
nach MoinMoin-Stilen begeben und dann hier Vorschläge machen ...über die
dann 'abgestimmt' werden kann.
(Auch ich finde den momentanen Stil suboptimal. Allerdings sehe ich die
Hauptproblematik in der [fehlenden] Struktur der Site. Daher bin ich der
Meinung, daß zunächst das Strukturproblem gelöst werden sollte, und man
sich dann besser /danach/ eine neue Optik gönnt, die dann den internen
Wandel nach außen kenntlich macht [neudeutsch: kommuniziert]. Ändert man
die äußere Form, ohne die innere zu ändern, dann verspielt man in großen
Teilen die Wirkungskraft einer neuen Optik.)
Aber so eine Oberflächenpolitur ist, wenn überhaupt, nur Beiwerk. Wenn es
allein darum ginge, die Website von "sieht bescheiden aus" hinzubringen zu
"sieht nett aus", dann braucht man bloß Bildchen mit halbnacktem weiblichem
Fleisch auf jede Seite zu pappen. Vorzugsweise entsprechende Anime-/Manga-
Girlies, damit das voyeuristische Element nicht *so* dermaßen offensichtlich
ist ...und man ist dabei auch viel jugend- und zielgruppen(?)-gerechter
...sind ja nur Zeichnungen / trendy Comic-Elemente.
(Und: Nein, das ist *kein* Anflug von Zynismus, sondern ein erprobtes Mittel
um die Verweildauer auf Seiten zu erhöhen.)
Design ist nicht nur mehr als "sieht nett aus". Design ist was anderes.
Design ist Form und Funktion.
Design ist auch kein kreatives Rumgewurschtel.
Design ist harte Arbeit, die ein hohes Maß an erstens Verständnis,
zweitens Professionalität und [erst] drittens Kreativität erfordert.
Design braucht ebendarum aber auch *Vorgaben* bzw. *Leitlinien* für Inhalt,
Struktur und Abläufe (neudeutsch: Workflow).
Es wurde schon vielfach über jeden einzelnen der Punkte diskutiert, aber
greifbar -- d.h. nachlesbar oder ähnliches -- haben wir diesbzgl. bisher so
gut wie gar nichts, nicht mal oberflächlich!
[...Zumindest kommt mir da bis auf die Arbeit von Manuela und mir nichts in
den Sinn. Was habe ich übersehen? Wo ist mein blinder Fleck? ...Aber es
geht auch nicht darum, mit dem Finger auf andere zu zeigen, sondern den
Finger in die Wunde zu legen.]
Dementsprechend ist es nur eine Selbstverständlichkeit, daß an der Design-
Front bisher auch nichts passiert ist.
Die Installation eines CMS bringt, wenn überhaupt, allerhöchstens eine Ober-
flächenpolitur; ...und diese auch nur für den Fall, daß die Anmutung des CMS
'schicker' ist als eine für das Wiki mögliche.
Ein CMS ersetzt kein Design. Es ist auch keine Bedingung, ja noch nichtmal
eine Randbedingung, dafür.
"wir *brauchen* ein CMS" ...fürs Design? Sehe ich nicht.
Design selbst ist allerdings durchaus etwas, was wir brauchen.
...Und wo ich gerade dabei bin (obwohl es mit Design nur teilweise etwas
zu tun hat): was wir noch brauchen können, ist die Möglichkeit Inhalte bei
Bedarf auch spezieller formatieren zu können, als es das Wiki-Markup her-
gibt.
Ich habe mal grade nen Exkurs nach reST (ReST?) gemacht.
Das würde mir schon reichen. (Da kann man dann mal ordentlich Tabellen
machen, row-/col-span macht keinen Umstand und in die Zellen kriegt man
sogar noch direkt Listen und Bilder rein.)
Ich weiß, Tabellen als Formatierungshilfsmittel sind genaugenommen böse.
Im Abwägen der Vor- und Nachteile finde ich es aber besser, es ab+zu über
sowas wie reST gezielt einsetzen zu können, als für jedes kleine bischen
Extra über den Weg des direkten Einbindens von HTML gehen zu müssen.
(Wobei bei Letzterem TheWayToGo[tm] wäre, die CSS-Datei um Formatierungs-
definitionen zu erweitern, die man so haben möchte, und dann im HTML auf
diese Klassen zurückgreift; damit man sich durch ein kleines unbedachtes
Tag nicht gleich die komplette Seitenformatierung zerschießt, und dann in
ein unsägliches [HTML+CSS-]Debugging gehen muß.)
Aber bezüglich reST-/HTML-/CSS-Unterstüzung ist es an sich auch egal, ob das
jetzt mit ner Wiki- oder CMS-Engine verknüppelt ist.
D.h. nur weil man ein CMS hernimmt / hernehmen möchte, ist diese Anforderung
bzw. Problematik auch nicht automatisch erschlagen.
- Inhalte / Abläufe -
Um Inhalte zu finden ist es am besten sie wiederauffindbar abzulegen.
Dazu braucht man Struktur. Und diese Struktur muß zwei wesentliche Aspekte
gut erfüllen:
o Eine klare Gliederung der Inhalte muß sich in ebenso klaren und
verständlichen Schlagworten/Oberbegriffen widerspiegeln und diese
wiederum müssen in ebenso klarer Beziehung bzw. Abgrenzung zueinander
stehen.
o Die Strukturierung muß die unterschiedlichen Abläufe in verschiedenen
Arbeitsbereichen unterstützen.
Wo haben wir den bisher Benamsung geklärt?
Wo ist denn eine Begriffsliste mit den dazugehörigen Bedeutungsräumen?
Wo sind denn bisher Arbeitsabläufe spezifiziert?
(Nein, nicht die Ablaufspezifikationen, die beschreiben, wie das Wiki (.de)
bzw. das Plone (.org) umgangen werden, um effektiv was zustande zu kriegen;
sondern die Spezifikation des Ablaufs, wie er sein sollte bzw. wir ihn haben
wollen.)
Und *wenn* /diese/ Sachen dann mal geklärt und nachvollziehbar gemacht
worden sind, dann sehe ich kein Problem, daß man sich an diese Übereinkunft
einfach zunächst mal hält.
Das ist doch auch im Wiki kein Problem; genausowenig wie die dortigen
Homepage- und ArbeitsWE-Seiten.
Irgendwelche Begriffe oder Abläufe dann darüberhinaus mittels eines CMS zu
*erzwingen* halte ich für eher kontraproduktiv. Insbesondere wenn man das
dann auch noch so a la "one word/workflow fits all" auf multinationaler/
-sprachlicher Ebene macht.
Es sind m.E. doch gerade diese Punkte, die einem die Arbeit im .org-Portal
verleiden. Infolgedessen werden dann doch alle zu Redakteuren gemacht, damit
man dann nämlich den Workflow zumindest abkürzen und somit letztendlich fast
beliebig (i.S.v. freizügig) 'herumwurschteln' kann.
Unter der Berücksichtigung gemeinsamer Leitlinien (neudeutsch: policies)
sehe ich kein Problem in einem Wiki.
Ein Wiki kann im Ggs. zu einem CMS keinen Vandalismus oder mutwillig
erzeugtes Durcheinander verhindern.
Aber mit beidem hatten wir nie ein Problem im Wiki und werden wohl auch
keins damit bekommen.(Bis auf die Werbebots; seitdem ist eben Schreiben
erst nach Anmeldung. Wäre bei einem CMS aber auch nicht anders.)
Bisher ist doch alles mit gegenseitigem Respekt, gesundem Menschenverstand
und gemeinsamen Absprachen wunderbar gelaufen.
Und das bisherige Durcheinander ist ja nicht mutwillig/böswillig entstanden,
sondern weil es bisher keinen deutlichen "Leitfaden für die Ablage" gibt.
Um es mal auf den Punkt zu bringen...
* Ich möchte die Flexibilität eines Wikis ungern verlieren, nur weil mit
einem CMS angeblich automatisch auch die Ordnung einzieht.
* Ich aus den dargestellten Gründen davon überzeugt, daß sich die neuralgi-
schen Punkte lösen lassen; auch unter Beibehaltung eines Wikis im allgem.
und -- mit einigen Detail-Tweaks -- auch mit MoinMoin im speziellen.
* Ich bin, was die technische Seite* betrifft, daher für die Integration von
reST und XML in unser MoinMoin. (XML per *angepasstem* Plugin.)
[*) Unabhängig von den Struktur- und Ablauf-Aspekten.]
* Ich bin *keineswegs* grundsätzlich gegen ein CMS. Ich halte nur den Mehr-
aufwand [über die o.a. notwendingen Arbeiten hinaus], den ein CMS für die
Einrichtung und die Pflege braucht, für unnötig und vermeidbar.
* Vielleicht ist ein CMS aus anderen Gründen nötig --- s.u.
> zu 2) Falls sich diese Aufgabe mit dem CMS leisten ließe schön. Zur Zeit
> glaube ich eher an eine Lösung mit CVS/SVN und Makefiles, bin aber noch
> auf der Suche.
Falls sich diese Aufgabe *wirklich* mit einem CMS leisten ließe, dann wäre
ich auch bereit einige Nachteile, die es mit sich bringt, zu verschmerzen.
Aber vielleicht *brauchen* wir unbedingt ein CMS, damit die Beteiligten dann
endlich mal mental/psychologisch bereit sind, sich mit den eigentlich
zugrundeliegenden Herausforderungen zu befassen. ;-P
Viele Grüße,
Patrick
...der nicht sieht, daß das Abklappern von einem CMS nach dem anderen uns
bei den inhaltlichen und strukturellen Ungereimtheiten auch nur ansatzweise
irgendwie weiterhilft.
Reply to: