Seiten hinzufⁿgen und diese aktualisieren
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.
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 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://www.webtechs.com/html-val-svc/ k÷nnen Sie Ihre bereits ver÷ffentlichten Seiten interaktiv testen.
Abbildung 29.1: |
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).
Abbildung 29.2: |
|
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://www.webtechs.com/html-tk/. |
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.
Abbildung 29.3: |
Weblint
Abbildung 29.4: |
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.
Abbildung 29.5: |
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.
Abbildung 29.6: |
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 © 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: |
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: |
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:
Abbildung 29.9: |
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).
Abbildung 29.10: |
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.
Toll, sagen Sie. Sie kaufen das Programm und versuchen, Ihre HTML-Dateien einzulesen. Aber Ihre HTML-Dateien enthalten Fehler. Diese Fehler traten in den Browsern nie zutage, aber nichtsdestotrotz handelt es sich um Fehler. Da das Autorenwerkzeug nicht so nachsichtig ist wie die Browser (und das mu▀ sein bei den Funktionen, die es bietet), k÷nnen Sie Ihre Originaldateien nicht mehr lesen, bevor Sie sie nicht manuell korrigiert haben. Das kann dauern, wenn Sie in jeder Datei nur ein paar Fehler gemacht haben. Sie sparen sich also viel Zeit, wenn die Dateien von vorneherein korrekt sind.
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
