Inhaltsverzeichnis Infoseite nächstes Kapitel


Integritätstests

Verwendungstests

Seiten hinzufügen und diese aktualisieren

Zusammenfassung

Fragen und Antworten



Kapitel 29


Testen, Überarbeiten und Verwalten von Web-Präsentationen

Nachdem Sie dieses Buch soweit sorgfältig gelesen haben, haben Sie Ihre eigene Web-Präsentation mit unzähligen praktischen Seiten erzeugt, mit hinreißenden Bildern und mit einem oder zwei Formularen. Und sie ist großartig geworden. Dann haben Sie Tabellen angelegt und Bilder ausgerichtet, mehrere Bilder mit JPEG komprimiert und ein wirklich cooles QuickTime-Video von Ihnen und Ihrer Katze eingefügt. Ihr Skript läßt eine Glocke erklingen, wenn jemand auf einen Link klickt. Recht viel besser kann sie nicht mehr werden, glauben Sie. Sie sind fertig?


Schlechte Neuigkeiten. Sie sind eben noch nicht fertig. Jetzt müssen Sie sich über zwei Dinge Gedanken machen. Sie müssen Ihre Präsentation testen und warten.


Beim Testen stellen Sie sicher, daß Ihre Web-Präsentation funktioniert - nicht nur vom technischen Standpunkt aus gesehen (Ist der HTML-Code korrekt? Funktionieren alle Links), sondern auch von der funktionalen Seite her (Finden die Leser auf Ihren Seiten das, was sie brauchen?). Darüber hinaus sollten Sie sicherstellen, daß Ihre Präsentation in mehreren Browsern gelesen werden kann, insbesondere, wenn Sie die neuen Tags verwenden, die Sie in den vorhergehenden Kapiteln kennengelernt haben.


Aber selbst, wenn alles getestet ist und wunderbar funktioniert, sind Sie noch nicht fertig. Sobald Sie Ihre erste Präsentation veröffentlicht haben, wollen Sie sie ergänzen und modifizieren, so daß alles interessant und aktuell bleibt. Glauben Sie mir. Im Web ändert sich die Technologie ständig, eine Präsentation wird nie fertig. Es gibt immer irgendwelche Seiten, die verändert werden müssen.


Nachdem Sie dieses Kapitel gelesen haben, werden Sie alles über die folgenden Themen wissen:



Integritätstests

Integritätstests haben nichts mit irgendwelchen Steuerhinterziehungen zu tun. Sie stellen einfach nur sicher, daß Ihre Seiten korrekt funktionieren, daß sie ohne Fehler angezeigt werden und daß alle Links auf sinnvolle Positionen zeigen. Dabei wird nichts darüber ausgesagt, ob Ihre Seiten sinnvoll sind oder ob die Leser sie gebrauchen können. Es wird also nur die technische Korrektheit geprüft. Die Integritätstests folgen drei Schritten:



Prüfen Ihres HTML-Codes

Im ersten Schritt stellen Sie sicher, daß Ihr HTML-Code korrekt ist, daß all Ihre Tags richtig abgeschlossen werden, daß sich die Tags nicht überlappen oder innerhalb von anderen Tags verwendet werden.


Aber das prüft doch der Browser für Sie, oder? Nicht ganz. Browser sollen Probleme in den HTML-Dateien erkennen und danach versuchen, festzustellen, was der Autor mit seinem Programm ursprünglich bewerkstelligen wollte, und sie zeigen dann irgend etwas an, wenn dies nicht möglich ist. (Erinnern Sie sich noch daran, wie Tabellen in einem Browser aussahen, der keine Tabellen unterstützt? Auch in diesem Beispiel versucht der Browser herauszufinden, was Sie eigentlich wollten.) Dabei sind einige Browser nachsichtiger gegenüber Fehlern als andere. Es kann sein, daß eine fehlerhafte Seite in einem Browser funktioniert, in einem anderen dagegen nicht.


Aber es gibt nur eine gültige HTML-Definition, nämlich die der HTML-Spezifikation. Einige Browser kommen mit dem HTML zurecht, das Sie ihnen möglicherweise fehlerhaft übergeben, aber wenn Sie von vornherein korrektes HTML schreiben, dann funktionieren Ihre Seiten garantiert in allen Browsern, die die von Ihnen verwendete HTML-Version unterstützen.


Um genau zu sein: Die einzig gültige Definition von HTML wird durch die sogenannte HTML DTD, also die Document Type Definition, festgelegt. HTML wird durch eine Sprache namens SGML definiert, eine umfassendere Sprache zur Definition anderer Sprachen. Die DTD ist eine SGML-Definition einer Sprache, also ist die HTML DTD die verbindliche technische Definition für HTML.

Aber wie können Sie sicherstellen, daß Ihr HTML-Code korrekt ist? Wenn Sie den Regeln und Beispielen folgen, die ich in den bisherigen Kapiteln vorgestellt habe, dann dürfte es an Ihrem HTML-Code nichts zu bemängeln geben. Aber jeder vergißt einmal ein abschließendes Tag, setzt ein Tag am falschen Platz oder vergißt die Anführungszeichen nach einer HRF. (So etwas passiert ständig, und es gibt viele Browser, die damit nicht zurechtkommen.) Die beste Methode, herauszufinden, ob Ihre Seiten korrekt sind, ist die Verwendung eines HTML-Validators, also eines Testprogramms.


Viele HTML-Editoren bieten inzwischen eingeschränkte Möglichkeiten zum Überprüfen Ihres HTML-Codes. Bei Programmen wie HoTMetaL Pro von SoftQuad geht dies sogar soweit, daß die interne Codeüberprüfung Sie davon abhält, Dokumente zu erzeugen, die bei der Überprüfung durchfallen würden. Bei den meisten Editoren ist die Codeüberprüfung allerdings eingeschränkt und unvollständig. Die Krönung ist allerdings, daß einige Editoren es Ihnen nicht nur erlauben, falschen HTML-Code zu produzieren, sondern sogar falschen HTML-Code für Sie erzeugen. Aus diesem Grund ist es sinnvoll, eine externe Codeüberprüfung zu verwenden.

Ein HTML-Validator soll Ihren HTML-Code auf seine technische Korrektheit überprüfen. Dem Validator ist es egal, wie Ihre Seiten aussehen - er prüft nur, ob Ihr HTML-Code der aktuellen HTML-Spezifikation (HTML 2 oder 3.2 usw.) entspricht. Wenn Sie jemals unter Unix programmiert haben, dann werden Sie feststellen, daß dieses Werkzeug eine ziemliche Ähnlichkeit mit lint hat, mit dem Codeprobleme ermittelt werden können. Um portables HTML zu erzeugen sowie HTML, das von zukünftigen Generationen von Autorenwerkzeugen gelesen werden kann, sollten Sie es wirklich auf Korrektheit überprüfen. Sie können nicht jedesmal, wenn wieder einmal das ultimative HTML-Autorenwerkzeug erscheint, das Ihren Code nicht mehr lesen kann, Tausende von Seiten von Hand reparieren.


Aber selbst wenn Ihr HTML-Code korrekt ist, sollten Sie Ihre Seiten in mehreren Browsern testen, um sicherzustellen, daß nicht irgendwelche seltsamen Designentscheidungen getroffen wurden. Ein Validator nimmt Ihnen die Designarbeit nicht ab.


Aber wie können Sie diese HTML-Validatoren einsetzen? Einige davon stehen im Web zur Verfügung, und Sie können sie sich herunterladen und lokal auf Ihrem System ausführen, andere wurden als Webseiten realisiert, wo Sie Ihre URLs in ein Formular eintragen können und der Validator sie im Netzwerk überprüft. Zwei dieser Programme finde ich besonders gut: den HTML Validation Service von WebTech sowie Weblint von Neil Browsers.


Wie es bei allen Webseiten der Fall ist, ändern sich diese Dienste ständig - bieten neue Features und verändern ihr Erscheinungsbild. Aber selbst wenn sie bei Ihrem Besuch anders aussehen sollten als in den hier gezeigten Beispielen, sollten diese Beispiele Ihnen eine gute Vorstellung von der Funktionsweise dieser Dienste vermitteln.


Der WebTech-HTML-Validator

Der HTML-Validator von WebTech (früher bekannt als HTML-Validator von HAL) ist ausschließlich auf HTML 2.0 oder 3.2 ausgerichtet. Er überprüft Ihr HTML-Dokument entsprechend der SGML-Definition von HTML. Diese Prüfung garantiert, daß Ihre Seiten völlig HTML-konform sind. Abbildung 29.1 zeigt die Homepage des HTML-Validators. Unter http://valsvc.webtechs.com/url/ können Sie Ihre bereits veröffentlichten Seiten interaktiv testen.


siehe Abbildung

Abbildung 29.1:
Die Homepage des HTML-Validators

Sie können Ihre Seiten in verschiedenen Stufen testen:


Neben diesen elementaren Stufen können Sie auch die Überprüfungsstufe »Strict« wählen, die die folgenden Dinge feststellt:


Die Verwendung von Strict führt zu anderen Ergebnissen, probieren Sie also Ihre Seiten in beiden Modi aus.


Sie können Ihre Seiten als URLs spezifizieren (falls sie bereits veröffentlicht wurden). Wenn Sie nicht ganz sicher sind, ob ein bestimmter HTML-Code korrekt ist, können Sie ihn auch in das Formular kopieren und von dort aus testen (siehe Abbildung 29.2).


siehe Abbildung

Abbildung 29.2:
Code im HTML-Validator prüfen

Wenn Ihre Seiten noch nicht veröffentlicht sind, Sie sie aber trotzdem überprüfen möchten, steht das Validator-Programm für verschiedene Plattformen zur Verfügung (leider alle Unix-basiert). Details finden Sie unter http://valsvc.webtechs.com/.

Ihre HTML-Seite wird durch einen SGML-Parser geprüft, ebenso nach der aktuellen HTML-Definition für die verwendete Stufe. Etwaige Fehler werden zurückgemeldet (ein Beispiel dafür sehen Sie in Abbildung 29.3). Wenn Sie im Originalformular Show Input gewählt haben, wird in der Ausgabe gleichzeitig Ihr HTML-Code mit Zeilennummern angezeigt, wodurch Sie die Fehler leichter finden, über die sich der Validator beschwert.


In diesem Beispiel bezieht sich die Fehlermeldung auf einen Absatz, in dem ich versehentlich das <P> weggelassen, jedoch das </P> angegeben habe:


An manchen Tagen habe ich plötzlich den Drang, witzig sein zu müssen. Sehr zum Glück meiner Mitmenschen dauert dieser Drang nie länger als ein paar Minuten an. Aber manchmal schreibe ich mir die Dinge auf.</P>


Die Verwendung eines abschließenden Tags ohne ein zugehöriges öffnendes Tag hat keine besonderen Auswirkungen auf die Anzeige des Dokuments, aber in einem unnachsichtigeren HTML-Browser macht sie vielleicht Probleme. Der Validator erkennt den Fehler, und ich kann ihn beheben.


Wenn Sie einen Fehler in Ihrer HTML-Datei korrigiert haben, führen Sie den Test erneut aus. Der HTML-Validator prüft Ihre Datei nämlich nicht zu Ende, wenn er einen fatalen Fehler entdeckt hat. Es könnte also sein, daß im restlichen Dokument noch weitere Fehler vorhanden sind.


siehe Abbildung

Abbildung 29.3:
Der Validator meldet die Fehler zurück

Die vom Validator erzeugten Fehlermeldungen sind häufig mißverständlich, um es gelinde auszudrücken. Eine strenge Überprüfung scheint unzählige unverständliche Fehler zu produzieren. Prüfen Sie Ihr Dokument in beiden Modi, und korrigieren Sie die offensichtlichsten Fehler.


Weblint

siehe Abbildung

Abbildung 29.4:
Das HTML-Prüfprogramm Weblint

Das Programm Weblint führt eine allgemeinere Überprüfung durch. Es stellt nicht nur sicher, daß Ihre Syntax korrekt ist, sondern erkennt auch allgemeinere Fehler: nicht übereinstimmende schließende Tags, die Angabe von TITLE außerhalb von HEAD, mehrfach vorkommende Elemente, die nur einmal vorhanden sein sollten. Außerdem gibt es noch viele andere Hinweise. Es ist viel benutzerfreundlicher als der HTML-Validator, aber es ist ungenauer hinsichtlich der strengen HTML-Konformität (und möglicherweise beschwert es sich über ein paar neuere Tags, etwa für Tabellen, weil es sie noch nicht kennt).


Abbildung 29.4 zeigt die Weblint-Seite unter http://www.unipress.com/cgi-bin/WWWeblint. Sie zeigt das Formular, in das Sie Ihre Seiten zur Überprüfung eintragen können.


Abbildung 29.5 zeigt die Ausgabe einer Überprüfung, die ich für den Fehler mit dem fehlenden <P> ausgeführt habe.


siehe Abbildung

Abbildung 29.5:
Ausgabe von Weblint

Interessanterweise hat Weblint festgestellt, daß ich ein schließendes </HEAD>-Tag vergessen habe, das der Validator übersehen hatte. Dagegen hat es die Tatsache, daß es ein </P> ohne entsprechendes <P> gibt, völlig ignoriert. Die beiden Programme haben für ein und dieselbe Seite völlig unterschiedliche Ergebnisse produziert.


Weblint ist inzwischen kein kostenloser Service mehr. Man kann sich für eine Jahresgebühr von $ 16.95 anmelden. Sie können aber auch erst einmal einen kostenlosen Probelauf machen, der nur die ersten 2048 Byte Ihrer Dokumente prüft (das führt bei längeren Dokumenten natürlich zu Fehlern, die eigentlich keine sind, sondern nur aus fehlenden Tags resultieren, die sich im Bereich nach 2048 Byte befinden).



Übung 29.1: Überprüfen einer Beispielseite

Nur um zu zeigen, welche Fehler Weblint und der Validator feststellen können, werde ich hier eine Beispieldatei mit einigen häufig gemachten Fehlern zusammenstellen.


Wir verwenden dazu die Homepage »Susan's Cactus Gardens«, die Sie in Abbildung 29.6 sehen.


siehe Abbildung

Abbildung 29.6:
Susan's Cactus Gardens

In Netscape funktioniert die Seite ganz gut, und sie sieht auch zufriedenstellend aus. Aber jetzt kommt der Code. Er ist randvoll mit Fehlern. Versuchen Sie, sie selbst zu finden, bevor Sie sich die Ergebnisse der Prüfung ansehen.


<HTML>
<HEAD>
<TITLE>Susan's Cactus Gardens: A Catalog</TITLE>
<HEAD>
<BODY>
<IMG SRC="cactus.gif" ALIGN=MIDDLE>
<STRONG>Susan's Cactus Gardens</STRONG>
<H1>Choosing and Ordering Plants</H3>
<UL>
<H3>
<LI><A HREF="browse.html">Browse Our Catalog
<LI><A HREF="order.html>How To Order</A>
<LI><A HREF="form.html">Order Form</A>
</UL>
</H3>
<HR WIDTH=70% ALIGN=CENTER>
<H1>Information about Cacti and Succulents</H1>
<UL>
<LI><A HREF="succulent.html">What does succulent Mean?</A>
<LI><A HREF="caring.html">How do I care for my cactus or succulent?</A>
<LI><A HREF="propogation.html">How can I propagate my Cactus or succulent?</A>
</UL>
<HR>
<ADDRESS>Copyright &copy; 1994 Susan's Cactus Gardens
susan@catus.com</ADDRESS>


Zuerst versuchen wir es mit Weblint. Meiner Erfahrung nach sind die Fehlermeldungen von Weblint einfacher zu lesen, deshalb ist es am besten, die offensichtlichsten Fehler zuerst dort zu korrigieren. Weblints Antwort (oder zumindest einen Teil davon) sehen Sie in Abbildung 29.7.


 

Abbildung 29.7:
Weblints Antwort auf die fehlerhafte Datei

Wir beginnen ganz oben mit dem zweiten Fehler:


line 4: tag <HEAD> should only appear once. I saw one on line 2!


Hier noch einmal der Code der Zeilen 1 bis 4:


<HTML>
<HEAD>
<TITLE>Susan's Cactus Gardens: A Catalog</TITLE>
<HEAD>
<BODY>


Das Tag in der vierten Zeile (<HEAD>) sollte </HEAD> sein. Einige Browser haben Schwierigkeiten mit dem Hauptteil des Dokuments, wenn Sie vergessen, den Titel abzuschließen. Diesen Fehler sollten Sie unbedingt beheben.


Anschließend sollten viele der anderen Fehler in der von Weblint erzeugten Liste, die sich darauf beziehen, daß irgend etwas im Titel nicht stehen kann (»X cannot appear in the HEAD element«), verschwinden. Betrachten wir den nächsten Fehler:


line 6: IMG does not have ALT text defined.


Er erklärt sich von selbst. Im IMG-Tag ist kein Wert für ALT angegeben. In textbasierten Browsern erscheinen alle Bilder, für die kein ALT angegeben ist, einfach nur als [IMAGE], was fürchterlich aussieht. Und so habe ich den Fehler behoben:


<IMG SRC="cactus.gif" ALIGN=MIDDLE ALT="">


Da das Bild hier nur aus Dekorationszwecken angezeigt wird, ist es egal, ob in der Textversion darauf hingewiesen wird oder nicht. Wir fügen einfach nur einen leeren String ein, so daß die Seite bei der Ansicht in einem textbasierten Browser gar nichts anzeigt, was darauf hinweisen könnte, daß ein Bild vorhanden war.


line 8: malformed heading - open tag is <H1>, but closing is </H3>


Betrachten wir Zeile 8:


<H1>Choosing and Ordering Plants</H3>


Der Fehler ist leicht zu erkennen. Wir haben H1 versehentlich mit H3 abgeschlossen. Die öffnenden und schließenden Tags müssen übereinstimmen, also ersetzen wir </H3> durch </H1>.


Der nächste Fehler zeigt auf eine ungerade Anzahl von Anführungszeichen in Zeile 12:


line 12: value for attribute HREF ("order.html) of element A should be quouted (i.e. HREF=""order.html")


Hier die Zeile:


<LI><A HREF="order.html>How To Order</A>


Der Dateiname wurde nicht mit einem Anführungszeichen abgeschlossen. Das funktioniert zwar in älteren Versionen von Netscape, aber nur die wenigsten anderen Browser kommen damit zurecht, und es handelt sich dabei wirklich um einen der häufigsten Fehler.


Zeile 12 enthält den nächsten Fehler:


line 12: <A> cannot be nested-</A> not yet seen for <A> on line 11.


Dies ist eigentlich ein Fehler in Zeile 11:


<LI><A HREF="browse.html">Browse Our Catalog


Am Ende dieser Zeile fehlt das Tag </A>, deshalb die Beschwerde. Man kann innerhalb eines <A>-Tags kein weiteres <A>-Tag angeben, so daß Weblint verwirrt ist (dieser Fehler kommt in dem Bericht mehrere Male vor). Achten Sie darauf, daß alle <A>-Tags am Ende des Verknüpfungstexts abgeschlossen werden.


Die folgenden Fehler sind alle ähnlich und beziehen sich auf fehlende abschließende Tags:


line 0: No closing </HTML> seen for <HTML> on line 1.
line 0: No closing </HEAD> seen for <HEAD> on line 2.
line 0: No closing </HEAD> seen for <HEAD> on line 4.
line 0: No closing </BODY> seen for <BODY> on line 5.
line 0: No closing </H1> seen for <H1> on line 8.
line 0: No closing </UL> seen for <UL> on line 9.
line 0: No closing </H3> seen for <H3> on line 10.
line 0: No closing </A> seen for <A> on line 11.


Eine schnelle Überprüfung zeigt, daß am Ende der Datei </BODY> und </HTML> fehlen. Das Problem ist also klar. Durch Ändern von <HEAD> in </HEAD> und </H3> in </H1> wird der Fehler behoben.


Aber was ist mit den nächsten beiden? Es gibt eine Beschwerde, daß <UL> und <H3> keine abschließenden Tags haben, aber sie stehen ganz am Ende der Liste. Beachten Sie jedoch die Reihenfolge. Die Tags UL und H3 überlappen sich hier, so daß das UL vor dem H3 geschlossen wird. Diese beiden Fehler korrigieren wir, indem wir die Tags einfach vertauschen.


Der letzte Fehler besagt, daß ein </A>-Tag fehlt. Wir haben ihn bereits behoben.


Das war der erste Durchlauf mit Weblint. Nun wollen wir noch schauen, was der Validator sagt. Wählen Sie die Überprüfung auf HTML-3.2-Konformität und lassen Sie uns mal gespannt sein, was wir finden.


Als erstes erhalten wir die folgende Fehlermeldung:


nsgmls: <OSFD>0:10:3:E: document type does not allow element "UL" here


Der Fehler resultiert daraus, daß Sie eine ungeordnete Liste in eine Überschrift der dritten Stufe eingebettet haben. Listen auf diese Art einzubetten, ist technisch gesehen nicht o. k., selbst wenn Netscape damit problemlos zurechtkommt. Sie müssen den Text in der Liste auf einem anderen Weg hervorheben:


<UL>
<LI><A HREF="browse.html"><B>Browse Our Catalog</B></A>
<LI><A HREF="order.html"><B>How To Order</B></A>
<LI><A HREF="form.html"><B>Order Form</B></A>
</UL>


Der nächste (und letzte Fehler) ist folgender:


nsgmls:<OSFD>0:14:12:E: an attribute value must be a literal unless it contains only name characters


Die fragliche Zeile ist, welche die horizontale Linie erzeugt:


<HR WIDTH=70% ALIGN=CENTER>


Was aber ist falsch in dieser HTML-Zeile? Der Fehler hängt mit dem Prozentzeichen (%) in der Wertangabe des WIDTH-Attributs zusammen. Wenn Sie den Wert in Anführungszeichen setzen, verschwindet der Fehler.


Wir führen noch eine Überprüfung durch. Abbildung 29.8 zeigt das Ergebnis.


 

Abbildung 29.8:
Das Ergebnis nach dem letzten Durchlauf im HTML-Validator

Glückwunsch! Die Kaktus-Seite ist jetzt HTML-konform. Und es waren nur zwei Programme und fünf Durchläufe dafür notwendig ...


Dies war natürlich ein extremes Beispiel. Größtenteils gibt es auf Ihren Seiten auch nicht annähernd so viele Probleme, wie hier gezeigt (und wenn Sie einen HTML-Editor einsetzen, können viele davon gar nicht erst zustandekommen). Beachten Sie jedoch, daß Netscape all diese Fehler ohne jede Beschwerde hingenommen hat. Nicht alle Browser sind so nachsichtig!



Browser-Test

Wie bereits erwähnt, können die HTML-Prüfprogramme nur feststellen, ob Ihr HTML-Code korrekt ist. Sie sagen nichts über das Design aus. Nachdem Sie mit der Überprüfung des HTML-Codes fertig sind, sollten Sie Ihre Seiten mit so vielen Browsern wie möglich ausprobieren, um sicherzustellen, daß der Entwurf paßt und Sie keine Elemente verwenden, die in einem Browser wunderschön, in einem anderen dagegen fürchterlich aussehen. Da die meisten Browser einfach aus dem Netz heruntergeladen werden können, sollten Sie mindestens zwei oder drei für Ihre Plattform ausprobieren.


Im Bestfall sollten Sie jede Ihrer Seiten in mindestens drei Browsern testen:


Damit erhalten Sie einen guten Eindruck, wie Ihre Seiten in anderen Browsern aussehen. Wenn Sie für Ihre Seiten Netscape- oder Internet Explorer-Erweiterungen nutzen, sollten Sie sie sowohl in Netscape als auch im Microsoft Internet Explorer testen, um sicherzugehen, daß diese in beiden Browsern richtig angezeigt werden.



Überprüfen Sie Ihre Links

Der dritte und letzte Test betrifft die Korrektheit Ihrer Links. Am besten können Sie diese natürlich prüfen, indem Sie sich vor einen Browser setzen und sie selbst nachvollziehen. Das ist für kleine Präsentationen ganz einfach, aber es kann doch sehr mühsam sein. Außerdem könnte es sein, daß Sie nach der ersten Überprüfung einige Namen verändern. Da sich das Web ständig irgendwie verändert, können Ihre Links fehlerhaft werden, auch wenn sich an Ihren Seiten nichts geändert hat.


Hinweise auf fehlerhafte Links, die sich auf Ihren eigenen Seiten befinden, die Sie möglicherweise beim Verschieben von irgendwelchen Dingen nicht berücksichtigt haben, finden Sie in den Fehlerprotokollen auf Ihrem Server. Diese Protokolle bezeichnen die Seiten, die nicht gefunden werden konnten: sowohl die fehlende Seite als auch die Seite, die den Link darauf enthielt. Damit dieser Eintrag in der Protokolldatei erscheint, muß natürlich jemand vergeblich versucht haben, dem Link zu folgen. Besser ist es in jedem Fall, den fehlerhaften Link festzustellen, bevor Ihre Leser das tun.


Die beste Methode für die Überprüfung von fehlerhaften Links ist der Einsatz eines Werkzeugs, des sogenannten »Link Checkers«, das die Seiten durchläuft und überprüft, ob alle darauf enthaltenen Links auf echte Dateien oder Sites im Web zeigen. Es gibt mehrere solcher Link Checker, unter anderem:



Verwendungstests

Verwendungstests stellen sicher, daß Ihre Dokumente verwendbar sind, selbst nachdem sie auf einfache technische Korrektheit getestet wurden. Sie können ganz einfach ein paar Webseiten zusammenstellen, aber finden Ihre Leser auch das, was sie suchen? Ist die Organisation so in Ordnung, wie Sie sie ursprünglich geplant haben? Werden Ihre Leser leicht verwirrt, oder ist die Navigation durch Ihre Seiten sehr schwierig?


Verwendungstests werden schon seit Jahren in vielen Firmen eingesetzt. Die Theorie dahinter ist, daß die Entwickler, welche ein Produkt erzeugen (sei es eine Software-Applikation, ein Videorecorder oder ein Auto), nicht feststellen können, wie gut oder schlecht es in der Handhabung ist, weil sie zu viel darüber wissen. Sie wissen, wie es entwickelt wurde, dann wissen sie natürlich auch, wie man es anwendet. Die einzige Methode, wie Sie feststellen können, wie einfach die Verwendung eines Produkts ist, ist Leute zu beobachten, die das Produkt noch nie gesehen haben. Dabei sollten Sie auf die Stellen achten, an denen diese Anwender Probleme haben. Nach diesen Erfahrungswerten können Sie das Produkt ändern, erneut testen, wieder ändern usw.


Web-Präsentationen sind ein gutes Beispiel für ein Produkt, das aus den Verwendungstests profitiert. Selbst wenn Sie nur einen Freund bitten, Ihre Seiten für Sie durchzusehen, kann Ihnen das viel darüber sagen, wie gut die Leute mit der von Ihnen entworfenen Struktur zurechtkommen.


Hier einige Aufgaben, die Sie den Testpersonen beim Überprüfen Ihrer Seiten stellen sollten:


Setzen Sie sich mit den Testpersonen zusammen, und machen Sie sich Notizen. Die Ergebnisse sind vielleicht überraschend, und Sie erhalten neue Ideen für die Organisation Ihrer Seiten.



Überprüfen Sie Ihre Protokolle

Eine weitere Methode für den Test Ihrer Dokumente nach der Veröffentlichung im Web ist die Auswertung von Server-Protokolldateien, was Sie in Kapitel 27, »Web-Server: Hinweise, Tricks und Tips«, gelernt haben. Ihr Web-Server oder -Anbieter schreibt eine Protokolldatei für jeden Zugriff auf Ihre Seite (immer wenn ein Browser das Dokument anfordert) und woher er kam (siehe Abbildung 29.9). Dadurch erhalten Sie mehrere Informationen:


siehe Abbildung

Abbildung 29.9:
Ein Beispiel für eine Protokolldatei


Seiten hinzufügen und diese aktualisieren

Selbst nachdem Sie Ihre Seiten veröffentlicht und sie sowohl auf Korrektheit als auch auf Funktionalität getestet haben, ist Ihre Präsentation noch nicht fertig. Man kann sogar sagen, daß sie nie fertig wird. Selbst wenn Sie es schaffen, sie so funktional wie möglich zu machen - es gibt immer wieder neue Informationen, die Sie auf neuen Seiten hinzufügen müssen, Aktualisierungen, Fortschritte im HTML, die Sie nutzen können usw.


Aber wie können Sie Ihre Web-Präsentationen warten? Sie erzeugen neue Seiten und verknüpfen sie durch Links mit den alten. Aber bevor Sie das tun, lesen Sie diesen Abschnitt, damit Sie wissen, wie Sie dabei am besten vorgehen.



Neuen Inhalt hinzufügen

Diesen Abschnitt beginne ich mit einer kleinen Geschichte.


In San Jose, Kalifornien, gibt es eine Touristenattraktion namens Winchester Mystery House. Ursprünglich gehörte dieser Landsitz der Erbin des Winchester-Rifles-Vermögens. Man erzählt sich, daß sie von einem Wahrsager die Botschaft erhalten hatte, daß die Geister aller Menschen, die durch die Winchester-Gewehre gestorben sind, sie und ihre Familie strafen würden. Von dem Zeitpunkt an glaubte sie, sie könnte die Geister verwirren, wenn Sie dem Winchester-Anwesen ständig neue Räume anbaute. Das Ergebnis war, daß neue Räume in das bereits existierende Haus angebaut wurden oder wiederum an irgendwelche Anbauten, ohne daß es dafür einen Plan oder irgendein System gab - die Arbeit hörte niemals auf. Es entstanden 160 Räume, Treppenhäuser, die ins Nichts führten, Türen, hinter denen sich nur Wände befanden, geheime Durchgänge sowie ein Grundriß, in dem sich niemand ohne Lageplan zurechtfindet.


Einige Web-Präsentationen sehen ganz ähnlich aus. Sie haben anfangs eine grundlegende Struktur, sind wohldurchdacht, organisiert und funktional. Je mehr Seiten jedoch in der Präsentation irgendwo hinzugefügt werden, desto schlechter strukturiert wird das Ganze, die ursprünglichen Ziele der Präsentation gehen verloren, und irgendwann hat man nur noch ein Chaos verketteter Seiten, in denen man sich allzuleicht verliert und unmöglich das finden kann, was man eigentlich sucht (siehe Abbildung 29.10).


siehe Abbildung

Abbildung 29.10:
Viele Web-Seiten mit konfuser Verknüpfungsstruktur

Vermeiden Sie, nach dem Modell des Winchester Mystery House vorzugehen! Wenn Sie einer existierenden Präsentation neue Seiten hinzufügen wollen, beachten Sie immer die folgenden Hinweise:



Überarbeiten Sie Ihre Struktur

Manchmal stellt man fest, daß die Präsentation an einem Punkt angelangt ist, wo die ursprüngliche Struktur nicht mehr funktioniert, oder daß sich Ihre Ziele geändert haben und die ursprüngliche Organisation es sehr schwierig macht, zu den neuen Informationen zu gelangen. Vielleicht hatten Sie aber von Anfang an keine Struktur und stellen fest, daß Sie jetzt eine brauchen.


Web-Präsentationen sind lebendige Konstrukte, und wenn Sie sie ändern, dann kann es notwendig werden, Ihren ursprünglichen Plan oder die Struktur zu überdenken. Bleibt zu hoffen, daß Sie dabei nicht ganz von neuem beginnen müssen. Oft gibt es eine Möglichkeit, Teile der Präsentation zu überarbeiten, so daß die neuen Informationen eingefügt werden können und die Gesamtpräsentation erhalten bleibt.


Manchmal ist es nützlich, zum ursprünglichen Plan für die Präsentation zurückzugehen (sie haben doch einen?) und ihn zu überarbeiten, so daß Sie Ihre Ziele wieder deutlicher sehen. Insbesondere sollten Sie folgendes ausprobieren:


Wenn Sie einen neuen Plan haben, sehen Sie in der Regel Bereiche, wo das Verschieben von Seiten oder des Inhalts auf manchen Seiten die Dinge wieder klarer macht. Behalten Sie Ihren neuen Plan während der Änderungen im Auge, und versuchen Sie, schrittweise vorzugehen. Wenn Sie zu viele Veränderungen gleichzeitig ausführen, zerstören Sie möglicherweise Links oder verlieren den Überblick. Wenn Sie Ihre Seiten auf deren Funktionalität geprüft haben, berücksichtigen Sie die Hinweise, die Sie aus dieser Arbeit gewonnen haben.



Zusammenfassung

Planen, schreiben, testen und warten sind die vier Meilensteine beim Entwurf von Webseiten. Planen und schreiben - unter anderem ist das, eine Struktur zu entwickeln, Seiten zu erzeugen, sie zu verknüpfen und dann das Ergebnis sukzessive zu verfeinern -, das haben Sie bereits durchs ganze Buch hindurch kennengelernt. In diesem Kapitel haben wir Ihnen die andere Hälfte des Prozesses gezeigt. Diese Hälfte geht jedoch noch weiter, nachdem Sie alles veröffentlicht haben und die Leute Ihre Seiten schon lange lesen.


Beim Testen wird sichergestellt, daß Ihre Seiten funktionieren. Vielleicht haben Sie bisher Ihre Seiten schon mit dem einen oder anderen Browser getestet, Ihre Links überprüft und sichergestellt, daß alle Ihre CGI-Skripten korrekt installiert und von der richtigen Stelle aus aufgerufen werden. Aber hier haben Sie gelernt, richtig zu testen - Integritäts-Tests mit HTML-Validatoren und automatische Programme für die Überprüfung von Links sowie Verwendungstests, mit denen man feststellen kann, wie praktisch die Leser Ihre Seiten finden.


Die Wartung erfolgt, wenn Sie Ihrer Präsentation neue Informationen hinzufügen und sicherstellen, daß alles noch zusammenpaßt und funktioniert. Die Wartung verhindert, daß Ihre ursprüngliche Planung durch die Veränderungen zerstört wird. Manchmal kann es auch sein, daß Sie mit einer völlig neuen Struktur und einigen neuen Seiten ganz von vorne beginnen müssen. Dieses Kapitel hat Ihnen einige Ideen vermittelt, wie Sie Ihre existierenden Präsentationen warten und überarbeiten.


Damit sind Sie fertig. Oder zumindest, bis es wieder an der Zeit ist, etwas zu ändern.



Fragen und Antworten

Frage:

Ich verstehe immer noch nicht, warum die HTML-Überprüfung notwendig ist. Ich teste meine Seiten in allen möglichen Browsern. Warum soll ich mir diese zusätzliche Arbeit antun, um sie endgültig HTML-konform zu machen? Spielt das eine Rolle?

Antwort:

Betrachten Sie es so. Stellen Sie sich vor, nächstes Jahr bringt die Web-Firma Z irgendein wahnsinnig praktisches Autorenwerkzeug für HTML heraus, das es Ihnen ermöglicht, schnell und einfach Webseiten zu erzeugen, sie zu verknüpfen, Hiearchien aufzubauen, die Sie visuell verschieben können, und alles mögliche andere, was bisher nur unter Mühen realisiert werden kann. Und das Werkzeug ist sogar in der Lage, Ihre alten HTML-Dateien einzulesen, so daß Sie nicht alles von Grund auf neu schreiben müssen.

Frage:

Muß ich all meine Dateien mit Weblint und dem HTML-Validator von HAL überprüfen? Das ist unheimlich viel Arbeit.

Antwort:

Sie müssen nicht, wenn Sie nicht die Zeit oder die Geduld haben. Aber ich kann es Ihnen nur immer wieder empfehlen, weil beide Programme unterschiedliche Funktionen bieten, die gleichermaßen wichtig sind. Weblint zeigt Ihnen die offensichtlicheren Fehler auf Ihren Seiten und bringt noch andere praktische Informationen. Es entdeckt beispielsweise fehlenden ALT-Text. HTML-Validator ist vollständiger, aber auch strenger. Er zeigt Strukturfehler in Ihren Dokumenten auf, aber die Fehlermeldungen sind extrem schwierig zu verstehen.


Copyright ©1998 by SAMS, einem Imprint der Markt&Technik Buch- und Software-Verlag GmbH.
Elektronische Fassung des Titels: HTML 4 in 14 Tagen, ISBN: 3-8272-2019-X


Top Of PageInhaltsverzeichnisInfoseite nächstes Kapitel