[Discuss] Neu Webseite

Erich N. Pekarek (spam-protected)
Fr Mai 29 16:13:31 CEST 2015


Hallo!

Am 2015-05-29 um 14:18 schrieb (spam-protected):
> Hallo!
>
> Am 29. Mai 2015 um 14:01 schrieb Adi Kriegisch <(spam-protected)>:
>> Hallo!
>> [... gekürzt ...]
>> 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.
Dann muss ich aber die Gegenfrage stellen, ob die Homepage oder 
veraltete Routerfirmwares die größere Gefahr darstellen - aber das ist 
eine andere Baustelle.
> Also ich finde es ist komplett irelevant, welche Technologien zum
> Einsatz kommen (solange eine moderne responsive Website am Ende dabei
> rauskommt)
Da bin ich absolut Deiner Meinung.
>
> Ich bin der Meinung, dass der größere Brocken an Arbeit
> nicht an auf der technischen, sondern auf der redaktionellen Seite
> liegt. Also regelmäßig aktuell relevante Inhalte auf die Website
Erfahrungsgemäß scheitern Webprojekte bei Vereinen meist daran, dass die 
gar kein dezentrales Publishing wollen, sondern meist -pardon für die 
bewusst provokante Formulierung - "einen Deppen suchen", der ihnen den 
Webmaster macht. Gerade das ist in Vereinen, wo schlecht kommuniziert 
wird, aber das Problem: Am Ende ist der Webmaster der Böse, wenn er 
nicht aktiv alle Infos zusammensucht.

> stellen. Dafür würde es wohl vermutlich auch einen kulturellen Wandel im
> Verein benötigen - Wie schon bei der Generalversammlung gesagt wurde
Ich persönlich bevorzuge ein Redaktionsmodell, bei dem Beiträge von 
(quasi) jedermann beigesteuert, aber vom Herausgeber freigeschaltet 
werden, da dies eher einem aktiven Dialog entspricht, und Wachstum 
ermöglicht. Anfrage - Antwort. Die Gefahr dabei ist, dass sich dann 
wieder niemand zuständig fühlt - aber das ist eh fast immer der Fall.
> (sorry kann mich nicht an den Namen erinnern) - Es wäre sehr
> Vorteilhaft für uns, wenn die von unserer Community erbrachten
> Leistungen nach außen hin sichtbar werden würden!
Full ack!
>
> Insofern ich der Meinung bin, dass aktuell relevante Inhalte das
> wesentlichste auf einer neu aufgelegeten Funkfeuer-Website sind, halte
> ich eine statische Website für wenig Vorteilhaft, das diese deutlich
> schwieriger mit neuen Inhalten befüllbar wären. Natürlich wenn man im
> Hintergrund einen (einfach zu bedienenden) CMS-ähnlichen Generator
> verwenden würde, wäre dieser Einwand wieder irrelevant.
Da bin ich anderer Meinung, da Eingabepunkt und Ausgabepunkt 
divergieren: Damit entsteht wieder der Eindruck einer "geschlossenen 
Gesellschaft".
Ich gestehe ein, dass ich dem Gedanken aber noch nicht konsequent in 
alle Richtungen gefolgt bin. Weiteren Argumenten stehe ich offen gegenüber.
>
>> (...)
>>> Sprechen wir darüber!
>> Super Idee! Was mich betrifft steuere ich gerne meine Bedenken bei,
>> vertrete aber die Auffassung, daß derjenige, der sich der Sache annimmt
>> auch die Entscheidungen zu treffen hat.
> Da sind wir uns einig! Der jenige der sich den Aufwand macht, sollte
> auch das Privileg haben zu entscheiden welche Technologien er dazu
> verwendet.
Das steht ihm freilich zu, jedoch haben wir in der Community sicherlich 
auch brachliegende Kompetenzen. Adis Mail entnehme ich, dass er Etliches 
an Fachwissen beitragen kann.

Man sollte einem Projektleiter der Ehrlichkeit halber auch Alternativen 
aufzeigen, die möglicherweise unbeabsichtigt übersehen wurden:
Schließlich sollte man die Freiwilligen nicht ausnutzen, sondern ihre 
Arbeit dankbar wertschätzen. In diesem Fall würde diese Dankbarkeit sich 
in einer regen Projektbeteiligung, im geringsten Fall in der Akzeptanz 
des Systems im Regelbetrieb, äußern.
Ich kenne mehrere Fälle, in denen Joomla zwar als grundsätzlich "nett" 
empfunden wurde, in der Praxis dann aber nur vom Webmaster allein 
technisch wie inhaltlich gepflegt wurde. Einmal wurde ein Projekt auf 
Basis von Joomla auch als "nettes Spielzeug" bezeichnet. Der Urheber der 
Aussage war Typo3-ianer, der die Website einer Partei gestaltete.

Die bisherigen Bemühungen aller Beteiligten bei allen webbezogenen 
Auftritten des Vereins in Ehren, würde ich mir doch vom Verein und 
seinen Mitgliedern hier eine Richtungsentscheidung im Sinne von "was 
wollen wir eigentlich" wünschen. Gerade beim Aufbau einer 
Web-Visitenkarte sollte eine klare Linie vertreten sein, die nicht 
gewährleistet ist, wenn wir dem meritokratischen Prinzip folgen:
*"Wir sind das Netz" verstehe in diesem Fall so, dass wir alle unsere 
Wünsche gegenüber dem Vorstand äußern, und der Vorstand einen Auftrag 
erteilt, Kompetenzen delegiert und die erforderlichen Mittel (insbes. 
Hosting) zur Umsetzung bereitstellt.*
Bis jetzt sind aber hierzu keine (laut vernehmbaren) Fragen gestellt 
worden. Der Visual Identity Guide gibt schon einmal einen Impuls, 
befasst sich aber nicht mit inhaltlichen Fragen.

Ich mahne vor einer sichtbaren Zersplitterung der diversen Auftritte, 
die die Vielschichtigkeit (aber nicht unbedingt auch die Vielfalt) im 
Verein nach Außen sichtbar machen.
> LG, Thomas
Ich würde gerne die *Diskussion mit ein paar Fragen in eine Richtung 
lenken*, die eine *Weiterentwicklung* und *Zusammenführung* der bisher 
geleisteten *Arbeiten* ermöglich

* Welche Inhalte möchte der Vorstand des Verein überhaupt auf seiner 
Website haben?
* Welche Inhalte möchte die Community dort finden können?
* Welche Inhalte sind für Interessenten vonnöten?
* Welche Inhalte sind als Visitenkarte gegenüber Firmen, Privaten, 
Behörden zu dienen?
* Welche Struktur erscheint für die Präsentation des Inhalts sinnvoll?¹
Z.B.:
*Kontinuität des Auftritts:*
* Ist es sinnvoll als "Funkfeuer Wien" auf der Homepage "Regionen" 
aufzuführen, die mit Wien nichts zu tun haben?
* Inwieweit ist der Begriff "Services" relevant, wenn es sich um 
Vereinseinrichtungen und nicht um (kommerzielle) "Produkte" handelt? - 
was verstehen wir unter Service?
* In wieweit hat das Housing auf der Vereinsseite seine Berechtigung, 
wenn es doch nur als unentbehrlicher Hilfbetrieb für das Mesh dient. Ist 
Housing in weiterer Folge nicht eher ein Service?
* Für das Housing ist eine separate Homepage angedacht (siehe mein 
voriges Mail).

1: Meiner persönlichen Ansicht nach lassen sich die Bereiche wie folgt 
einteilen:

     Vision - Woher kommt Funkfeuer, was tut es, wohin will es.
     Projekt - Konkrete Informationen zur Technik und Umsetzung
     Organisation - Über den Verein, seine Organe und Funktion
     Referenzen - Wer setzt Funkfeuer wofür wie ein, Welche 
Kooperationen mit Firmen und Behörden gibt es. Exemplarische Use Cases.
     Ansprechpartner - Wer ist im Verein wofür zuständig, welche 
Arbeitsgruppen gibt es, ...

Teilbereiche von Projekt, Referenzen und Ansprechpartner sehe ich als 
community-editable an.

     "Services" wie Map, Frontend, Link Budget Calc, ... etc sehe ich im 
Bereich "Projekt" angesiedelt.
     "Housing" wäre ein Link in Projekte
     Die "Gallery" wäre über Projekt angesiedelt, könnte in Referenzen 
verlinkt sein. (Alles? Wohl eher nicht.)
     Die "Regionen" könnten bei Organisation Erwähnung finden. Bei 
Projekt eher nicht, außer es handelt sich um eine gemeinsame 
Projektseite aller Funkfeuer-
     Ableger Österreichs.

Gegenvorschläge und sonstige andere Ansichten sind willkommen!

Mein Fazit: Die konkrete technische Umsetzung ist mir an sich egal, aber 
meiner Meinung nach sollten wir uns über die Voraussetzungen im Klaren 
sein, bevor wir uns mit ihr befassen. Wir haben im Moment ein Projekt 
auf Basis statischen Markups, eines mit Drupal und eines mit Joomla (in 
der zeitlicher Reihenfolge ihrer Entstehung). Hinzu kommen Subprojekte 
wie Forum, Map, Wiki, Newwiki, Galerie u.s.w..
Das statische Projekt entspricht nicht dem VI-Guide und deckt nur einen 
Teilbereich ab. Das Projekt mit Drupal ist ein Vorschlag für mehr 
Struktur und eine Einladung für einen Umstieg von Typo3 auf ein ähnlich 
mächtiges und erweiterbares System, das einfacher zu handhaben ist. Das 
auf Joomla basierende Projekt ist ein Versuch, einen ähnlichen 
Befreiungsschlag in dieser Richtung zu erwirken.

Von der Optik her gefallen mir alle Entwürfe, sie entsprechen aber 
allesamt nicht oder nicht in Details den Vorgaben des VI-Guides, wobei 
Christophers Vorschlag diesem am noch nächsten kommt.

Die Erstellung eines Templates für ein spezifisches CMS ist aber auch 
keine Hexerei - man kann also mit gutem Willen sicherlich eine 
Zusammenführung der bisherigen Vorarbeiten und etwaiger noch 
auftauchender Probleme in Angriff nehmen.

Wenn die Entscheidung auf Christophers Projekt fällt, kann ich 
langjährige Erfahrung mit Joomla (und Mambo) [und dessen Macken] 
beisteuern, wenn dies gewünscht ist. Ich möchte dennoch dazu raten, 
Joomla u.a. wegen seiner inhomogenen Erweiterungskultur und dem 
aktuellen Releasezyklus in diesem konkreten Fall gerade nicht 
einzusetzen - auch, wenn es mit angeblicher Einfachheit lockt. Das 
Schöne an Drupal ist, dass Front- und Backend stärker zusammengewachsen 
sind und Änderungen daher auch für Newbies leicht zu handhaben sind. 
Hinzu kommt, dass die verschiedenen Inhaltstypen den Bedürfnissen 
angepasst werden können, was bislang bei Joomla fehlte. In Sachen 
Rechteverwaltung und automatische Updates hat sich Joomla gemausert, 
jedoch hat auch hier Drupal ein feiner abstufbares Rollen- und 
Rechtemanagement und Updates lassen sich mittels drush auch über die 
Kommandozeile erledigen ('drush upc' und 'drush updb'), was viel Zeit 
spart. Zudem besitzt es ähnlich wie Typo3 eine Möglichkeit zur 
Multi-Domain-Verwaltung (sites), während dies bei Joomla zwar machbar, 
aber immer noch mühsam ist.

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. Danke!

LG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20150529/aa1f226b/attachment.htm>


Mehr Informationen über die Mailingliste Discuss