<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2015-05-29 um 14:18 schrieb <a class="moz-txt-link-abbreviated" href="mailto:kaefert@gmail.com">kaefert@gmail.com</a>:<br>
</div>
<blockquote
cite="mid:CACDumsS3_O_h7nJUeQ5boZ2eZTXmHFJCzHv3FO-vkoE3pYYCnw@mail.gmail.com"
type="cite">
<pre wrap="">Hallo!
Am 29. Mai 2015 um 14:01 schrieb Adi Kriegisch <a class="moz-txt-link-rfc2396E" href="mailto:adi@kriegisch.at"><adi@kriegisch.at></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Hallo!
[... gekürzt ...]
</pre>
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
Ich gehe davon aus, dass Adi berechtigte Interessen hinsichtlich der
Sicherheit der Seite in den Vordergrund stellt.<br>
Dann muss ich aber die Gegenfrage stellen, ob die Homepage oder
veraltete Routerfirmwares die größere Gefahr darstellen - aber das
ist eine andere Baustelle.<br>
<blockquote
cite="mid:CACDumsS3_O_h7nJUeQ5boZ2eZTXmHFJCzHv3FO-vkoE3pYYCnw@mail.gmail.com"
type="cite">
<pre wrap="">
Also ich finde es ist komplett irelevant, welche Technologien zum
Einsatz kommen (solange eine moderne responsive Website am Ende dabei
rauskommt)</pre>
</blockquote>
Da bin ich absolut Deiner Meinung.<br>
<blockquote
cite="mid:CACDumsS3_O_h7nJUeQ5boZ2eZTXmHFJCzHv3FO-vkoE3pYYCnw@mail.gmail.com"
type="cite">
<pre wrap="">
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
</pre>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CACDumsS3_O_h7nJUeQ5boZ2eZTXmHFJCzHv3FO-vkoE3pYYCnw@mail.gmail.com"
type="cite">
<pre wrap="">stellen. Dafür würde es wohl vermutlich auch einen kulturellen Wandel im
Verein benötigen - Wie schon bei der Generalversammlung gesagt wurde</pre>
</blockquote>
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.
<blockquote
cite="mid:CACDumsS3_O_h7nJUeQ5boZ2eZTXmHFJCzHv3FO-vkoE3pYYCnw@mail.gmail.com"
type="cite">
<pre wrap="">
(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!</pre>
</blockquote>
Full ack!<br>
<blockquote
cite="mid:CACDumsS3_O_h7nJUeQ5boZ2eZTXmHFJCzHv3FO-vkoE3pYYCnw@mail.gmail.com"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
Da bin ich anderer Meinung, da Eingabepunkt und Ausgabepunkt
divergieren: Damit entsteht wieder der Eindruck einer "geschlossenen
Gesellschaft".<br>
Ich gestehe ein, dass ich dem Gedanken aber noch nicht konsequent in
alle Richtungen gefolgt bin. Weiteren Argumenten stehe ich offen
gegenüber.<br>
<blockquote
cite="mid:CACDumsS3_O_h7nJUeQ5boZ2eZTXmHFJCzHv3FO-vkoE3pYYCnw@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">(...)
</pre>
<blockquote type="cite">
<pre wrap="">Sprechen wir darüber!
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Da sind wir uns einig! Der jenige der sich den Aufwand macht, sollte
auch das Privileg haben zu entscheiden welche Technologien er dazu
verwendet.</pre>
</blockquote>
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.<br>
<br>
Man sollte einem Projektleiter der Ehrlichkeit halber auch
Alternativen aufzeigen, die möglicherweise unbeabsichtigt übersehen
wurden:<br>
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.<br>
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.<br>
<br>
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:<br>
<b>"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.</b><br>
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.<br>
<br>
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.<br>
<blockquote
cite="mid:CACDumsS3_O_h7nJUeQ5boZ2eZTXmHFJCzHv3FO-vkoE3pYYCnw@mail.gmail.com"
type="cite">
<pre wrap="">
LG, Thomas
</pre>
</blockquote>
Ich würde gerne die <b>Diskussion mit ein paar Fragen in eine
Richtung lenken</b>, die eine <b>Weiterentwicklung</b> und <b>Zusammenführung</b>
der bisher geleisteten <b>Arbeiten</b> ermöglich<br>
<br>
* Welche Inhalte möchte der Vorstand des Verein überhaupt auf seiner
Website haben?<br>
* Welche Inhalte möchte die Community dort finden können?<br>
* Welche Inhalte sind für Interessenten vonnöten?<br>
* Welche Inhalte sind als Visitenkarte gegenüber Firmen, Privaten,
Behörden zu dienen?<br>
* Welche Struktur erscheint für die Präsentation des Inhalts
sinnvoll?¹<br>
Z.B.:<br>
<b>Kontinuität des Auftritts:</b><br>
* Ist es sinnvoll als "Funkfeuer Wien" auf der Homepage "Regionen"
aufzuführen, die mit Wien nichts zu tun haben?<br>
* Inwieweit ist der Begriff "Services" relevant, wenn es sich um
Vereinseinrichtungen und nicht um (kommerzielle) "Produkte" handelt?
- was verstehen wir unter Service?<br>
* 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?<br>
* Für das Housing ist eine separate Homepage angedacht (siehe mein
voriges Mail).<br>
<br>
1: Meiner persönlichen Ansicht nach lassen sich die Bereiche wie
folgt einteilen:<br>
<br>
Vision - Woher kommt Funkfeuer, was tut es, wohin will es.<br>
Projekt - Konkrete Informationen zur Technik und Umsetzung<br>
Organisation - Über den Verein, seine Organe und Funktion<br>
Referenzen - Wer setzt Funkfeuer wofür wie ein, Welche
Kooperationen mit Firmen und Behörden gibt es. Exemplarische Use
Cases.<br>
Ansprechpartner - Wer ist im Verein wofür zuständig, welche
Arbeitsgruppen gibt es, ...<br>
<br>
Teilbereiche von Projekt, Referenzen und Ansprechpartner sehe ich
als community-editable an.<br>
<br>
"Services" wie Map, Frontend, Link Budget Calc, ... etc sehe ich
im Bereich "Projekt" angesiedelt.<br>
"Housing" wäre ein Link in Projekte<br>
Die "Gallery" wäre über Projekt angesiedelt, könnte in
Referenzen verlinkt sein. (Alles? Wohl eher nicht.)<br>
Die "Regionen" könnten bei Organisation Erwähnung finden. Bei
Projekt eher nicht, außer es handelt sich um eine gemeinsame
Projektseite aller Funkfeuer- <br>
Ableger Österreichs.<br>
<br>
Gegenvorschläge und sonstige andere Ansichten sind willkommen!<br>
<br>
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..<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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!<br>
<br>
LG<br>
Erich<br>
</body>
</html>