Dr. O. Hoffmann
Die beste Methode, um Informationen zu bekommen,
ist die, selbst welche zu geben.
Niccoló Machiavelli
2003-04-24/29, 2003-05-11, 2005-03-04, 2007-12-14, 2008-05-15, 2015-03-09, 2015-05-01
Das internet wird getragen von einem Grundgedanken, freie Information von allen für alle zur Verfügung zu stellen.
Wem das nichts sagt, der wird an diesem Artikel nicht viel Freude haben
und ist im internet auch irgendwie fehl am Platze.
Um so erschütternder sind zahlreiche angeblich professionell gestaltete internet-Projekte,
die von geradezu unglaublicher Naivität im Umgang mit diesem Medium zeugen.
Wie ein Ansporn zum klaren Denken immer ein paar Worte wert ist,
so fordern diese abschreckenden Beispiele geradezu,
einige fundamentale Grundsätze zur praktischen Umsetzung von guten internet-Projekten auf den Punkt zu bringen.
Wie kommt es also, daß an sich sehr kreatives Köpfe und gute Designer, die sich teilweise sogar explizit webdesigner nennen, bei internet-Projekten oft so kläglich versagen?
Nun, das liegt an einigen Besonderheiten des Mediums, mit denen sich jeder sorgfältig auseinandersetzen muß, der ein Projekt wirklich gekonnt umsetzen will. Viele Designer hängen aber wie gehabt am klassischen Modell vergangener Jahrhunderte, wo man Information immer auf ein endliches Stück Papier bekannter Größe druckte. Den Inhalt an solche Abmaße anzupassen, hat sich offensichtlich tief in das Denken von Designern eingebrannt.
Ein anderer Typ von Mensch ist der Programmierer. Dieser hängt sehr einer seiner programmatischen Herangehensweise und will Inhalte immer dynamisch und massiv interaktiv anbieten. Als Basiszugang zu digitaler (Text-)Information ist das aber weder notwendig noch sinnvoll. Der programmatische Zugang zu Information eignet sich eher als alternativer Zugang zum eigentlichen Inhalt, nicht als ausschließlicher Zugang.
Die klassischen Medien wie Bücher, Zeitschriften, Werbeplakate, Prospekte, Poster,
aber auch Ge- und Verbrauchsgüter sind dem späteren Nutzer praktisch direkt und unmittelbar zugänglich -
er kann sie anfassen, ansehen und unmittelbar erfassen ohne weitere Hilfsmittel außer seinen eigenen Sinnen.
Digitale Informationen werden aber immer erst über Hilfsmittel zugänglich
- im Falle von internet-Projekten ist das in erster Linie der
browser
des Nutzers, der die Informationen optisch (oder akustisch) vermittelt, allgemein auch das Darstellungsprogramm.
Während es bei klassischen Medien im Prinzip egal ist, wie das Projekt technisch umgesetzt wird,
ist dies bei internet-Projekten von zentraler Bedeutung, weil davon abhängt,
ob der Betrachter die Information überhaupt vermittelt bekommt.
Wird eine dem Darstellungsprogramm unbekannte Technik verwendet oder stellt dieser das Projekt anders dar,
als bei der Erstellung erwartet, ist die ganze Arbeit vergeblich gewesen.
So muß der Ersteller eines Projektes nicht nur genaue Kenntnis über die Werkzeuge haben,
mit denen er die Daten erzeugt, sondern viel wichtiger - er muß detailliert darüber informiert sein,
ob und wie die Daten nachher vom Darstellungsprogramm präsentiert werden und zugänglich gemacht werden.
Im Gegensatz zu Medien wie Fernsehen, Video oder Musik-CDs ist dem
Anbieter der Information auch gar nicht genau bekannt,
welche Fähigkeiten das Darstellungsprogrammes des späteren Nutzers haben wird und
welches Darstellungsprogramm eingesetzt werden wird, um die Information zugänglich zu machen.
Ja es wird technisch nicht einmal möglich sein, daß alle Nutzer das gleiche Darstellungsprogramm
mit den gleichen technischen Möglichkeiten benutzen.
So sind auch Erfahrungen wie "Neunzig Prozent der Besucher nutzen den browser -wasweißich-"
nicht wirklich nützlich, da am Darstellungsprogramm mannigfaltige Voreinstellungen getätigt werden können,
die die Eigenschaften des Darstellungsprogrammes verändern können.
Die Situation kann zudem Monate später schon wieder deutlich anders aussehen.
Und der Minderheit kann es technisch gar nicht möglich sein, das Darstellungsprogramm der Mehrheit zu verwenden -
oder es gibt aus den verschiedensten Gründen Vorbehalte gegen das
Darstellungsprogramm (zum Beispiel Sicherheitsfragen, Firmenphilosophie des Anbieters,
Anschaffungskosten, rechtliche Probleme).
Selbst wenn also neunzig Prozent die Informationen vermittelt bekommen können,
so liegt das Scheitern gerade in den zehn Prozent, wo das nicht möglich ist, denn das Ziel ist ja,
Information für alle anzubieten.
Unter diese zehn Prozent fallen oft auch Behinderte, vor allem Sehbehinderte, die im internet eine neue Welt vorfinden,
in der sie an sich gegenüber Nichtbehinderten nicht benachteiligt sind.
In diese Welt wird meist mit textbasierten Darstellungsprogrammen aufgebrochen,
die die Information dann geeignet für den Nutzer umsetzen -
es sei denn natürlich, bei der Projekterstellung werden durch exotische Methoden wieder Barrieren aufgebaut,
die für das einfache Text-Darstellungsprogramm und damit auch für den Behinderten unüberwindlich werden.
Letztlich ist die neunzig-Prozent-Einstellung ähnlich asozial wie die eines Geschäftsmannes,
der an die Tür seines Geschäftes ein Schild mit der Aufschrift hängt:
"Wir bedienen keine Juden - und Behinderte auch nicht".
Was also ist zu tun? - die Lösung kann nur sein, die zentralen Informationen und Funktionen des Projektes in einem standardisierten Format anzubieten.
Um entscheiden zu können, welche Methoden für welchen Zweck eingesetzt werden sollten oder sinnvoll eingesetzt werden können,
ist es nützlich sich anzusehen, aus welchen Komponenten ein internet-Projekt besteht.
Wieder gibt es einen gravierenden Unterschied zu klassischen Medien,
deren Aufbau und Zusammensetzung für den Benutzer meist intuitiv klar ist -
zum Beispiel ist bei einem Buch jedem Benutzer klar, wie er von einem Inhaltsteil technisch zum nächsten gelangt -
er blättert eine Seite um.
Bei einem internet-Projekt ist das nicht so einfach.
Es setzt sich aus folgenden Komponenten zusammen:
Technische Komponenten sind zum Beispiel Methoden, mit denen Nutzer identifiziert werden oder statistisch erfaßt werden.
Das ist auch die Anbindung an Datenbanken oder die dynamische Erzeugung von anderen Komponenten
oder die Verarbeitung von Formularen.
Diese technischen Bestandteile sind für den Nutzer idealer Weise gar nicht sichtbar,
sondern nur für den Betreiber des Projektes - oder es sind Methoden, die Komponenten erzeugen,
welche dann erst das Darstellungsprogramm des Nutzers verstehen muß.
Bei funktionellen Komponenten handelt es sich zum Beispiel um das Impressum,
Kontaktformulare, Angabe einer
Kontakt-email-Adresse etc.
Wenn diese Komponenten nicht garantiert funktionieren, wird ihr Zweck nicht erfüllt.
Möchte etwa jemand per email oder Formular einen Fehler oder technischen Mangel melden,
kann dieses aber eben wegen eines solchen Mangels nicht,
so ist zweifellos die kommunikative Katastrophe perfekt und der Seitenersteller wird nie erfahren,
wo sein Projekt komplett versagt.
Kontaktmöglichkeiten müssen natürlich auch unmittelbar und problemlos zugänglich sein.
Insbesondere bei kommerziellen Projekten können technische Mängel bei Kontaktformularen bereits teuer werden
- wenn nicht einmal die internet-Seite richtig funktioniert, welcher Kunde wird da noch Vertrauen fassen?
Und dann gibt es noch Gesetze und Verordnungen, die zumindest für Deutschland vorschreiben,
daß ein Impressum unmittelbar lesbar sein muß, was darauf hinausläuft, daß dieses in reinem
(X)HTML
erstellt werden muß, ohne jeden sonstigen Schnickschnack und gut sichtbar mit dem Rest des Projektes verbunden ist,
entweder direkt auf jeder Seite drauf oder aber durch einen einfachen (X)HTML-Verweis
mit dem Projekt gut sichtbar verknüpft.
Anzeigeprobleme können hier bereits empfindliche Geldstrafen nach sich ziehen, sei es, daß
java-script
oder andere plugins notwendig wären,
um das Impressum sehen zu können oder auch nur so viele Fehler auf der Seite sind,
daß diese nicht mehr mit jedem Darstellungsprogramm anzeigbar ist.
Ebenso wichtig ist das garantierte Funktionieren einer weiteren funktionellen Komponente, der Navigation oder des Menüs eines Projektes. Diese Komponente macht ja gerade erst den Inhalt eines Projektes zugänglich, wenn die nicht sicher und bei jedem Nutzer funktioniert, ist der Sinn und Zweck des kompletten Projektes in Frage gestellt - darum ist auch hier besondere Sorgfalt notwendig.
Die zentrale Komponente des Projektes ist der Inhalt, das Thema. Das ist der eigentliche Zweck des Projektes, die Existenzberechtigung - das, was der Nutzer an dieser Stelle entweder von sich aus zu finden hofft, oder das, was ihm näher gebracht werden soll. Ein Defizit hier sorgt sicher dafür, daß das Projekt vom Nutzer schnell wieder verlassen wird.
Eine weitere Komponente ist die Dekoration oder das Design.
Damit kann es gelingen, mehr Aufmerksamkeit für das Projekt zu gewinnen,
den Inhalt in seiner Aussagekraft zu unterstützen und eventuell das Projekt für den Nutzer intuitiv verständlicher zu strukturieren.
Auch wenn oft versucht wird, durch spektakuläres Design inhaltliche Defizite zu verbergen,
so kann dies den Besucher natürlich nur kurzfristig blenden,
so daß dieser sich schließlich ge- und enttäuscht abwenden wird.
Insgesamt hat es wenig Zweck, sich nur auf eine Komponente zu konzentrieren, vielmehr kommt es auf eine geschickte Kombination aller Komponenten an, um maximale Wirkung zu erzielen. Schwerpunkt ist aber natürlich immer der Inhalt und der Zugang für alle zum Inhalt.
Während bei der Wahl des Inhaltes eigentlich weitgehend Freiheit besteht -
der Initiator des Projektes sollte es natürlich mit möglichst originärem Inhalt versuchen,
der nicht schon an zig anderen Stellen gleichwertig oder besser zu finden ist,
sind funktionelle Komponenten stark dadurch festgelegt,
daß der Nutzer später dadurch einen möglichst intuitiven und logisch nachvollziehbaren Zugang zum Inhalt bekommen sollte.
Das Design, die Dekoration ist allerdings immer eine Frage des Geschmackes,
sollte sich aber letztlich dem eigentlichen Zweck des Projektes unterordnen.
Ergonomisches Design wird vom Nutzer geliebt werden.
Es sei denn, Thema des Projektes ist gerade das Rätseln und Irren in einem Labyrinth.
Welche Mittel zur Umsetzung eines Projektes eingesetzt werden sollen oder
welche optimal sind, um den vorgesehenen Zweck zu erfüllen,
hängt hauptsächlich davon ab, welche Komponenten damit realisiert werden sollen - und welche Inhalte angeboten werden.
Die eingesetzten Mittel sind sehr kritisch auszuwählen, weil von ihnen die Funktion der Seite abhängt -
damit diese sichergestellt ist, ist es wichtig, auf standardisierte Methoden zurückzugreifen und auf weit verbreitete Formate.
Gehen wir vom derzeitigen Stand (2015) der Dinge aus, so ist
XHTML das Basismittel zur Umsetzung eines Projektes.
XHTML ist von der Struktur her deutlich einfacher als HTML,
daher einfacher von deutlich mehr Programmen zu interpretieren.
HTML ist letztlich eine historisch bedingte Sackgasse, welche allerdings von etablierten Anbietern von
Darstellungsprogrammen protegiert wird, um die eigenen Machtpositionen zu sichern
und neue Anbieter durch ein unnötig komplexes Format gezielt zu behindern.
HTML ist etwas älter als XHTML,
wurde aber letztlich nie von den Entwicklern von Darstellungsprogrammen komplett und korrekt implementiert.
XHTML ist von der Struktur und Technik her deutlich ausgereifter und einfacher von Programmen zu analysieren,
ist daher mittlerweile aufgrund der besseren Zugänglichkeit zum Inhalt der veralteten HTML-Syntax vorzuziehen.
Diese Dokumentbeschreibungssprache (X)HTML
wird zusammen mit dem HTTP
(siehe: »Hypertext Transfer Protokoll)
dem späteren Nutzer des Angebotes die Textinformation im Klartext liefern.
Die digitale Kodierung des Klartextes erfolgt gemäß einer Erweiterung des ASCII beziehungsweise ANSI, siehe zum Beispiel bei »selfhtml). Eine Erweiterung allerdings mit der gleichen Kodierung der Grundzeichen sind UTF (meist -8, selten -16) und einige ISO-Kodierungen. Sofern es keine Altlasten in anderen Kodierungen gibt, ist heute UTF-8 die Kodierung der Wahl und bereitet sowohl Autoren als auch Darstellungsprogrammen am wenigsten Probleme und ist auch für XHTML als Standardkodierung vorgesehen, sofern keine expliziten anderen Kodierungsinformationen vorgenommen werden.
Der HTTP- und (X)HTML-Standard wird festgelegt durch eine Organisation:
W3C
(siehe: »World Wide Web Consortium)).
Verschlüsselte Formate, die sich nur für ein bestimmtes
Betriebssystem eignen oder nur für bestimmte Programme, sind hingegen ungeeignet, weil nicht bekannt ist,
mit welchem Betriebssystem und welchen Programmen die Daten abgerufen werden.
UTF-8-kodierter Klartext kann dagegen von jedem System interpretiert werden.
Dies ist auch ein großer Vorteil bei der Datenarchivierung,
da andere Kodierungen als Klartext in der Regel in wenigen Jahren veraltet sind
und mit den dann aktuellen Programmen nicht mehr lesbar.
Die (X)HTML-Standards (HTML4.01, XHTML1.0, XHTML1.1 etc) sind insofern recht unkritisch,
weil man Dokumente in diesem Format notfalls auch ohne spezielles Darstellungsprogramm lesen kann
und zum großen Teil auch von Programmen, die nur einen älteren Standard kennen, interpretiert werden können.
Das relativ neue HTML5 hat sowohl eine sicherlich vorzuziehende Variante mit XHTML-Syntax
als auch eine mit eigener eigenen Syntax (auch oft Markierungssuppe genannt), welche weder mit der XHTML-Syntax
noch er HTML4.01-Syntax kompatibel ist und deswegen als problematisch abzulehnen ist.
Ein anderes formales Problem von HTML5 ist, daß diese Version keine Struktur aufweist,
um überhaupt anzugeben, daß man diese Version in einem Dokument verwendet,
was diese Version leider für Dokumente mit definierter Bedeutung disqualifiziert,
ein grober, aber beabsichtigter Mangel bei dieser Version.
Bei Bildern ist die Auswahl der Methoden bereits etwas kritischer. W3C-Standards gibt es zum Beispiel für die Formate SVG (»Scalable Vector Graphics, Vektorgraphik, Klartext-Format!) und PNG (»Portable Network Graphics, Pixelgraphik, Digitalbilder und Computergraphik). Insbesondere bei der Pixelgraphik ist es wegen der großen Datenmengen notwendig, Kompressionsverfahren anzuwenden. Das Problem dieser Formate ist, daß sehr alte Darstellungsprogramme hier Implementierungslücken aufweisen können. Der große Vorteil besonders bei SVG liegt allerdings darin, daß man damit sehr gut Zugänglichkeitshilfen für Graphik einbauen kann.
PNG funktioniert bei aktuellen Programmen mit graphischen Darstellungsmöglichkeiten praktisch durchgängig und SVG ist zumindest bei technisch aktuellen Versionen von Programmen, die auf dem aktuellen Stand der Technik sind, teilweise implementiert, für viele Anwendungen ist der Umfang ausreichend.
Seit Jahren etabliert ist im Bereich der Pixelgraphik das
JPEG-Format
(auch jpg, Joint Photographic Experts Group,
»JPG bei W3C
und »JPG bei JPEG, Pixelgraphik,
besonders für Bilder von Digitalkameras und Zeilenrasterer), welches ebenfalls standardisiert ist.
Etwas ins Zwielicht gerückt ist wegen einiger Lizenzquerelen das ebenfalls stark verbreitete
GIF-Format
(»Graphics Interchange Format,
Pixelgraphik, besonders für Computergraphik).
Beim Einsatz von Graphik ist also ein Kompromiß zwischen diesen vier Formaten zu finden,
welcher dem Inhalt und dem erwarteten Besuchertyp des Projektes anzupassen ist.
(X)HTML bietet auch die Möglichkeit eines Alternativtextes,
mit dem der Inhalt des Bildes grob beschrieben werden kann,
auch wenn das Bild selbst nicht angezeigt werden kann (es gibt auch Programme,
die Bilder prinzipiell nicht darstellen und bei jedem Programm gibt es die Möglichkeit, die Bildanzeige abzuschalten,
vor allem, um die Ladezeit von internet-Seiten zu verkürzen).
Für technische Komponenten sollte komplett auf server-seitige Methoden zurückgegriffen werden. Ob zum Beispiel die XHTML-Ausgabe mit »PHP erzeugt wird oder mit CGI-Skripten oder einfach als Text-Dateien auf dem server (Dienstrechner) liegen, kann dem Nutzer der Seite egal sein, weil dieser von der Technik der Erzeugung der XHTML-Ausgabe gar nichts wissen muß. Ähnliches gilt für die Formularverarbeitung, Datenbanken, Besucherstatistiken - hier hat der Ersteller des Projektes völlige Wahlfreiheit, solange die Methoden komplett server-seitig ablaufen.
Nehmen wir etwa einen Besucherzähler, der auf java-script zurückgreift, so handelt es sich um eine sehr schlechte technische Umsetzung, weil java-script auf dem Rechner des Nutzers durchgeführt wird - oder eben auch nicht, worauf der Ersteller des Projektes keinen Einfluß hat. Auch Zähler, die mit Bildern arbeiten, sind für eine zuverlässige Statistik ungeeignet, weil nicht jeder Nutzer alle Bilder aufruft. Ähnlich schlecht hinsichtlich der Zugänglichkeit und Nutzbarkeit ist auch eine java-script-Anwendung, die AJAX, zumindest sofern damit für den Nutzer relevante Inhalte verändert oder verfügbar gemacht werden sollen, was natürlich ohne anwenderseitige Skriptausführung nicht funktionieren wird.
Benutzeridentifikation mit cookies ist ebenfalls problematisch, wie bei java-script handelt es sich um einen optionalen Zusatz, es ist keine server-seitige Technik und ist vom Nutzer leicht manipulierbar. Das Funktionieren des Projektes jedenfalls sollte nicht von ihnen abhängen. Als Zusatz zu einem unabhängig davon funktionierenden Projekt kann die Methode aber recht nützlich sein.
Da funktionelle Komponenten beim Nutzer auf jeden Fall funktionieren müssen, gibt es hier fast gar keine Wahlfreiheit -
die Komponenten müssen daher praktisch mit reinem XHTML realisiert werden.
Früher hätte man empfohlen, nur die Schnittmenge aller (X)HTML-Standards als Befehlssatz
für funktionelle Komponenten zu wählen.
Mittlerweile gibt es allerdings so viele Versionen und Programme, das es sinnvoller ist,
XHTML korrekt zu verwenden, statt sich auf HTML-Markierungssuppe einzulassen,
die prinzipiell nur sehr wenige Programme mehr oder weniger korrekt interpretieren können.
Die allgemeine Zugänglichkeit zur Information ist mit dem deutlich einfacheren XHTML
besser gewährleistet.
Daraus ergibt sich aber auch, daß zum Beispiel java-script
(»Netscape),
java
(»Sun)
oder SWF (shockwave flash,
»Macromedia,
neuerdings Adobe) wiederum für diese Anwendung komplett ungeeignet sind.
All diese Methoden laufen anwenderseitig, verlangen im Darstellungsprogramm plugins,
die beim Nutzer gar nicht vorhanden oder aktiviert sein müssen.
Ferner gibt es diese Methoden in zahllosen verschiedenen Versionen und Varianten,
da all diese Methoden keinem Standard folgen und teilweise nicht einmal über einen offengelegten Quelltext verfügen,
mit dem damit erstellte Komponenten nachvollzogen werden könnten.
Auch sogenannte Intros (Startseiten), die mit solch kritischen und ungeeigneten Formaten erstellt werden,
sind reiner Unfug, so lange nicht eine reine XHTML-Variante als Alternative bereitgestellt wird.
Menüs werden auch gerne mit Bildern gestaltet - das ist insofern auch recht unproblematisch,
als das Einbinden von Bildformaten zum XHTML-Standard gehört.
Insbesondere wenn die Bilder mit sinnvollen Alternativtexten versehen sind,
sollte es keine Probleme geben, selbst wenn die Bilder gar nicht angezeigt werden.
Da für verschiedene Nutzer allerdings verschiedene Schriftgrößen optimal sind,
sollte in solch Bildern enthaltene Textinformation mit der voreingestellten Schriftgröße mitskalieren,
was in der Praxis für den Autor allerdings so schwierig sein kann, daß Bilder in Menüs wieder unpraktikabel werden.
Bei Vektorgraphik kann man indessen das Bild problemlos so weit skalieren, daß Text immer lesbar ist.
Wegen des fehlenden automatischen Zeilenumbruches empfiehlt sich das allerdings nicht für lange Texte.
Die Methoden für den Inhalt hängen stark vom darzustellenden Inhalt ab. Um so schwieriger ist die Auswahl. Als Leitfaden kann gelten, daß immer das am besten standardisierte und am leichtesten unabhängig zu implementierende und das verbreitetste Mittel zum Einsatz kommen sollte. Einem proprietären, firmenspezifischen Format ist also immer der Standard vorzuziehen, also auf jeden Fall eher SVG statt SWF. Da ein XML-Format wie XHTML einfacher zu implementieren ist als HTML-Markierungssuppe, ist XHTML dem HTML eindeutig vorzuziehen. XHTML ist wiederum weiter verbreitet als etwa DocBook, daher diesem vorzuziehen, wenngleich XHTML von der Elementkollektion her deutlich armseliger ist, mittlerweile gibt es allerdings Erweiterungen.
Basis-Methode ist somit wieder XHTML und die genannten Bildformate. Aber es gibt vielleicht auch noch wenige Inhalte, die nur mit speziellen Methoden wie java oder SWF realisiert werden können - obgleich da inzwischen auch Standardmethoden von W3C als Alternativen zur Verfügung stehen dürften oder zumindest in Vorbereitung sind. Zum Beispiel gibt es auch Standards für dynamische Effekte (Animationen, Audio, Video, »SMIL). Aufgrund von Patent- und Lizenzproblemen sind allerdings andere Multimediaformate immer noch ein Problembereich des internets und auch immer wieder ein Grund, warum Anbieter immer wieder neue Audio- und Videoformate mit kosmetischen Änderungen anbieten, deren Patente sie dann selber halten, die von anderen Programmen aber nur schlecht interpretierbar sind und daher oftmals nicht sonderlich für das internet geeignet. Eine weitere schlechte Mode ist es, Audio und Video mit speziellen SWF-Unterformaten innerhalb dieses Formates anzubieten, wobei die Unterformate wiederum alleine von anderen Programmen kaum interpretiert werden, also auch wieder eine schlechte allgemeine Eignung aufweisen. Ein vermutlich patentfreies Format Ogg eignet sich sowohl für Audio und Video, dank unübersichtlicher Patentgesetze in den USA fürchten einige Anbieter aber nach wie vor, daß bei einer breiten Implementierung doch noch irgendwelche Leute auftauchen könnten, die im Nachhinein Patente hervorzaubern könnten. Dabei ist unklar, ob dies nur eine Schutzbehauptung ist oder eine realistische Gefahr, weswegen sich auch dieses Container-Format noch nicht durchgesetzt hat.
Wichtige nicht-Standard Methoden für fest formatierten Text,
Vektorgraphik und Pixelgraphik sind die Formate
PS
(»postscript)
und PDF
(»portable document format) der Firma adobe.
Von der Idee her ist PS den Formaten XHTML und SVG durchaus verwandt.
Es handelt sich, was Text und Vektorgraphik anbelangt, ebenfalls um Klartext,
der ebenso unmittelbar gelesen werden kann wie auch von darstellenden Programmen oder Druckern interpretiert.
PDF weist von den Funktionen her noch mehr Ähnlichkeit mit (X)HTML auf,
ist aber kein Klartextformat mehr, die Daten sind meist komprimiert und verschlüsselt.
Zur Datenkompression gibt es aber eigentlich andere Standards oder Quasistandards, zumindest was Klartext angeht.
Der Einsatz dieser beiden Methoden ist vor allem dann angebracht,
wenn großen Mengen Text (und Graphik) fest formatiert und zum direkten Ausdruck geeignet angeboten werden sollen.
Insbesondere bei wissenschaftlichen Arbeiten mit der Notwendigkeit von
umfangreicherem Formelsatz sind PS/PDF
dem XHTML (in Kombination mit dem dafür gedachten
MathML) leider immer noch klar überlegen,
sowohl in der praktischem Umsetzung mit Hilfe der Sprache LaTex,
als auch hinsichtlich der zuverlässigen visuellen Präsentation von Formeln.
Hinsichtlich der Zugänglichkeit zu Information für nicht visuelle Darstellungen,
dürfte die Kombination von XHTML mit MathML
allerdings formal die bessere Wahl sein.
Von der Idee her ist PS dem PDF vorzuziehen.
Weiter verbreitet scheint inzwischen das etwas jüngere
und vom Funktionsumfang zudem vereinfachte PDF zu sein.
Einen Haken haben inzwischen beide Formate: Offenbar gibt es zahlreiche Versionen,
teilweise offenbar auch sehr nah an bestimmte Betriebssysteme angelehnt,
so daß es beim Nutzer wieder zu den bereits angesprochenen Interpretationsproblemen
der eingesetzten Programme einer anderen Version kommen kann.
Einmal mehr zeigt sich der gravierende Nachteil, wenn ein Format nicht von einer unabhängigen
Organisation standardisiert ist, sondern den kommerziellen Interessen einer Firma
oder verschiedener Gruppen unterworfen ist.
Da man immerhin mit den gängigen Darstellungsprogrammen auch geeignet gut strukturierte
(X)HTML-Dokumente gut drucken kann, ist von daher PDF
weitgehend redundant.
Sogenannte frames sind eine besondere Funktion von HTML4,
die so nur in diesem speziellen Standard vorkommt - eigentlich nur ein Kompromiß mit jahrelanger Praxis.
Fernab vom HTML3.2 Standard hat diese Funktion einst die Firma netscape eingeführt,
so daß es zu dieser Funktion vom Standard abweichende Schreibweisen gibt,
die als historische Altlast diese Funktion auch noch belastet.
Da diese Funktion aber sehr praktisch war, als server-seitige Skriptsprachen noch nicht im allgemeinen Gebrauch waren,
erfreute sie sich allgemeiner Beliebtheit
und hat schließlich auch Eingang in den HTML4-Standard (transitional, nicht strict) gefunden.
Problematisch ist die Methode in der Hinsicht, daß Darstellungsprogramme, die den
HTML4-strict-Standard oder XHTML interpretieren oder auch Mobiltelephone,
die das reduzierte XHTML-basic-Profil verstehen, sowie auch textbasierte Darstellungsprogramme,
frames gar nicht darstellen werden.
iframes, eine Variante, die auf die Firma microsoft zurückzuführen ist,
wird sogar von noch weniger alten Darstellungsprogrammen interpretiert, von aktuellen durchgehend.
Daraus sollte der Ersteller eines Projektes den Schluß ziehen,
so weit möglich ganz auf frames zu verzichten
oder eine typische Möglichkeit von (X)HTML ausgiebig zu nutzen,
Alternativen anzubieten (noframes-Bereiche).
Ein weiteres Problem von frames ist, daß sich bei ihnen die
Komponenten Funktion, Technik und Design auf unerfreuliche Weise vermischen und verwischen,
was wieder zu Darstellungsproblemen führen kann -
ein ungeschickter frame-Aufbau kann die Anzeige von Elementen gar unterbinden.
Insbesondere für den unerfahrenen Projektersteller lauert hier die Gefahr,
Komponenten seines Projektes nicht mehr logisch voneinander trennen zu können und so zu scheitern.
Aufgrund der Historie von frames ist die Umsetzung dieser Funktion immer noch uneinheitlich.
Es darf aber nicht verschwiegen werden: Insbesondere wo server-seitige
Techniken wie SSI oder PHP nicht möglich sind,
kann eine Menüstruktur mit frames insbesondere bei größeren Projekten erst praktikabel werden.
Im übrigen, zumal es frames in der strict-Varianten und in XHTML1.1 gar nicht gibt,
sollte auf einen recht eleganten und verallgemeinerten Ersatz hingewiesen werden,
der recht ähnliche Funktionen übernehmen kann - dabei handelt es sich um das object-Element,
mit dem im Prinzip beliebige Dateien in XHTML-Seiten integriert werden können -
insbesondere auch andere XHTML-Dateien.
Auch java ist eine weit verbreitete nicht-Standard-Methode. Es dient vor allem dazu, auf dem Rechner des Nutzers sehr rechenintensive Prozesse realisieren zu können, die so nicht das internet belasten. So können recht elegant dynamische Prozesse berechnet und dargestellt werden, die auch interaktiv vom Nutzer gesteuert werden können. Da es für den Nutzer immer ein Sicherheitsrisiko ist, ihm unbekannte fremde Programme auf seinem Rechner ausführen zu lassen, sollte es selbstverständlich sein, daß er die unbedingte Notwendigkeit des Einsatzes dieser Methode nachvollziehen kann, sonst wird er dieses plugin seines Darstellungsprogrammes gar nicht erst aktivieren.
Deutlich sichtbar wird an diesen Beispielen, daß bei der konkreten Umsetzung eines Projektes immer wieder sinnvolle Kompromisse geschlossen werden müssen zwischen dem, was an besonderen Methoden unbedingt notwendig ist und dem, was mit Standards für den Nutzer problemloser interpretierbar ist.
Am spannendsten ist vielleicht die Auswahl geeigneter Methoden, die das Design betreffen.
Das liegt vor allem daran, daß Designkomponenten nicht in Konflikt mit funktionalen
oder inhaltlichen Komponenten kommen dürfen.
In diesem Zusammenhang kommt das sogenannten Schichtenmodell zum tragen.
Dabei wird der Inhalt von der Dekoration getrennt.
Dazu wird zunächst der Inhalt komplett und mit voller Funktion mit XHTML realisiert.
Dies muß dann komplett und sinnvoll ohne weiteres Design funktionieren und den erwünschten Sinn ergeben.
In einer zweiten Schicht wird das Design mit vom Inhalt getrennten Stilvorlagen ergänzt.
Dieses Design bietet dann also alternative Präsentationen zum Inhalt,
zusätzlich zur Basispräsentation, welche immer noch mit dem undekorierten XHTML verfügbar ist,
wenn die Interpretation der Stilvorlagen deaktiviert wird.
In einer weiteren Schicht können dann weitere, insbesondere dynamische Alternativen und Dekorationen,
andere Zugänge zum Inhalt mit java-script über das DOM angeboten werden.
Der Trick liegt nun darin, daß egal ob die Interpretation von Stilvorlagen aktiviert ist oder nicht und egal,
ob die Interpretation von java-script aktiviert ist oder nicht,
der mit XHTML realisierte Inhalt immer komplett zugänglich bleibt.
W3C bietet mit CSS (»cascading style sheet) ebenfalls einen Standard an, der vor allem der Textformatierung in (X)HTML dient, allgemeiner dem Layout von (X)HTML-Seiten. Inzwischen ist der Einsatz dieser Methoden weit verbreitet. Als Ersteller eines Projektes sollte man jedoch zwei Probleme beachten - zum einen ist die Umsetzung und Unterstützung dieser Standards bei alten Darstellungsprogrammen noch recht uneinheitlich - viele ältere Darstellungsprogramme interpretieren CSS2 etwa nur teilweise. CSS3 ist noch in der Entwicklung, einzelne Module werden von technisch aktuellen Darstellungsprogrammen aber bereits interpretiert.
Zum anderen bietet CSS so viele Formatierungsmöglichkeiten, daß damit - auch unbeabsichtigt - viel Unfug getrieben werden kann, der bei verschiedenen Darstellungsprogrammen zu argen Problemen bei der Anzeige des Layouts führen kann. Um hierbei ansehnliche Design-Resultate zu erzielen, ist es nicht zu umgehen, das Design mit den verschiedensten Darstellungsprogrammen, Voreinstellungen und Betriebssystemen zu testen - und vor allem auch ohne CSS-Unterstützung (auch das kann an Darstellungsprogrammen deaktiviert werden oder ist bei textbasierten Darstellungsprogrammen gar nicht eingebaut).
In verschärfter Form gilt all das für nicht Standardmethoden
wie java-script, java, SWF, um vorzubeugen, daß das Design die Darstellung des Inhaltes verhindert.
Immerhin hat sich gerade seit der Veröffentlichung der Empfehlung von CSS 2.1
eine deutliche Vereinheitlichung der Interpretation von Stilvorlagen auf dieser Basis ergeben,
was die Arbeit für Autoren wieder deutlich vereinfacht.
Allerdings ist auch ein Wildwuchs von proprietären Erweiterungen entstanden,
die von Autoren konsequent ignoriert werden sollten.
Auch bei Modulen von CSS3 sollte unbedingt gewartet werden,
bis dazu eine offizielle Empfehlung vorliegt, die Arbeit an der Spezifikation also abgeschlossen ist.
Eine vorzeitige Verwendung dieser Module jenseits von Tests der Module selbst bringt nur Chaos,
Komplikation und weitere Verzögerungen, bis eine ordentliche Spezifikation veröffentlicht werden kann.
Auch die herstellerspezifischen Präfixe sind nur für Tests gedacht, nicht für normales Design.
Die Hersteller sind inzwischen übereingekommen, Eigenschaften mit Präfix nicht mehr im normalen Betrieb zu interpretieren,
nur noch wenn der Nutzer dies explizit am Programm einstellt.
Designer können also nicht davon ausgehen, daß neue Versionen von Programmen solche Eigenschaften mit
Präfix noch interpretieren, da wenige Nutzer die Einstellmöglichkeit kennen werden.
In jedem Falle sollte der Einsatz von Nichtstandard-Methoden für den Nutzer unmittelbar einsichtig sein. Wenn zum Beispiel ein Video gezeigt werden soll, ist vom Nutzer nachvollziehbar, daß er für das Videoformat ein Abspiel-plugin im Darstellungsprogramm oder ein externes Programm braucht. Nur wenige Formate werden von Darstellungsprogrammen direkt interpretiert und erst recht nicht von all diesen dieselben Formate. An einen Verweis, wo er ein plugin im internet zum kostenlosen Herunterladen findet - und zwar für jedes Betriebssystem - sollte es bei einem exotischen Format nicht fehlen und was letztlich als exotisch angesehen wird, entscheidet sich beim Nutzer, nicht beim Autor. Ein Nutzer, für den das Format nicht darstellbar ist, ist immer mit einer alternativen Beschreibung zu erfreuen, die auch von anderen Nutzern gern mit Gewinn gelesen werden wird.
Mehrfach sind bereits die Konflikte zwischen den dekorativen und den anderen Elementen des Projektes angesprochen worden. Wie können nun solche Konflikte von vorne herein vermieden werden? - die nachträgliche Behebung solcher Konflikte ist oft recht mühsam. In vielen Fällen ergeben sich diese Konflikte bereits aus einem falschen Denkansatz ganz am Anfang des Projektes, so daß direkt hier angesetzt werden muß, um zu optimalen Ergebnissen zu kommen: Logisches Vorgehen bei der Umsetzung des Projektes führt zum gewünschten Erfolg, dabei kann das im folgenden grob skizzierte Schema benutzt werden:
Viele Probleme und Fehler bei der Umsetzung von internet-Projekten lassen
sich gezielt vermeiden durch Sachkenntnis verwendbarer Standards
und systematisches Vorgehen bei der Erstellung des Projektes.
Um so erstaunlicher erscheint es, daß dabei so viele auch angeblich
professionelle "webdesigner" regelmäßig jämmerlich versagen.
Zu vermeiden ist dies nur durch logisches Denken und Berücksichtigung der Besonderheiten des Mediums,
die vor allem darin begründet sind, daß der Ersteller des Projektes nicht nur über gute technische Kenntnisse verfügen muß,
was die Programme zum Erstellen des Designs und des Layouts betrifft,
sondern noch viel mehr muß er vertraut sein mit den verwendeten Standardformaten, aber auch mit den Möglichkeiten der verschiedenen Darstellungsprogramme,
mit denen der spätere Nutzer sein Projekt wahrnehmen wird.
Eine böse Falle können in dem Zusammenhang viele sogenannte
XHTML-Editoren sein,
die mit bunten graphischen Oberflächen und viel Schnickschnack dem Seitenersteller suggerieren,
die technische Kompetenz nicht mehr zu benötigen, weil diese vom Programm übernommen wird.
Diese Einschätzung ist ein großer Irrtum, die Programme ersetzen eine solche Kompetenz nicht.
XHTML zeichnet den Inhalt semantisch und seiner Funktion gemäß aus.
Diese Programme können die Funktion und die semantische Bedeutung des Inhaltes gar nicht beurteilen
und helfen dem Autor in der Regel dabei auch nicht.
Und diesem Irrtum unterliegen auch die Hersteller dieser Programme, wenn es nicht gar böse Absicht ist,
um den Nutzer solcher Programme an diese oft kostenpflichtigen Produkte zu binden,
wo es auch ein simpler Texteditor täte.
Bei diesen Programmen sind in der Regel die Standards nicht einstellbar, an die man sich halten will -
manchmal halten sich die Programme an gar keinen Standard oder verleiten den Seitenersteller dazu,
extrem neue Funktionen neuester Standards so einzusetzen,
daß die Seiten mit älteren Darstellungsprogrammen nur noch verstümmelt angezeigt werden -
oder eben auch gar nicht mehr.
Es bleibt dem Ersteller eines Projektes also nicht erspart,
sich ganz persönlich mit den technischen Details der Realisation seines Projektes zu beschäftigen,
sonst wird er nur ein weiteres Zeugnis des Versagens und der Inkompetenz abliefern,
statt mit Sachkenntnis und gelungener Umsetzung zu glänzen...
