Information für alle

Praktische Umsetzung von internet-Projekten

Dr.O.Hoffmann@gmx.de
24-29.04./11.05./14.07.2003

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-" sind 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 Umterschied 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
- Funtionelles
- 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.
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 (Juli 2003) 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). 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 eigenen 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 html-Standards (html3.2, html4, xhtml1 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 von allen browsern fest implementiert. Etabliert ist im Bereich der Pixelgraphik hingegen das jpg-Format (Joint Photographic Experts Group, bei w3c und 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. 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 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 html-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 html-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 html 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 html-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 html-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.

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 html 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 html 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 html 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 html 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 html-Seiten integriert werden können - insbesondere auch andere html-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 zwei Standards an (css1 und css2), die vor allem der Textformatierung in html dienen, allgemeiner dem Layout von 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 noch recht uneinheitlich - viele browser unterstützen css2 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.

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:
1. Festlegen des Themas der Seite
- Sammlung der Inhalte
- Logische Strukturierung der Inhalte in Untergruppen
2. 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.
3. 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.
4. 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
5. 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

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 betrachten wird.
Eine böse Falle können in dem Zusammenhang viele sogenannte html-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 - das ist ein großer Irrtum - auch der Hersteller dieser Programme (wenn nicht gar böse Absicht, 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...