Hallo!
1. Die kurze Antwort und zugleich die zentrale Frage ist: *Wer für wen
was zu welchem Zweck womit* machen soll.
2. Weiters möchte ich die Frage in den Raum stellen, ob nicht zwischen
*www.funkfeuer.at* und *wien.funkfeuer.at* eine klare Trennung passieren
sollte, denn obwohl Wien Ausgangspunkt der Bewegung war, so ist es heute
nur einer von vielen Schauplätzen mit je eigenen Herangehensweisen.
Diese logische Trennung hätte zur Folge, dass man auf überflüssige und
veraltete Informationen dort leichter verzichten kann.
Ich erwarte mir davon, dass diese bloße "Visitenkarte" im Netz für alle
Abspaltungen in den Bundesländern so auf gleichberechtigte Weise Werbung
macht und Fehlvorstellungen bei Interessenten gar nicht erst aufkommen
lässt.
3. Ausführlicheres zu Punkt 1 als Antwort:
Am 2015-05-29 um 22:44 schrieb Adi Kriegisch:
Hallo!
Ich bin ebenfalls für eine statische Seite. (Wobei mir egal ist, ob da
irgendwo im Hintergrund eine PHP-Anwendung läuft ...)
Der Punkt ist, möglichst wenig PHP-Code laufen zu haben; idealerweise
garkeinen.
Ich gehe davon aus, dass Adi berechtigte Interessen hinsichtlich der
Sicherheit der Seite in den Vordergrund stellt.
Kurz zusammengefasst: unsere Homepage ist statisch; es gibt also keinen
Grund, die Seite bei jedem Aufruf neu zu generieren (PHP CMS).
Der Grund für ein CMS ist also lediglich/hauptsächlich der, den Inhalt
"einfach" bearbeiten zu können und trotzdem ansprechende Webseiten erzeugen
zu können.
Dazu gibt es 2 Varianten:
[...gekürzt...]
Vor der Diskussion um die Technik sollte die Diskussion um die Nutzer
stehen:
*Wer ist die Zielgruppe* für statische Seiten und wer ist die Zielgruppe
für das CMS beziehungsweise, was soll damit erreicht werden - Dazu
stellt sich die Vorfrage nach Anforderungen:
a) Welche *Anforderungen* stellt der *Vorstand* an die Homepage?
u.a.: Welche Informationen, Grad der Aktualität der Informationen,
Nutzerkreis der Informationen bereitstellt, Nutzerkreis der
Administratoren, Zielgruppe für
die Informationen.
b) Welche *Anforderungen* stellt der *Besucher* an die Homepage?
u.a. Übersichtlichkeit, optisch ansprechender Auftritt, gute
Auffindbarkeit von Inhalten - d.h. Material, das seiner Recherche
entspricht, schnelle Ladezeiten,
Befriedigung seiner Erwartungshaltung oder Anregung zur weiteren
Befassung mit dem Thema; gute Kontaktmöglichkeiten.
c) Welche *Anforderungen* stellt die *Community* an die Homepage?
u.a. Information über Vereinsgeschehen, Neuerungen, Planungen,
Bereitstellung von Tools, ...
Von den Antworten hierauf ausgehend kann man die Frage, ob CMS,
Site-Generator oder Plain HTML dafür zweckdienlicher ist, gestellt werden.
Oder auch, ob ein die *Splittung* in ein "*Intranet*" (techn. Infos,
Tools, Interna) und "das *Internet*" (Visitenkarte, Werbung) tunlicher ist?
Wenn im Ergebnis der Wille erkennbar ist, dass der neue Webauftritt aus
einer Willkommensseite, einer Projektvorstellung, einem Impressum mit
Kontaktformular (=unstatisch) und einer Linksammlung (u.a. zu anderen
Communities und zu den diversen Tools, wo die eigentliche Inhalte
stehen) bestehen soll, dann stellt sich gar nicht die Frage nach einem
CMS, weil der Aufwand hierfür auch im Falle, dass es als HTML-Generator
gebraucht wird, übertrieben hoch ist.
Der Verzicht auf interaktive Elemente bei der Homepage bedeutet in der
Signalwirkung aber auch, dass die Mitwirkung der Community an dieser
Stelle unerwünscht ist - was dann legitim ist, wenn die anderen
Beteiligungsformen für sie in den Vordergrund rücken.
Erfahrungsgemäß wird dadurch aber der Zersplitterungsgrad der
Information erhöht und der Aktualitätsgrad vermindert. (Siehe Forum,
siehe wiki, siehe Gallery).
Was meint der gesamte Vorstand dazu? Welche Linie gibt er vor?
Adi würde ich ersuchen, seine Vorschläge für alle jene Diskutanten, die
nichts mit Site-Generatoren oder Versionskontrollsystem am Hut haben,
von der Konzeption her näher auszuführen oder Literatur zu verlinken.
Ein Site-Generator besteht aus 3 Teilen:
* dem Program (Toolkit, zb Pelican: http://blog.getpelican.com/)
* dem Layout (Stil, Icons, ...)
* dem Inhalt
[...]
Naja, der Rest ist einfach: durch aufruf des Programms wird aus dem Layout
und den Textdateien mit den Inhalten eine Webpage erzeugt, die dann von
einem einfachen Webserver ausgeliefert werden kann.
Der spätestens beim Kontaktformular wieder dynamische Inhalte ausliefert
und Eingaben verarbeitet ;-)... SCNR.
Womit abschließend wieder die Frage nach dem Use Case (Wer für wen was
zu welchem Zweck womit machen soll) aufkommt.
lg Adi
LG
Erich
--
Discuss mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/discuss
