Work in Progress

# Deutsch # english # italiano # francais # nederlands

Technische Umsetzung

This is my idea of fun
Playing video games
Lana del Rey

Ziel und Entscheidungen

Ziel: eine Publikation schaffen, welche für den Autoren umsetzbar ist, das Budget nicht sprengt und ein möglichst großes, aber weitgehend unbekanntes Publikum erreicht. Um anderen Autoren den Weg zu erleichtern, hier eine Zusammenfassung des gewählten Weges, der Fallstricke und der letztendlichen Umsetzung.

Da ich mein Geld mit dem Schreiben von Software und der Beratung über Ihren Einsatz verdiene, verwende ich keine raubkopierte Software. Aber: für alle hier nötigen Aufgaben gibt es kostenfreie Programme. Ich habe mich bevorzugt für Programme entschieden, die Open Source sind, aber auch Closed Source Programme verwendet.

Versions- Control - System

Ein Versionscontrolsystem (VCS) ist ein Programmpakett, welches die Verwaltung von Dateien in unterschiedlichen Versionen unterstützt. Unabdingbar ist ein solches System, wenn mehrere Personen an einem Projekt arbeiten. Aber auch wenn nur eine einzelne Person an einem Text arbeitet, kann es vorkommen, dass ein VCS erheblich Zeit und Nerven spart: scheiße, die Formulierung, die du gestern für diesen Satz hattest, war viel besser. Aber wenn Du jetzt das BackUp von gestern nimmst, sind auch alle anderen Änderungen weg. Dies ist eine typische Situation, in der ein VCS mit wenigen Mausklicks helfen kann. Und die Frage, wo denn das Backup von Gestern eigentlich ist, ist mit einem VCS ebenfalls geklärt: im VCS.

Kurz gesagt ist ein VCS ein ein System, welches automatisch oder auf Auforderung für die Dateien, die es verwaltet, jedesmal dann, wenn es eine Änderung gibt, eine neue Kopie anlegt, und sich merkt, wer diese Kopie wann angelegt hat. Fragen wie: was sind die Unterschiede zwischen der Version die ich gestern "eingescheckt" habe, und derjenigen Version, die der Kollege vor drei Wochen bearbeitet hat, sind mit einem VCS einfach zu beantworten.

Ich habe auf meinem Ubuntu-Heimserver Subversion installiert, und verwende auf meinen Arbeitsrechnern TortoiseSVN als Client. TortoiseSVN kann auch lokale Repositories ohne einen Server verwalten. Alternativen sind das veraltete CVS oder Mercurial.

Die Verwendung eines Versions-Kontrolsystems empfielt sich m.E. für jeden, der mehr gelegentlich am Computer schreibt. Ob Programmcode oder literarische Texte: die Herausvorderungen für den Computer sind die gleichen.

Anfang 2011 habe ich damit begonnen, die Verwendungsdaten in ein LateX Dokument zu überführen. Diese Daten habe ich bis dahin bis dahin in einer OpenDokument Spreadsheet-Datei gehalten. - dass ist eine kostenfreie Variante einer Excel Datei - und wird u.a. von OpenOffice und seinem Ableger LibreOffice erzeugt. Damaliges Ziel war, eine Druckvorlage für ein Buch zu erstellen. Der Katalogteil dieser LaTeX-Fassung kam auf ca. 80 Druckseiten und entsprach im Grundlayout den aktuellen Katalogseiten. Einige dutzend Belege sind für diese LaTeX Fassung eingescannt worden, geplant war, alle Belege auf einer CD dem entstehenden Druckwerk beizulegen. Also habe ich damals schon ein System für die Benennung der Scans entwickelt, welches mir bei der Erstellung der Webseite später sehr entgegen kommen sollte: die Dateinamen beginnen mit dem Ortsnamen des mich interessieren Stempels, gefolgt vom Stempeldatum im ISO-Format. Das ISO Format hat den Vorteil, dass es besser sortierbar ist. Dass dieses Datumsformat ein wenig gewöhnungsbedürftig ist, hebt den Vorteil nicht hinweg.

Ausgehend von 120 Druckseiten - der Handbuchteil war ja noch nicht zusammengestellt, aber im Umfang durch die bereits veröffentlichten Artikel aber abschätzbar, habe ich mir einen Druckkostenvoranschlag machen lassen. Ausgehend von einer verkauften Auflage in der Größe der Mitgliedschaft der Arge Italien, hätte dies einen Selbstkostenpreis von mindestens 30 - 50 Euro bedeutet - mit "Rest"exemplaren für die nächsten 20 Jahre. Eine kostengünstigere Lösung mußte her. Die Idee, einfach die PDF Datei auf CD zu brennen - am besten nur in kleinen Stückzahlen, und bei Bedarf nachzubrennen - wurde schnell verworfen. Wenn schon digital, dann sollten auch die Vorteile des digitalen Mediums genutzt werden.

Hatte ich schon bei meinem Versuch, eine Ausstellungssammlung über die Dani-Maschine damit zu kämpfen, dass ich am liebsten mehrere Erzählstränge parallel erzählt hätte (und dabei vor dem Problem stand, dass dann der gleiche Beleg an verschiedenen Stellen eingeordnet werden kann), war durch den Katalog noch eine weitere Ebene hinzugekommen. Also bot es sich an, eine interaktive Form zu wählen, bei der sich der Leser seinen Erzählstrang selbst zusammenstellt.

Also als ersten Schritt die bestehenden Katalogdaten nach HTML konvertieren. Dies ist mit dem verwendeten LaTeX-Editor (LyX) sogar automatisch möglich. Allerdings bin ich diesen Weg nicht gegangen, sondern habe den HTML Code per Hand geschrieben. Als Editor habe ich Notepad++ verwendet, von den dort für die HTML Codierung vorhandenen Features aber nur das Syntax-Highlighting wirklich verwendet. Wie gut sich die Autovervollständigung dieses Editors wirklich mit HTML auskennt, habe ich nicht probiert.

Für die meisten Philatelisten wird dieser Weg nicht der richtige sein. Er läßt sich m.E. nur dann verfolgen, wenn neben dem philatelistischen Interesse solide Grundkenntnisse der Web-Techniken vorhanden sind, sowie die Möglichkeit/der Wille einen eigenen - lokal auf dem eigenen Rechner reicht - Web-Server für Testzwecke aufzusetzen, und den geschreibenem Code einem Versionscontrolsystem anzuvertrauen.

Waren die letzten Webseiten, die ich gestaltet hatte, noch mit einem "klassischen" "Kopf-Zeile - Menu Links - Fließtext Rechts" Layout erstellt worden, schwebte mir jetzt eine Menuzeile wie in Word vor, wo die Hauptmenueinträge nebeneinander stehen und die Untermenu-Einträge erst bei Bedarf eingeblendet werden. Von den beiden hier gangbaren Wegen: JavaScript und CSS (Cascading Style Sheets) erwies sich CSS als der Weg, den ich gegangen bin. Nach einer kurzen Suche im Internet und einigen schnell hingehackten Codezeilen stand die erste Version des Menus. Gedacht war dieser Versuch hauptsächlich, eine Abschätzung zu gewinnen, welcher Aufwand bei der Wahl von CSS auf mich zukommt. Dass ich hier reletiv schnell zu einem vorläufig ausreichendem Ergebnis kam, hat dazu geführt, dass ich mir die Möglichkeiten Menus mit Javascript zu gestalten, nicht näher angeschaut habe. Denn gegen Javasript sprach auch, dass viele sicherheitsbewußte Surfer Javascript ausgeschaltet haben, während CSS m.W. kein Sicherheitsrisiko darstellt. Die einzige nenneswerte Usergruppe, die CSS standartmäßig "ausschalten", sind Blinde. Diesen kommt die Verwendung von CSS insbesondere - bei strikter Trennung zwischen Inhalt und Darstellung - aber entgegen. So ist es für einen Screenreader oder eine Braile-Zeile sicherlich leichter möglich eine Anweisung wie Hervorheben (z.B. durch eine andere Stimme) umzusetzen als eine Anweisung wie Fettdruck. Und auch "Normalsichtige" tun sich leichter, wenn Hervorhebungen einheitlich gehalten sind und nicht abwechselnd durch Fett- und Kursivdruck geschehen. Dass manche User sich ihre eigenen Stylesheets schreiben und damit die vom Webprogrammierer zur Verfügung gestellten Stylesheets übergehen, mag aus der Sicht eines Designers, der sich Stunden damit auseinandergesetzt hat, ob nun eine 3 Punkte breite rote Linie oder eine 4 Punkte breite grüne besser aussieht, eine Scheiß-Idee sein. Für mich ist dies kein Problem.

Mit der Wahl der Technik für das Menu - andere sagen auch "Site-Navigation" dazu - fiel die Wahl der verwendeten HTML-Version leicht: ich habe micht für XHTML 1.1 entschieden. Die Features, die für HTML 5.0 sprechen, z.b. dass "native Einbinden" von Videos scheinen mir für diese Webseite noch nicht notwendig zu sein. Wenn ich irgenwann mal ein Video über den Einsatz der Bollatrice entdecke, werde ich diese Entscheidung eventuell revidieren. Bis dahin bleibe ich bei meiner Einschätzung - durch eine mehrstündiges Surfen nach Tipps fürs Web-Design gewonnen - dass XHTML 1.1 mit CSS der Standard ist, der von den meisten Browsern am klaglosesten verarbeitet wird. Einzig: um bestimmte, auf jeder Seite vorkommende Elemente nicht jedesmal neu tippen zu müssen - dazu gehören nicht nur das Menu und die Fußzeile - habe ich von Anfang an auf die Verwendung von Server Side Includes (SSI) gesetzt. Dies ist aber keine Frage, welche die Browser unterstützen müssen, sondern die der Webserver - und damit der Provider - unterstützten muß. SSI ist - anders als z.B. PHP kein Sicherheitsrisiko, da es keine dynamischen Inhalte hat, welche der Leser steuern kann. Ein Provider, der aus Sicherheitsgründen SSI nicht unterstützt, aber PHP und MySQL zuläßt, ist m.E. inkompetent.

Philatelisten ohne grundlegende Programmier- und Computerkenntnisse steht - wie oben angedeutet, dieser Weg nicht so leicht offen. Allerdings glaube ich, dass die Kombination (X)HTML, CSS und SSI auch für diesen Personenkreis ein Weg ist, der vergleichsweise wenig Lernaufwand erfordert. Denn für (X)HTML gibt es Editoren die WYSIWYG unterstützen und von der Bedienung weitestgehend an eine Textverarbeitung erinnern. Dass der auf diese Art erzeuigt HTML Code, nicht so flexible und optimiert ist, wie handgeschriebener Code, dürfte sich verschmerzen lassen. Die etwas größeren Dateien - und damit Ladezeiten für die Leser - sind im Vergleich zu dem Aufwand, den ein Content Management System wie Joomla erfordert, zu vernachlässigen. Zwar ist Joomla - und auch einige Alternativen - mit einem Mausklick installiert. Aber um es auf dem neuesten Stand zu halten, bzw. um regelmässig Sicherheitsupdates einzuspielen, ist mehr als ein Klick notwendig. Und gerade bei weit verbreiteten CMS rächt es sich, wenn man eine Version verwendet, in der bekannt Sicherheitslücken sind.

Details der Umsetzung

Das wichtigste Detail der Umsetzung habe ich schon oben erwähnt: ein Namensschema zur Benennung der Bilder (Belege). Wie gesagt, beginnt dieses mit dem Stempelort, es schließt sich das Stempeldatum in der Schreibweise Jahr, Monat, Tag an. Den Vorteil der einfacheren Sortierung hatte ich weiter oben schon erwähnt. An diese Grunddaten schließt sich eine ein- oder zweibuchstabige Klassifizierung des Stempels an.

Aus diesen Informationen zu den einzelnen Stempel erzeuge ich mit einem Python-skript die Grundstruktur der verschiedene Seiten. Vermutlich würde dies auch "online" funktionieren, ich mache dies aber offline und lade die entstehenden Datei auf den Server hoch. Ich halte dynamische Elemente auf dieser Webseite nicht für notwendig.

Zu jeder Bild-Datei gibt es eine Text-Datei, welche die Beschreibungstexte zu dem Beleg enthält. Diese hätte man sicherlich auch in einer Datenbank ablegen können, ich glaube aber so mehr Freiheiten zu haben. Letzlich ist das aber Geschmackssache.

Vervollständigt wird die Webseite durch Text-Dateien für die einzelnen Artikel, die Beschreibungen der Orte und einige technische Dateien für das Menu und die Gestaltung (CSS).

Used tools

Für die maschinenlesbaren Inhaltsverzeichnisse verwende ich G-Mapper (http://www.g-mapper.co.uk). Neben den für Google und andere Suchmaschinen wichtigen sitemap.xml erstellt dieses Programm auch die xml-Dateien für die verschiedenen Aggregatoren (RSS-Feeds).

Xenu Link Sleuth 1.3.8 ist ein Tool, welches die "Verkettungen" zwischen den einzelnen Seiten einer Website überprüft.

Zur Qualitätskontrolle, d.h. ob alle "Tags" richtig geschlossen sind, bietet sich der Validator des W3C an. Dieser hat einen Nachteil, nämlich dass er nur eine Seite analysiert. Der Qualidator schaut sich in der kostenfreien Version mehrere Seiten einer Website an, in einer bezahlten Version analysiert er auch alle Seiten.

Zusammenfassend läßt sich sagen, dass es für die Validation von Webseiten keine rundum befriedigende Lösung gibt. Xenu deckt halbwegs brauchbar ein wichtiges Teilgebiet ab, befriedigt aber nicht 100%. Die anderen Tools in diesem Bereich sind nur Notlösungen.