<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>