1. Erschütterndes aus dem internet
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.
2. Besonderheiten des Mediums
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.
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.
Elektronische Informationen werden 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.
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 browser 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 browser dargestellt werden.
Im Gegensatz zu Medien wie Fernsehen, Video oder Musik-CDs ist dem
Anbieter der Information auch gar nicht genau bekannt, welche
Fähigkeiten der browser des späteren Nutzers haben wird und
welcher browser eingesetzt werden wird, um die Information zugänglich
zu machen. Ja es wird technisch nicht einmal möglich sein, daß
alle Nutzer den gleichen browser 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 browser mannigfaltige Voreinstellungen
getätigt werden können, die die Eigenschaften des browsers
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, den Mehrheitsbrowser zu verwenden -
oder es gibt aus den verschiedensten Gründen Vorbehalte gegen den
browser (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 browsern 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 den einfachen
Text-browser und damit auch für den Behinderten unüberwindlich
werden.
Letztlich ist die neunzig-Prozent-Einstellung
ähnlich assozial 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.
3. Komponenten eines Projektes
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:
- Technisches
- Funktionelles
- Inhalt
- Dekoratives
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 der
browser 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
xhtml
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 xhtml-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 browser 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 eigentlich 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 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 einer geschickte Kombination aller Komponenten an, um
maximale Wirkung zu erzielen.
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.
4. Auswahl der einzusetzenden Mittel
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 (März 2005) der
Dinge aus, so ist html,
beziehungsweise xhtml (siehe:
»Hypertext Markup Language)
das Basismittel zur Umsetzung eines Projektes. Diese Dokumentbeschreibungssprache
wird zusammen mit dem http
(siehe: »Hypertext Transfer Protokoll)
dem späteren Nutzer des Angebotes die Textinformation im Klartext liefern
(die elektrische Kodierung des Klartextes erfolgt gemäß
ascii
beziehungsweise ansi,
siehe zum Beispiel bei
»selfhtml).Eine Erweiterung allerdings mit der gleichen Kodierung der
Grundzeichen sind UTF und einige ISO-charsets.
Der http und 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 software, sind hingegen
ungeeignet, weil nicht bekannt ist, mit welchem Betriebssystem und welcher
software die Daten abgerufen werden. ascii-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 der
dann aktuellen software nicht mehr lesbar.
Die (x)html-Standards (html4, xhtml1.0, xhtml1.1 etc) sind insofern recht unkritisch,
weil man Dokumente in diesem Format notfalls auch ohne browser lesen kann
und zum großen Teil auch von browsern, die nur einen älteren
Standard kennen, interpretiert werden können.
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ß diese Formate noch relativ neu
sind und noch nicht in allen browsern komplett implementiert. Etabliert ist
im Bereich der Pixelgraphik hingegen das
jpeg-Format
(auch jpg, Joint Photographic Experts Group,
»jpg bei w3c
und »jpg bei jpeg, Pixelgraphik,
besonders für Bilder von Digitalkameras und scannern), 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. xhtml 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
browser, die Bilder prinzipiell nicht darstellen und bei jedem browser
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 serverseitige Methoden
zurückgegriffen werden. Ob zum Beispiel die xhtml-Ausgabe mit
php
erzeugt wird oder mit
cgi-scripten
oder einfach als Text-Dateien auf dem
server 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 serverseitig 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.
Benutzeridentifikation mit cookies ist ebenfalls
problematisch, wie bei java-script handelt es sich nicht um einen Standard,
es ist keine serverseitige Technik und ist vom Nutzer leicht manipulierbar.
Das Funktionieren des Projektes jedenfalls sollte nicht von ihnen
abhängen.
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, dabei
sollte auch nur die Schnittmenge aller html-Standards als Befehlssatz
für funktionelle Komponenten gewählt werden.
Daraus ergibt sich, daß zum Beispiel java-script
(»Netscape),
java
(»Sun)
oder swf (shockwave flash,
»Macromedia)
wiederum für diese
Anwendung komplett ungeeignet sind. All diese Methoden laufen
anwenderseitig, verlangen im browser 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 kristischen
und ungeeigneten Formaten erstellt werden, sind reiner Unfug, so lange
nicht eine reine xhtml-Variante als Alternative bereit gestellt 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öß mitskalieren, was in der Praxis
für den Autor allerdings so schwierig sein kann, daß Bilder in
Menüs wieder unpraktikabel werden.
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 verbreitetste Mittel zum Einsatz kommen sollte. Basis-Methode ist somit wieder xhtml und die genannten Bildformate. Aber es gibt sicher auch 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, Videos, »smil)
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 xhtml auf, ist aber kein Klartextformat mehr,
die Daten sind komprimiert. 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. Von der Idee her ist ps
vorzuziehen. Weiter verbreitet scheint inzwischen das etwas jüngere
pdf-Format zu sein.
Einen Haken haben inzwischen beide Formate: Offenbar gibt es inzwischen
zahlreiche Versionen, teilweise offenbar auch sehr nah an bestimmte
Betriebssysteme angelehnt, so daß es beim Nutzer wieder zu den
bereits angesprochenen Interpretationsproblemen der eingesetzten
software 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.
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 ist, erfreut 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ß browser, die den
html4-strict-Standard oder xhtml interpretieren,
wie etwa textbasierte browser,
frames gar nicht darstellen werden. iframes, eine Variante, die auf die
Firma microsoft zurückzuführen ist, wird sogar von noch weniger
browsern interpretiert. Daraus sollte der Ersteller eines Projektes
den Schluß ziehen, so weit möglich ganz auf frames zu verzichten
oder eine typische Möglichkeit von xhtml ausgiebig zu nutzen,
Altenativen anzubieten (noframe-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 serverseitige
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-Variante und in xhtml
gar nicht gibt, sollte auf einen recht eleganten und verallgemeinerten
Ersatz hingewiesen werden, der recht ähnliche Funktionen
übernehmen kann - dabei handelt es sich um die object-Funktion,
mit dem im Prinzip beliebigen 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 browsers 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 mit funktionalen oder inhaltlichen Komponenten
kommen dürfen.
W3c bietet mit css
(»cascading style sheet)
ebenfalls einen Standard, der vor allem der Textformatierung in
xhtml dient, allgemeiner dem Layout von xhtml-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 noch recht uneinheitlich -
viele browser unterstützen css etwa nur teilweise. Zum anderen
bietet css so viele Formatierungsmöglichkeiten, daß damit
- auch unbeabsichtigt - viel Unfug getrieben werden kann, der bei
verschiedenen browsern 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 browsern,
Voreinstellungen und Betriebssystemen zu testen - und vor allem auch
ohne css-Unterstützung (auch das kann an browsern deaktiviert werden
oder ist bei textbasierten browsern gar nicht eingebaut).
In verschärfter Form gilt all das für nicht Standardmethoden
wie java-script, java, swf, um zu verhindern, daß das Design die
Darstellung des Inhaltes verhindert.
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 Abspielplugin im browser braucht. An einen Verweis, wo er dieses in internet zum kostenlosen Herunterladen findet - und zwar für jedes Betriebssystem - sollte es nicht fehlen. Und wenn er das nicht tun möchte, sollte man ihn trotzdem mit einer alternativen Beschreibung erfreuen, die auch andere Nutzer gern mit Gewinn lesen werden.
5. Konflikte vermeiden durch richtigen Denkansatz
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:
- Festlegen des Themas der Seite
- Sammlung der Inhalte
- Logische Strukturierung der Inhalte in Untergruppen - Sorgfältige Auswahl der notwendigen Techniken und Methoden, um die
Inhalte darzustellen
- Kontrolle, ob für den Zweck Standardmethoden ausreichen
- Bei nicht-Standardmethoden ermitteln, welche Version für die Darstellung der Inhalte ausreicht - wenn nur die Schnittmenge der Befehlsätze aller Versionen genutzt wird, sollte der spätere Nutzer am wenigsten Probleme bekommen
- Offenbar sollte auf Methoden verzichtet werden, wo Unterschiede zu früheren Komponenten nicht offengelegt sind oder die Methode nicht einmal theoretisch für jeden Besucher des Projektes verfügbar ist. - Festlegen der funktionellen Komponenten und Techniken, die notwendig
sind, um den Inhalt darzustellen.
- Wie soll die Navigation, das Menü des Projektes aussehen und welcher Umfang von Inhalt muß damit verwaltet werden. Die verwendete Technik richtet sich dann ganz zwanglos nach diesem Umfang. Wenig Inhalt kann auch mit relativ einfacher Technik verwaltet werden. Bei großen Mengen werden serverseitige Techniken wie php oder Datenbanken benötigt, um eine Navigation zu realisieren, insbesondere wenn öfter Inhalt gewechselt oder hinzugefügt werden wird.
- Somit sollte sich an dieser Stelle klären, ob serversseitige Techniken notwendig und verfügbar sind oder ob es möglich ist, diese statt anwenderseitiger Methoden einzusetzen, um spätere Probleme beim Nutzer zu vermeiden. - Erarbeitung des Designkonzeptes
- Erstellung des Layoutes und einer Designvorlage - Auswahl dafür geeigneter Methoden, die zudem nicht zu Konflikten mit anderen Komponenten führen
- Test des Designs unter verschiedenen Bedingungen (verschiedene browser, bei jedem verschiedene Voreinstellungen, zum Beispiel mit und ohne style-sheet, java-script und ähnlichem. Wichtig ist auch Größe und Typ voreingestellter Fonts am browser, vor allem aber auch intensives Durchprobieren verschiedenster Fenstergrößen beim jeweiligen browser) - im Grunde sind es Phantasten, die glauben, sie könnten bei einem internet-Projekt ein Design erreichen, welches bei allen Nutzern identisch aussieht. Realistisch ist es, ein Design anzustreben, welches bei allen ansehnlich ist.
- Solange das Design nur mit einem oder wenigen browsern und Voreinstellungen ansehnliche Resultate liefert, ist es zu überarbeiten - Technische Umsetzung des Projektes
- Elektronische Darstellung des Inhaltes, der funktionellen Komponenten, realisieren technischer Komponenten
- Integration derselben ins Design und Verknüpfung mit den funktionellen Komponenten
- ausgiebiger Test und Fehlersuche
- nach Fertigstellung des Projektes Zusammenfassung und Stichwörter für Suchmaschinen und Kataloge zusammenstellen, die Startseite für selbige einrichten und optimieren, Projekt dort anmelden und auf anderen Seiten ausgiebig auf die neue Seite verweisen. Genaugenommen ist eine fachgerecht erstellte xhtml-Seite mit relevanten Inhalt übrigens schon für Suchmaschinen optimiert.
6. Worauf es ankommt
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
Möglichkeiten der verschiedenen browser, 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 seiner
Funktion gemäß aus. Diese Programme können die
Funktion 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 browsern 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...