Rozdział 27.
Testowanie, poprawianie i aktualizowanie stron WWW

Po dokładnym przeczytaniu wcześniejszych rozdziałów tej książki, przystąpiłeś do tworze­nia własnej prezentacji WWW, w której poszczególne strony zostały połączone ze sobą, a gdzieniegdzie pojawił się obraz i jakiś formularz. Potem dodałeś jeszcze tabele i wyrów­nałeś obrazy, przekonwertowałeś niektóre z nich do formatu JPEG, dołączyłeś kilka fantas­tycznych sekwencji wideo prezentujących Ciebie i Twojego kota oraz skonfigurowałeś skrypt, który powoduje, że każde wejście w połączenie oznajmiane jest dźwiękiem dzwonka. Kaskadowe arkusze stylów nadają wszystkim tym wspaniałym stronom ładny, jednolity wygląd. Dynamiczny HTML nakłada grafikę na rysunki i tekst oraz naprawdę dodaje smaczku witrynie. Przyglądając się swemu dziełu, stwierdzasz, że jest po prostu świetne. Właściwie lepsze już być nie może. Wreszcie skończyłeś pracę.

Mam złe wieści. Do końca jeszcze kawałek drogi. Musisz popracować nad dwoma aspektami: przed Tobą testowanie i obsługa. Dzięki testowaniu uzyskujesz pewność, że Twoja witryna WWW działa, nie tylko z tech­nicznego punktu widzenia (czy kody HTML są poprawne, a połączenia prowadzą w odpo­wiednie miejsca), ale także pod względem użytkowym (czy użytkownicy znajdą na Twoich stronach to, czego szukają?). Istotna powinna być dla Ciebie kwestia czytelności prezentacji w różnych przeglądarkach, szczególnie wówczas, gdy korzystasz z najnowszych znaczników, które tu poznaliśmy.

Nawet, gdy wszystko zostanie już przetestowane i działa poprawnie, Twoja rola jeszcze się nie kończy. Już po opublikowaniu prezentacji zechcesz zapewne dodać do niej nowy ma­teriał i coś zmienić, by nieustannie była interesująca i aktualna. Uwierz mi, w sieci, gdzie wszystkie technologie nieustannie się zmieniają, żadna witryna nie jest nigdy rzeczywiście ukończona. Po prostu pewne strony rzadziej podlegają zmianom niż inne.

Po przeczytaniu tego rozdziału będziesz wiedział wszystko na poniższe tematy:

• testowanie poprawności — chodzi tu o upewnienie się, że strony WWW rzeczywiście działają,

• testowanie użyteczności, także pod względem skuteczności założonego przez Ciebie sposobu korzystania ze stron i spełniania przez nie założonych celów,

• dodawanie do witryn nowych stron oraz wprowadzanie poprawek na istniejących stronach, bez zaburzania konstrukcji prezentacji.

Test poprawności

Testowanie poprawności nie ma nic wspólnego z Tobą ani z Twoim formularzem podatko­wym. Chodzi tu o sprawdzenie, czy połączone ze sobą strony działają poprawnie, to znaczy, czy wyświetlane są bez błędów, a połączenia prowadzą pod właściwe adresy. Ten rodzaj testowania nie powie Ci nic o użyteczności stron i relacjach strona-użytko-wnik, dowiesz się tu jedynie, czy strony są poprawne technicznie. Oto kolejne etapy tego sposobu testowania:

1. sprawdź poprawność kodu HTML,

2. zobacz wygląd stron w wielu przeglądarkach,

3. przetestuj działanie połączeń (na samym początku i po kilku miesiącach).

Korekta kodu HTML

Pierwszy krok to sprawdzenie poprawności kodu HTML. Sprawdź, czy wszystkie znaczniki mają odpowiedniki zamykające, czy nie zazębiłeś pewnych znaczników lub nie użyłeś ich w obrębie innych, które nie działają.

Ale czy do tego nie służy sprawdzanie w przeglądarce? No cóż, niewątpliwie nie. Przeglą­darki są tak zaprojektowane, by umiały obejść pewne problemy, które ujawnią się w inter­pretowanych przez nie plikach HTML i wyświetlić to, o co Ci chodziło, a jeśli nie są w stanie określić Twoich zamierzeń, wyświetlić cokolwiek. (Czy pamiętasz ten przykład, w którym pokazany został wygląd tabeli w przeglądarce nieinterpretującej tabel? Tam wła­śnie przeglądarka starała się określić o co Ci chodziło.) Niektóre przeglądarki traktują błędy kodu HTML dość liberalnie. W jednej strona z błędami może działać poprawnie, a w innej wcale.

Ale istnieje tylko jedna prawdziwa definicja HTML i jest ona zawarta w specyfikacji HTML. Nawet w przypadku najbardziej wymagających przeglądarek, jeśli postać źródłowa stron jest poprawna, strony będą działały bezbłędnie we wszystkich przeglądarkach, które obsłu­gują daną wersję HTML.

W rzeczywistości, aby być całkowicie poprawnym, musisz znać definicję HTML-a określoną przez HTML DTD (Document Type Definition). HTML jest podzbiorem języka SGML używanego do definiowania różnorodnych języków znakowania. DTD to definicja języka w SGML, a więc HTML DTD definiuje HTML od strony technicznej.

Jak więc sprawdzić poprawność kodu HTML? Jeśli stosujesz się do zasad i przykładów, które przedstawiłam Ci w poprzednich rozdziałach, Twój kod HTML nie zawiera błędów. Wszyscy jednak zapominają o znacznikach zamykających, umieszczają znaczniki w nieod­powiednich miejscach i gubią zamykające cudzysłowy atrybutu HREF (mam z tym nieustannie kłopoty — „zawiesiłam” w ten sposób już wiele przeglądarek). Najlepszą metodą sprawdzenia poprawności stron jest przetestowanie ich za pomocą programu sprawdzającego poprawność kodu HTML.

Wiele edytorów HTML udostępnia obecnie możliwość sprawdzenia popraw­ności kodu HTML, a programy, takie jak HoTMetaL Pro (SoftQuad) ustrzegą Cię przed tworzeniem dokumentów zawierających błędy składniowe. Jednak w większości przypadków kontrola poprawności jest ograniczona i niepełna. Co więcej, pewne edytory nie tylko przepuszczają Twoje błędy w kodzie HTML, ale same generują takie błędy. Z tego względu skorzystanie z dodatkowego programu sprawdzającego poprawność kodu jest jak najbardziej wskazane.

Programy sprawdzające poprawność kodu HTML służą tylko i wyłącznie do tego celu. Nie ma tu znaczenia wygląd Twoich stron, ale jedynie to, czy jesteś w zgodzie z aktualną specyfikacją HTML. Niektóre z tych programów sprawdzają poprawność ze starszymi i nowszymi specyfikacjami HTML. Nowsze programy weryfikujące pozwalają na sprawdzenie zgodności kodu z trzema „gatunkami” HTML 4.0 lub XHTML 1.0 (ścisły, z ramkami bądź przejściowy).

Aby uzyskać kod HTML, który może być używany z następnymi generacjami narzędzi tworzenia stron, testowanie jego poprawności jest jak najbardziej potrzebne. Nie uśmiecha Ci się chyba ręczne poprawianie tysiąca stron, gdy pojawi się wreszcie ostateczne narzędzie tworzenia stron HTML, a Ty odkryjesz, że nie są one absolutnie przez nie czytane.

Oczywiście, nawet jeśli Twój kod HTML jest bez wątpienia poprawny, powinieneś testo­wać swoje strony w wielu przeglądarkach, aby upewnić się, że podjęte decyzje projektowe były właściwe. Stosowanie programu testującego poprawność kodu HTML nie wykaże błędów popełnionych przy projektowaniu stron.

W jaki sposób dotrzeć do programów sprawdzających poprawność kodu? Kilka jest dostęp­nych w sieci bądź w postaci plików, które możesz ściągnąć i uruchomić na swoim kompu­terze, bądź stron WWW, na których wprowadzasz w formularzu swój adres URL, a prog­ram testuje stronę poprzez sieć. Moimi ulubionymi programami są serwis sprawdzający HTML W3C i Weblint (autorstwa Neil Browsers).

Tak jak w przypadku wszystkich witryn WWW, te serwisy także ciągle się przeobrażają, wzbogacając się o nowe opcje i zmieniając swój wygląd. Nawet jeśli będą wyglądały inaczej niż na przedstawionych rysunkach, przykłady pozwolą Ci na zapoznanie się z istotą ich działania

W następnej części przedstawię kilka programów weryfikujących dostępnych w Internecie.

Istnieją również programy sprawdzające poprawność kodu, które można pobrać i uruchomić na swoim komputerze. Takim programem, działającym na platformie Windows 95/NT, jest CSE 3310 HTML Validator. Program ten pomaga w wyszukiwaniu i przezwyciężaniu różnych problemów związanych z HTML-em, takich jak przekręcone lub nieprawidłowe nazwy znaczników, nieprawidłowe atrybuty lub wartości, brakujące cytaty, brakujące znaczniki zamykające, nieprawidłowe rozmieszczenie lub zagnieżdżenie znaczników i wiele innych. Więcej o tym programie można przeczytać na jego stronie domowej dostępnej pod adresem http://www.htmlvalidator.com/. Można tam również pobrać darmową wersję testową programu, posiadającą nieco mniejsze możliwości, jest ona dostępna pod adresem:

http://www.htmlvalidator.com/htmldownload.html.

Weblint

Nieco bardziej ogólnym programem kontrolującym poprawność HTML-a jest Weblint. Op­rócz sprawdzania poprawności składni, wyszukuje on także niektóre powszechnie popełnia­ne błędy: niewłaściwie zastosowane znaczniki zamykające, umieszczone poza sekcją HEAD znaczniki TITLE, powtarzające się elementy, które powinny wystąpić tylko raz, itp. Próbuje także naprowadzić Cię na inne możliwe nieprawidłowości, na przykład, pytając, czy umieściłeś atrybut ALT w znaczniku <IMG>. Podsumowanie testu jest zdecydowanie przyjaźniejsze niż w przypadku poprzedniego programu, aczkolwiek zgodność z HTML-em nie jest tu rygorystycznie respektowana (w zasadzie program oprotestowałby nowsze znaczniki, takie jak tabele i inne dodatki HTML).

Na rysunku 27.1 pokazana jest strona Weblint, którą możesz znaleźć pod adresem http://www.unipress.com/cgi-bin/WWWeblint. Prezentuje ona formularz służący do przesyłania stron do testowania.

Rysunek 27.1. Serwis testujący Weblint

Serwis Weblint pozwala zarówno na przetestowanie kodu HTML wklejonego do pola formularza, jak i strony opublikowanej w Internecie. Jeśli chciałbyś zobaczyć, co Weblint może powiedzieć o Twoim kodzie HTML, wpisz poniższy przykład w polu DATA formularza. W przykładzie pominięto otwierający znacznik <p>, choć akapit został zamknięty za pomocą znacznika <p>:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN "http://www.w3.org/TR/xhtml1/DTD/transitional.dtd">

<html>

<head>

<title>Sprawdzanie poprawnosci kodu HTML</title>

</head>

Co jakis czas zdarza mi sie, ze odczuwam nagle pragnienie bycia zabawnym. Na szczescie dla otoczenia, zazwyczaj przechodzi mi to po kilku minutach. Czasem jednak zaczynam pisac... </p>

</body>

</html>

Jak widać na rysunku 27.2, nasz przykładowy kod powoduje wypisanie informacji o brakującym znaczniku <p>.

Rysunek 27.2. Podsumowanie testu Weblint

Weblint nie jest już bezpłatnym serwisem. Za całoroczną subskrypcję trzeba zapłacić 16.95 dolara, a za półroczną, 9.95 dolara. Bezpłatnie dostępna jest jednak wersja próbna, testująca jedynie 2 048 bajtów (jej sto­sowanie kończy się wygenerowaniem pewnych fikcyjnych błędów, ze względu na brakujące znaczniki obecne w pozostałej części dokumentu).

Serwis testujący W3C HTML

Wśród wielu serwisów testujących zgodność kodu ze standardem HTML 4.0 istnieje tylko kilka zgodnych z XHTML 1.0. Najlepszym źródłem sprawdzania poprawności kodu stron WWW jest serwis W3C HTML Validation Service, znajdujący się pod adresem http://validator.w3.org/. Serwis ten pozwala na sprawdzenie zgodności kodu HTML z różnymi definicjami typów dokumentu i, co więcej, jest on darmowy. Można również za jego pomocą sprawdzić różne typy „oficjalnych” standardów HTML (łącznie z HTML 4.01 i XHTML 1.0) oraz poprawność kodu dostosowanego do przeglądarki Internet Explorer bądź Netscape. Spis wszystkich formatów dokumentów, z którymi może zostać sprawdzona zgodność kodu, znajduje się pod adresem:

http://validator.w3.org/sgml-lib/catalog.

Aby skorzystać z tego serwisu testującego, wpisz w polu Location adres URL witryny, którą chcesz sprawdzić, tak jak przedstawiono to na rysunku 27.3 (w chwili pisania tych słów nie było możliwości sprawdzenia poprawności wklejonego kodu ).

Rysunek 27.3. Formularz serwisu testującego W3C HTML

Po wpisaniu adresu URL swojej witryny można wybrać jedną lub więcej następujących opcji:

• Show source input (Pokaż dane wejściowe) — Opcja powoduje dołączenie wydruku kodu źródłowego sprawdzanego przez serwis. Pozwala to na łatwiejsze ustalenie dokładnego miejsca wystąpienia błędu, ponieważ do kodu źródłowego są dołączone numery wierszy, do których odnoszą się informacje o błędach zwrócone przez serwis;

• Show an outline of this document (Pokaż zarys dokumentu) — Jeśli na stronie znajdują się nagłówki, zaznaczenie tej opcji spowoduje zwrócenie informacji o strukturze nagłówków dokumentu. Jest to użyteczna opcja pozwalająca stwierdzić, czy struktura nagłówków jest zgodna ze strukturą standardową (H2 poniżej H1, H3 poniżej H2 itd.);

• Show parse tree (Pokaż drzewo przetwarzania) — Zwraca informacje pozwalające określić strukturę znaczników HTML w dokumencie;

• Exclude atributes from the parse tree (Wyłącz atrybuty z drzewa przetwarzania) — Po zaznaczeniu tej opcji atrybuty zostaną wyeliminowane z wyświetlanego drzewa, dzięki czemu wydruk zyska na przejrzystości.

Ćwiczenie 27.1: Sprawdzenie poprawności przykładowej strony

Aby zaprezentować rodzaje błędów wychwytywane przez serwisy W3C i Weblint, przygotujmy plik testowy zawierający najczęściej popełniane błędy. Jako podstawę naszego eksperymentu potraktujemy stronę Ogród kaktusów Zuzanny, przedstawioną na rysunku 27.4.

Rysunek 27.4. Strona Ogród kaktusów Zuzanny

W przeglądarce Internet Explorer strona ta wygląda dość dobrze. Poniższy kod jednak jest pełen błędów. Sprawdź, ile z nich jesteś w stanie znaleźć na własną rękę, zanim sprawdzisz poprawność kodu za pomocą programu.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/transitional.dtd">

<html>

<head>

<title>Ogród kaktusów Zuzanny</title>

<head>

<body>

<strong>Ogród kaktusów Zuzanny</strong>

<h1>Wybór i zamawianie roślin</h3>

<ul>

<h3>

<li><a href="browse.html">Obejrzyj nasz katalog

<li><a href="order.html>Jak zamowic</a>

<li><a href="form.html">Formularz zamówienia</a>

</ul>

</h3>

<hr width=70% align=center>

<h1>Informacje o kaktusach i sukulentach</h1>

<ul>

<li><a href="succulent.html">Co to są sukulenty?</a>

<li><a href="caring.html">Jak dbac o kaktusy i sukulenty?</a>

<li><a href="propogation.html">Jak propagować hodowlę kaktusów i sukulentów?</A>

</ul>

<hr>

<address>Copyright &copy; 2001 Ogród kaktusów Zuzanny [e-mail]</address>

Teraz opublikuj tę stronę w Internecie i zapisz jej adres. Przejdź do serwisu sprawdzania poprawności kodu W3C HTML Validator pod adresem http://validator.w3.org/ i wpisz adres naszej „złej” strony w polu Location formularza. Zaznacz opcję Show Source Input (co powinno pomóc przy określaniu pozycji błędów) i kliknij przycisk Validate URL. Chwilę później na ekranie pojawi się wydruk informacji o błędach, przy-pominający to, co można zobaczyć na rysunku 27.5.

Rysunek 27.5. Odpowiedź serwisu sprawdzającego W3C nadesłana po przeanalizowaniu dokumentu zawierającego błędy

Rozpocznij od błędów zgłoszonych przez serwis Weblint, gdyż generowane przez niego komunikaty są bardziej zrozumiałe niż te, które generuje W3C HTML Validation Service. Gdy przejrzysz listę błędów zgłoszonych przez serwis Weblint, znajdziesz w niej następujące błędy odszukane w 6. i 7. wierszu kodu:

line 6: <HEAD> must immediately follow <HTML>

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

line 6: <HEAD> cannot appear in the HEAD element.

line 7: <BODY> must immediately follow </HEAD|NOFRAMES|/FRAMESET>

line 7: <BODY> cannot appear in the HEAD element.

Oto raz jeszcze fragment kodu, linie od 1. do 7.:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/transitional.dtd">

<html>

<head>

<title>Ogród kaktusów Zuzanny</title>

<head>

<body>

W szóstym wierszu zamiast znacznika <HEAD>, powinien być znacznik </HEAD>. Jeśli za­pomnisz o zamykającym znaczniku </HEAD>, niektóre przeglądarki mogą mieć kłopoty z interpretacją dokumentu.

Po poprawieniu tego błędu, z listy znikną wszystkie komunikaty typu:

X cannot appear in the HEAD element.

Następny błąd odnaleziony przez Weblint znajduje się w linii 9., oto komunikat o tym błędzie:

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

Ten błąd jest bardzo prosty do poprawienia. Autor strony przez pomyłkę zakończył element <H1> znacznikiem zamykającym </H3>. Znacznik zamykający musi odpowiadać znacznikowi otwierającemu, a zatem należy zastąpić znacznik </H3> znacznikiem </H1>.

Wynik zwrócone przez serwis Weblint nie zawierają żadnego komentarza na temat linii 10., choć powinien on być oczywisty. Jednak pod koniec listy błędów znajduje się komunikat, który może nam pomóc w rozwiązaniu tego problemu, oto on:

line 10: no closing </UL> seen for <UL> on line 10.

Gdy spojrzysz na 15. linię kodu, znajdziesz w niej zamykający znacznik </UL>. A zatem, na czym polega problem? Przyjrzyj się dokładnie liniom od 10. do 16., zauważysz zapewne, że znaczniki <UL> oraz <H3> nie zostały poprawnie zagnieżdżone. Kod ma następującą postać:

<ul>

<h3>

<li><a href="browse.html">Obejrzyj nasz katalog

<li><a href="order.html>Jak zamowic</a>

<li><a href="form.html">Formularz zamówienia</a>

</ul>

</h3>

Gdy zamienisz kolejność znaczników <UL> i <H3>, błąd powinien zniknąć. Poprawiony fragment kodu powinien mieć następującą postać:

<h3>

<ul>

<li><a href="browse.html">Obejrzyj nasz katalog

<li><a href="order.html>Jak zamowic</a>

<li><a href="form.html">Formularz zamówienia</a>

</ul>

</h3>

Kontynuujmy dalej poprawianie błędów związanych z powyższą listą wypunktowaną. Kolejny odszukany błąd znajduje się w linii 13. i jest związany z nieparzystą ilością cudzysłowów:

line 13: odd number of quotes in element <a href="order.html>.

Zauważ, iż po nazwie pliku order.html nie ma znaku cudzysłowu. Taki kod działałby poprawnie w przeglądarkach Netscape oraz Internet Explorer, lecz w wielu innych przeglądarkach stwarzałby problemy. Błędy tego typu są jednymi z najczęściej popełnianych. Poniżej przedstawiłam poprawną wersję 13. linii kodu:

<li><a href="order.html">Jak zamowic</a>

W liniach 13. i 14. znajdują się kolejne dwa błędy:

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

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

W rzeczywistości błąd został popełniony w linii 12.

<li><a href="browse.html">Obejrzyj nasz katalog

Jak widać, na końcu linii nie ma zamykającego znacznika </A> i to tłumaczy problem. Nie można umieścić znacznika <A> wewnątrz innego znacznika <A>. W liście zgłoszonych błędów znajdziesz kilka błędów tego typu. Pamiętaj, aby zawsze umieszczać zamykające znaczniki </A> na końcu tekstu stanowiącego treść połączenia. Poprawienie tego błędu spowoduje zniknięcie błędu odnoszącego się do linii 18., który dotyczy faktu, iż znacznik <A> powinien być zagnieżdżony w znaczniku <H1>, a nie na odwrót. Znikną także błędy odnoszące się do linii 20., 21. i 22., informujące, że znaczników <A> nie wolno zagnieżdżać. Wszystkie one są spowodowane pominięciem zamykającego znacznika </A>, który powinien się znaleźć na końcu linii 12.

line 17: attribute "WIDTH" for <hr> is extended markup.

line 17: value for attribute WIDTH (70%) of element HR should be quoted (i.e. WIDTH="70%")

line 17: attribute "ALIGN" for <hr> is extedned markup.

line 17: illegal value for WIDTH attribute of hr (70%).

Określenie „extended markup” oznacza zazwyczaj rozszerzenie specyfikacji HTML, charakterystyczne dla jakieś przeglądarki. Jednak określenie to może także oznaczać znaczniki, które zostały uznane za przestarzałe w ścisłej specyfikacji języka HTML. Jeśli Weblint zgłosi informacje o przestarzałych znacznikach, porównaj je ze zgłoszonymi przez serwis W3C HTML Validation. Jeśli korzystasz ze specyfikacji HTML 4.0 lub XHTML 1.0 Transitional, które pozwalają na wykorzystanie rozszerzeń, to decyzja, czy pozostawić te problematyczne fragmenty kodu, należy do Ciebie. Jeśli jednak używasz specyfikacji HTML 4.0 lub XHTML 1.0, to takie komunikaty o pojawieniu się rozszerzeń HTML, mogą stanowić ostrzeżenie, aby zmienić postać kodu. W przypadku atrybutu WIDTH, można go zastąpić właściwościami kaskadowych arkuszy stylów.

Jeśli się zdecydujesz pozostawić atrybut WIDTH znacznika <HR>, to pamiętaj, by zapisać jego wartość pomiędzy znakami cudzysłowu. Choć Weblint nie zgłosił żadnych uwag dotyczących wartości CENTER atrybutu ALIGN, to także ją powinieneś zapisać w cudzysłowach. Poprawiona linia 17. powinna wyglądać w następujący sposób:

<hr width="70%" align="center">

Wszystkie pozostałe błędy są podobne i dotyczą brakujących znaczników zamykających:

line 0: No closing </HTML> seen for <HTML> on line 1.

line 0: No closing </HEAD> seen for <HTML> on line 2.

line 0: No closing </HEAD> seen for <HTML> on line 4.

line 0: No closing </BODY> seen for <HTML> on line 5.

line 0: No closing </UL> seen for <HTML> on line 8.

line 0: No closing </H3> seen for <HTML> on line 9.

line 0: No closing </A> seen for <HTML> on line 10.

Szybkie sprawdzenie kodu strony pozwala stwierdzić, iż na jej końcu brakuje znaczników zamykających </BODY> oraz </HTML>, co wyjaśnia problem. Pozostałe błędy znikną po zamienieniu drugiego znacznika <HEAD> na </HEAD> oraz znacznika </H3> na </H1>.

Czego jednak dotyczą pozostałe dwa błędy? Weblint informuje, że znaczniki <UL> i <H3> nie mają odpowiednich znaczników zamykających, lecz znaczniki te znajdują się w kodzie, pod koniec listy. Spójrz jednak na kolejność, w jakiej znaczniki zostały zapisane. Zamienienie ich rozwiąże ten problem.

Ostatni błąd dotyczy brakującego znacznika zamykającego </A>, który już wcześniej dopisaliśmy.

W porządku. Poprawiliśmy błędy zgłoszone przez serwis Weblint. Poniżej przedstawiona została poprawiona wersja kodu:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/transitional.dtd">

<html>

<head>

<title>Ogrod kaktusow Zuzanny</title>

</head>

<body>

<strong>Ogrod kaktusow Zuzanny</strong>

<h1>Wybór i zamawianie roslin</h1>

<h3>

<ul>

<li><a href="browse.html">Obejrzyj nasz katalog</a>

<li><a href="order.html">Jak zamowic</a>

<li><a href="form.html">Formularz zamówienia</a>

</ul>

</h3>

<hr width="70%" align="center">

<h1>Informacje o kaktusach i sukulentach</h1>

<ul>

<li><a href="succulent.html">Co to sa sukulenty?</a>

<li><a href="caring.html">Jak dbac o kaktusy i sukulenty?</a>

<li><a href="propogation.html">Jak propagować hodowle kaktusow i sukulentow?</A>

</ul>

<hr>

<address>Copyright &copy; 2001 Ogrod kaktusow Zuzanny

[e-mail]</address>

</body>

</html>

A teraz sprawdźmy tę stronę jeszcze raz. Rysunek 27.6 pokazuje, że W3C HTML Validator odnalazł na niej kilka błędów. W rzeczywistości jest ich całkiem sporo.

W czasie publikacji niniejszej książki serwis Weblint nie zgłaszał błędów związanych ze specyfikacją XHTML 1.0. Błędy te są natomiast zgłaszane przez W3C HTML Validation Service. Aby zmniejszyć ilość zgłaszanych błędów związanych z niezgodnościami ze specyfikacją XHTML 1.0, wykonaj szybkie sprawdzenie i upewnij się, że wszystkie znaczniki zostały poprawnie zamknięte. W szczególności zwróć uwagę, iż w kodzie przedstawionym przed rysunkiem 27.6, żaden z sześciu znaczników <LI> nie został zamknięty.

Rysunek 27.6. Wyniki sprawdzenia poprawionej wersji strony, zwrócone przez W3C HTML Validation Service

Znaczniki te są umieszczone w liniach od 12. do 14. oraz od 22. do 24. Poprawnie powinny one mieć następującą postać:

<li><a href="browse.html">Obejrzyj nasz katalog</a></li>

<li><a href="order.html">Jak zamowic</a></li>

<li><a href="form.html">Formularz zamówienia</a></li>

oraz

<li><a href="succulent.html">Co to sa sukulenty?</a></li>

<li><a href="caring.html">Jak dbac o kaktusy i sukulenty?</a></li>

<li><a href="propogation.html">Jak propagować hodowle kaktusow i sukulentow?</a></li>

Co więcej, w liniach 17. oraz 24. zostały zapisane znaczniki <HR>, które także należy poprawnie zakończyć:

<hr width="70%" align="center" />

<hr />

Gratuluję! Teraz strona o kaktusach i sukulentach jest wreszcie zgodna ze specyfikacją HTML, a wymagało to jedynie użycia dwóch programów!

Oczywiście, przykład stanowił pewne ekstremum. Zazwyczaj na Twoich stronach nie będzie aż tylu uchybień (a jeśli korzystasz z edytora HTML, wiele błędów w ogóle się nie po­jawi). Dla Netscape żaden z tych błędów nie stanowił problemu, ale czy inne przeglądarki będą aż tak liberalne?

Testowanie w przeglądarkach

Jak wspomniałam wcześniej, programy sprawdzające poprawność kodu HTML nie zajmują się poprawnością projektu. Po zakończeniu testów poprawności HTML, powinieneś prze­testować swoje strony w tylu przeglądarkach, do ilu masz dostęp, aby sprawdzić wygląd stron w różnych środowiskach. Większość przeglądarek jest bezpłatna i bez trudu można je ściągnąć, postaraj się więc zgromadzić na swoim komputerze dwie lub trzy.

Idealnie byłoby, gdybyś wszystkie swoje strony testował przynajmniej w trzech przeglądar­kach. Zastosuj:

• Netscape lub Microsoft, z włączoną i wyłączoną opcją wyświetlania obrazów,

• którąś z wymienionych tu przeglądarek: Oper, Mosaic,

• jakąś przeglądarkę tekstową, na przykład, Lynx.

Testy te pozwolą Ci uzyskać wyobrażenie o wyglądzie stron w różnych przeglądarkach. Jeśli stosujesz na stronach rozszerzenia Netscape lub Microsoft, możesz przetestować stro­ny zarówno w przeglądarce Netscape, jak i w Internet Explorer, aby przekonać się, czy w obu przeglądarkach wyglądają równie dobrze.

Sprawdzanie połączeń

Trzecim i ostatnim testem jest test działania połączeń. Najprościej usiąść przy komputerze i samemu podążać kolejnymi połączeniami. Ta metoda nadaje się do niewielkich pre­zentacji, ale w przypadku dużych jest czasochłonna i nużąca. Poza tym, nawet po sprawdzeniu połączeń, może się okazać, że pewne witryny, do których prowadzą połączenia, zmieniły adres lub nazwy swoich stron — sieć ciągle się przecież przeobraża. W takim wypadku połączenia przestaną działać, chociaż na Twoich stronach nic się nie zmieniło.

Informacje na temat takich niedziałających połączeń możesz znaleźć w raportach o błę­dach, które są przechowywane na serwerze. Raporty odnotowują strony, które nie mogą być odnalezione, przy czym podawana jest zarówno poszukiwana strona, jak i strona zawierająca połączenie do niej prowadzące. Oczywiście, aby połączenie pojawiło się w raporcie, ktoś wcześniej musiał bezskutecznie nim podążać. Lepiej wyprzedzić tu czytelnika i samemu wychwycić wcześniej zerwane połączenia.

Najlepszym sposobem weryfikacji odnośników jest zastosowanie programu do automatycznej ich kontroli. Program ten przegląda poszczególne strony Twojej witryny i sprawdza, czy umieszczone w nich odnośniki wiodą do istniejących plików lub witryn. Istnieje wiele tego typu programów, łącznie z programami — pająkami ogólnego zastosowania, przeglądającymi w ten sposób od odnośnika do odnośnika całą sieć. Za ich pomocą można zweryfikować poprawność odnośników na swojej witrynie, ale należy być przy tym bardzo ostrożnym, by nie wymknęły się do innych witryn. Dobrym przykładem programu tego typu jest MOMspider dostępny pod adresem:

http://www.ics.uci.edu/WebSoft/MOMSpider/).

Jeśli posiadasz bardzo dużą witrynę, ręczne sprawdzanie działania wszystkich odnośników nie wchodzi w rachubę. Na szczęście wiele programów usprawniających tworzenie stron WWW posiada opcję sprawdzania, czy wszystkie odnośniki na stronach danej witryny działają prawidłowo. Jednym z programów umożliwiających skontrolowanie poprawności odnośników zewnętrznych i wewnętrznych na stronach witryny jest Microsoft FrontPage.

Można również skorzystać z osobnego programu sprawdzającego odnośniki, takiego jak, na przykład, LinkBot firmy Tetranet Software, który pomoże Ci zweryfikować poprawność i utrzymać wszystkie odnośniki na stronach witryny. Program ten wyszukuje niedziałające odnośniki, nieprawidłowe odwołania do rysunków i wiele więcej. Więcej informacji można znaleźć na jego stronie domowej dostępnej pod adresem:

http://tetranetsoftware.com/.

Testowanie użyteczności strony

Tego typu testy służą sprawdzaniu użyteczności strony, której poprawność techniczna już została zbadana. Możesz z łatwością stworzyć mnóstwo stron WWW, ale czy Twoi czytel­nicy będą w stanie znaleźć na nich to, czego potrzebują? Czy pod względem organizacyj­nym strony spełniają przyjęte założenia? A może czytelnicy czują się na nich zdezoriento­wani lub sfrustrowani trudnościami nawigacji?

Testowanie użyteczności to pomysł realizowany od lat przez wiele firm. Opiera się on na teorii, która mówi, że projektanci tworzący produkt (może to być aplikacja, magnetowid, samochód lub cokolwiek) nie są w stanie wiarygodnie określić, czy jest on prosty w użyciu; są bowiem zbyt zaangażowani w jego produkcję. Znają dokładnie projekt, w oparciu o któ­ry produkt powstał, potrafią więc bez trudu posługiwać się wyprodukowanym tworem. Jedynym sposobem jest więc wyręczenie się ludźmi, którzy z produktem wcześniej nie mieli do czynienia i obserwowanie, w jakich sytuacjach pojawiają się kłopoty z obsługą. W oparciu o te obserwacje produkt może być doskonalony.

Witryny WWW są doskonałymi przykładami produktów, które wiele mogą zyskać na testowaniu ich użyteczności. Nawet krótki rzut oka Twojego przyjaciela może być dob­rym testem organizacji stron i łatwości znajdowania informacji.

Oto pewne zadania, które możesz zlecić osobom testującym Twoje strony:

• niech przeglądają strony bez specjalnego celu — przyglądaj się, gdzie się przemieszczają, co ich interesuje przede wszystkim, jakimi ścieżkami podążają. Zapamiętaj, na których stronach częściej się zatrzymują, a które przeskakują;

• niech znajdą konkretny temat lub stronę, najlepiej taką, która jest głęboko ukryta
  — obserwuj efekty poszukiwań: jaką ścieżką pójdą, by znaleźć stronę, ile czasu im to zajmie, czy poszukiwania są frustrujące;

• niech przedstawią swoje sugestie — użytkownicy mają swoje zdanie na temat oglądanych stron, ale prawdopodobnie nie prześlą Ci listu e-mail, nawet jeśli ich o to poprosisz. Spytaj osoby testujące stronę, w jaki sposób, według nich, można by ją poprawić.

Usiądź z osobą testującą i przyjrzyj się notatkom. Rezultaty mogą Cię zadziwić i natchnąć nowymi pomysłami dotyczącymi organizacji stron.

Studiowanie raportów

Inną metodą testowania użyteczności dokumentów już opublikowanych w sieci jest śledze­nie zawartości przechowywanych na serwerze. Twój serwer WWW lub dostawca przecho­wują raporty rejestrujące wszystkie trafienia na Twoją stronę (ilekroć przeglądarka odszu­kuje ten dokument) i miejsca, z których pochodzą. Studiując te raporty, dowiesz się paru interesujących rzeczy:

• Które strony są najpopularniejsze? Mogą to być strony, których o to nie podejrzewasz. Możesz wówczas ułatwić znajdowanie tych stron, umieszczając połączenia do nich na stronie głównej witryny;

• Jakie są sposoby przeglądania Twoich stron, w jakim porządku są one czytane?

• Jakie błędy popełniają ludzie, gdy starają się dotrzeć do Twoich stron. Szukane, ale nie znalezione pliki zostaną umieszczone w plikach błędów (są one zawarte w tym samym katalogu, co pliki raportów). Stosując symboliczne połączenia lub zamienniki, mógłbyś obejść pewne problemy, jeśli są one częste.

Uaktualnianie prezentacji
i dodawanie nowych stron

Nawet po opublikowaniu stron i dokładnym ich przetestowaniu na wszystkie sposoby, Twoja praca nad witryną nie jest jeszcze zakończona. Powiedziałabym wręcz, że ona nigdy się nie skończy. Choćby prezentacja była dopracowana w najdrobniejszych szczegółach, zawsze pojawiają się nowe informacje i nowe strony, które trzeba dodać oraz nowinki techniczne HTML-a, które trzeba wypróbować.

Jak więc obsługiwać prezentację? To proste. Tworzysz nowe strony i łączysz je ze starymi. Zanim jednak do tego przystąpisz, przeczytaj ten podrozdział. Z niego dowiesz się, jak to zrobić najlepiej.

Dodawanie nowej zawartości

Rozpocznijmy ten podrozdział od takiej oto opowieści.

W San Jose, w Kalifornii, znajduje się atrakcja turystyczna o nazwie Winchester Mystery House. Należała ona do Sary Winchester — spadkobierczyni fortuny Strzelców z Winchester. Opowieść głosi, że po śmierci męża i córki wróżka powiedziała jej, że duchy tych, którzy zginęli z produkowanej przez nich broni, straszą ją i jej rodzinę. Wróżka doradziła jej, aby nieustannie dobudowywać nowe pokoje i w tej sposób przechytrzyć duchy.

Dobudówki były „dolepiane” do istniejącej budowli lub do poprzednich dobudówek bez ładu i składu, a na dodatek bez końca. Powstało w ten sposób ponad 160 pokoi, klatki schodowe, które prowadzą donikąd, drzwi otwierające się na ściany i sekretne przejścia. Plan piętra jest tak skomplikowany, że poruszanie się bez mapy jest praktycznie niemożliwe.

Niektóre prezentacje WWW wyglądają podobnie jak ten tajemniczy dom. Być może miały na początku dobrze przemyślaną i zorganizowaną strukturę, ale wraz z narastaniem w pre­zentacji liczby stron, zaczęła się ona załamywać, a zasadnicze cele zagubiły się. W rezul­tacie powstał zlepek pomieszanych połączeniami stron, w którym czytelnicy od razu się gubią (patrz rysunek 27.7).

Rysunek 27.7. Tak wygląda układ stron, w którym nadrzędny jest tylko bałagan

Unikaj projektowania stron w duchu dworu Winchester. Dodając nowe strony do istniejącej prezentacji, przestrzegaj takich oto reguł:

• Trzymaj się struktury. Jeśli dotychczas stosowałeś się do podawanych wskazówek, Twoja prezentacja powinna mieć strukturę hierarchiczną lub liniową. Wówczas, w większości wypadków, dodawanie nowego materiału nie sprawia kłopotów — pojawia się on w logicznym umiejscowieniu. Dodając strony, staraj się zachować strukturę wyjściową;

• Skup się na swoich celach. Dodając nową zawartość, miej na względzie cele wyjściowe. Jeśli nowe treści odciągną od nich uwagę lub będą wręcz kolidować, zrezygnuj z nich lub zbagatelizuj ich obecność. W przypadku zmiany celów prezentacji lepiej zrewidować ją całą, niż wklejać fragmenty nowego materiału;

• Jeśli to konieczne, wprowadź rozgałęzienia. Czasami łatwiejszym sposobem dodania nowego materiału, a szczególnie w przypadku struktury hierarchicznej, jest dołączenie całkowicie nowej prezentacji podrzędnej, zamiast rozbudowywania zawartości. Jeśli dodawany materiał może być przedstawiony w postaci samodzielnej prezentacji, rozważ taką możliwość.

Rewidowanie struktury

Zdarza się, że prezentacja tak się rozbuduje, że wyjściowa struktura przestaje być wydolna. Może się również zdarzyć, że założone cele prezentacji przestają być aktualne, a wyjściowa organizacja utrudnia dostęp do nowego materiału. Nie jest też wykluczone, że rozpoczyna­jąc pracę nad prezentacją, nie myślałeś nad jej strukturą, ale teraz dochodzisz do wniosku, że jest Ci ona potrzebna.

Witryny WWW opierają się na organizacji. Wynika stąd fakt, iż jeśli zmienisz znacząco samą prezentację, będziesz musiał zmodyfikować także jej plan czy strukturę. Mam nadzie­ję, że nie będziesz musiał zaczynać od zera. Często można tak zmienić fragmenty prezen­tacji, że nowy materiał pasuje do zwalnianego miejsca, dzięki czemu struktura prezentacji nie jest zaburzana.

Czasem dobrze jest cofnąć się do wyjściowego planu (stworzyłeś taki, nieprawdaż?) i za­cząć od zrewidowania go, abyś wiedział, jakie są Twoje cele. Daję Ci pod rozwagę takie oto sugestie:

• wymień cele prezentacji. Wylicz sposoby korzystania z prezentacji przez użytkowników i określ, jak, Twoim zdaniem, ma być ona postrzegana. Porównaj nowe cele ze starymi. Jeśli się różnią, zastanów się nad sposobami zmodyfikowania tego, czym dysponujesz, aby pomóc czytelnikom;

• zmodyfikuj listę tematów. Jest to najtrudniejszy etap, bowiem może okazać się konieczne przemieszczenie pewnych partii materiału. Staraj się pamiętać, które z tematów są nowe, a które stare, pomoże Ci to, gdy rozpoczniesz pracę nad edycją stron;

• zastanów się nad zmianą struktury, jeśli obecna się nie sprawdza. Jeśli prosta struktura wyjściowa obecnie stała się zbyt złożona, by łatwo w niej nawigować, pomyśl o narzuceniu na prezentację sztywnej struktury. W przypadku płytkich struktur hierarchicznych (niewiele poziomów, ale wiele opcji na stronie głównej), rozważ ich zrównoważenie (więcej poziomów, mniej opcji).

Po stworzeniu nowego planu, bez trudu zorientujesz się, w jaki sposób przemieścić materiał, by prezentacja stała się czytelniejsza. Wszystkie wprowadzane zmiany powinny być realizowane w oparciu o ten właśnie plan. Nie spiesz się z ich wprowadzaniem i nie rób zbyt wielu rzeczy naraz. Ryzykujesz bowiem zerwanie połączeń oraz utratę orientacji. Jeśli strony były testowane pod względem użyteczności, przekształcając prezentację, weź pod uwagę wnioski, jakie wynikły z tych doświadczeń.

Podsumowanie

Planowanie, pisanie, testowanie i obsługa to czterej jeźdźcy projektowania strony WWW. Wcześniej poznałeś planowanie i pisanie, poczynając od struktury, tworzenia stron, połą­czeń i dopracowywania całości. Ten rozdział poświęcony był drugiej połowie procesu, tej, która obejmuje także opublikowaną stronę, tłumnie odwiedzaną przez czytelników.

Testowanie stron to upewnianie się, że będą one działały poprawnie. Możesz zdecydować się na zredukowane do minimum testy w jednej lub w dwóch przeglądarkach, sprawdzenie połączeń i skryptów CGI, ale poznałeś przecież prawdziwe testowanie. Jest to proces, w którym specjalne programy badają poprawność kodu HTML, inne kontrolują auto­matycznie poprawność połączeń, a Twoim zadaniem jest zbadanie stron pod kątem użyteczności dla czytelników.

Procesy obsługi obejmują uaktualnianie prezentacji oraz zapewnienie jej popraw­nego działania bez względu na wprowadzane zmiany. Nadrzędną ideą jest trzymanie się wyjściowego planu i unikanie przesłaniania starych treści nowymi. A czasami oznacza to zało­żenie nowej struktury i nowego zestawu stron. W rozdziale zaproponowałam Ci także parę sugestii dotyczących obsługi i modyfikacji materiału.

Teraz skończyłeś pracę. Do czasu, gdy przyjdzie pora na zmienianie wszystkiego od począ­tku. Dużo się nauczyłeś, czytając kilka ostatnich rozdziałów, teraz jesteś już gotów, by tworzyć własne witryny WWW. Kreując je, nie zapominaj, że najważniejsze jest, by mieć z tego satysfakcję i jednocześnie dobrze się przy tym bawić.

Warsztat

I tak oto zbliżasz się do końca książki, uzbrojony w pełen asortyment informacji o tworzeniu, reklamie oraz publikacji stron WWW w Internecie. Ostatni warsztat zawiera kilka pytań dotyczących sprawdzania poprawności kodu HTML oraz quiz i ćwiczenia, które pomogą Ci zachować wiedzę nabytą w trakcie pracy z niniejszą książką.

Pytania i odpowiedzi

P. Ciągle nie rozumiem dlaczego sprawdzanie poprawności HTML-a jest takie istot­ne? Testuję swoje strony w wielu przeglądarkach. Po co mi dodatkowa robota, by kod był całkowicie zgodny ze specyfikacją? Jakie to ma znaczenie?

O. No, cóż. Popatrz na to w ten sposób: wyobraź sobie, że w przyszłym roku kompania sieciowa Z wchodzi na rynek z fantastycznym narzędziem projektowania stron WWW. Dzięki niemu będziesz mógł szybko i łatwo tworzyć swoje strony, łączyć je ze sobą, bu­dować hierarchie, które można przebudowywać i robić ze stronami wszystkie te wspa­niałe rzeczy, które teraz są bardzo trudne do osiągnięcia. Narzędzie to będzie czytało Twoje stare pliki HTML, nie będziesz więc musiał zaczynać od zera.

Wspaniale, powiesz. Kupujesz program i starasz się nim przeczytać swoje dokumenty HTML. Pliki mają jednak błędy. Nie ujawniły się one w przeglądarce, ale mimo wszyst­ko są to błędy. Ponieważ narzędzie jest bardziej restrykcyjnie niż przeglądarki (i musi takie być), nie możesz wczytać swoich plików bez wcześniejszego rę­cznego poprawie­nia błędów. Jeśli w każdym z plików popełniłeś ich kilkanaście, proces poprawiania potrwa bardzo długo, a można było tego uniknąć, pisząc strony poprawnie.

P. Czy wszystkie moje pliki muszę poddawać kontroli przez W3C Validator i Weblint? To jest okropnie dużo pracy.

O. Nie musisz stosować obu programów, jeśli nie masz na to czasu ani chęci. Ale ja nie od­ważę się zarekomendować któregoś z nich, ponieważ możliwości tych programów są różne, ale jednakowo istotne. Weblint wykazuje na sprawdzanej stronie większość oczy­wistych błędów i wykonuje inne cenne zadania, takie jak wskazanie braku atrybutu ALT. HTML Validator ma więcej możliwości, ale jest także bardziej restrykcyjny. Wykazuje błędy strukturalne w dokumencie, ale komunikaty o błędach są tajemnicze i trudne do zrozumienia.

Jeśli ściągasz te programy i uruchamiasz je lokalnie, sprawdzenie całego katalogu pli­ków nie zajmie wiele czasu. A jeśli zrozumiesz, o co chodzi w dobrym kodzie HTML, będziesz popełniał mniej błędów. Może więc stosowanie obu programów nie będzie kłopotliwe.

Quiz

1. Prawda czy fałsz: HTML to jedyny język, którego kiedykolwiek będziesz musiał się nauczyć, by móc tworzyć witryny WWW.

2. W jaki sposób można zredukować rozmiar stron WWW, które zawierają mnóstwo grafiki i elementów multimedialnych?

3. czym należy pamiętać przy projektowaniu stron WWW zawierających ramki?

4. Prawda czy fałsz: jeśli wszystkie odnośniki działają prawidłowo na moim komputerze, nie muszę testować całości po wysłaniu witryny na serwer.

5. Wymień kilka sposobów poprawienia czytelności stron WWW.

Odpowiedzi

1. W początkowym okresie rozwoju sieci twierdzenie to mogło być prawdziwe, ale z pewnością nie dotyczy to już czasów obecnych. Tworząc witryny WWW wykorzystujące wyłącznie znaczniki HTML, będziesz musiał poznać dodatkowe technologie, takie jak kaskadowe arkusze styli CSS (rozdział 10. — „XHTML i arkusze styli”), JavaScript oraz Dynamiczny HTML (rozdział 21. — „Tworzenie elementów dynamicznych”), pozwalające na tworzenie ciekawych witryn wykorzystujących możliwości zaawansowanego pozycjonowania i prezentacji.

2. Można zmniejszyć wymiary grafiki lub animacji. Można także zmniejszyć objętość rysunków, kompresując je (wykorzystując format JPG) lub też zmniejszając liczbę ich kolorów (rysunki GIF). Jeśli zawiedzie wszystko inne, można umieścić na stronie niewielką miniaturę rysunku czy też tylko jedną z klatek animacji i pozwolić, by osoby przeglądające witrynę samodzielnie decydowały, czy chcą dany element pobrać lub też obejrzeć. Więcej informacji na ten temat można znaleźć w rozdziale 7. — „Wykorzystanie obrazów, kolorów i tła”.

3. Używając ramek, nie należy dzielić okna przeglądarki na zbyt wiele części. Tego typu podział może być mylący dla czytelników, a w niższych rozdzielczościach może zabraknąć miejsca na ekranie do odpowiedniego wyświetlenia Twojej strony. Jeśli na witrynie znajdują się odnośniki do stron na innych witrynach, należy pamiętać o używaniu znacznika target="_top", dzięki czemu inna witryna zostanie wyświetlona na pełnym ekranie, a nie w jednej z ramek. Jeśli strona z ramkami zawiera grafikę, rysunki powinny być na tyle małe, by mieściły się wewnątrz ramek również w niższych rozdzielczościach. Należy również umieścić wewnątrz znacznika <noframes> odnośniki do poszczególnych podstron, dzięki którym osoby korzystające z przeglądarek nieobsługujących ramek również będą mogły przeglądać materiały na Twojej stronie. Więcej informacji na ten temat można znaleźć w rozdziale 12. — „Ramki i połączenia do nich”.

4. Fałsz. Podczas wysyłania stron na serwer może wystąpić któryś z wielu błędów powodujących nieprawidłowe działanie odnośników. Więcej informacji na ten temat można znaleźć w rozdziale 25. — „Publikowanie witryny”.

5. Spróbuj ograniczyć liczbę nieuporządkowanych odnośników, poukładaj je, wykorzystując spisy i tabele. Jeśli tylko to możliwe, spróbuj unikać korzystania z naprawdę długich akapitów. Korzystaj z nagłówków jak z nagłówków, a nie środków do podkreślania istotnych fragmentów tekstu. Nie nadużywaj formatowania tekstu (pochylenia i pogrubienia), ponieważ może to rozpraszać uwagę czytelnika. Korzystaj z rozmysłem z animowanych rysunków, przyciągając za ich pomocą uwagę osób oglądających stronę do najważniejszych informacji. Więcej informacji na ten temat znajdziesz w rozdziałach 22. — „Tworzenie i projektowanie stron WWW” i 23. — „Przykłady dobrych i złych stron WWW”.

Ćwiczenia

1. Ponieważ znajdujesz się już blisko końca książki, logicznym ćwiczeniem w tym miejscu (o ile nie zacząłeś robić tego już wcześniej) będzie rozpoczęcie tworzenia swojej własnej strony WWW. Zacznij od znaczników, z którymi czujesz się najpewniej. Gdy już będziesz gotów, wzbogacaj stronę o grafikę, odnośniki oraz tabele. W miarę nabywania doświadczenia, spróbuj skorzystać z bardziej zaawansowanych technik, takich jak ramki, kaskadowe arkusze styli, dynamiczny HTML oraz inne rozszerzenia HTML-a.

2. Opublikuj swoją stronę w sieci, w sposób opisany w rozdziale 25. Sprawdź działanie strony i spróbuj ją zareklamować. Pamiętaj, że jedną z najlepszych cech stron WWW jest to, że nie zostały one wykute w kamieniu. Można je modyfikować, usuwać oraz rozbudowywać, gdy tylko uzna się to za stosowne.

(przyp. red.) Niestety serwis sprawdzający Weblint nie jest już dostępny bezpłatnie, o czym autorka pisze pod koniec podrozdziału. Niemniej jednak można na Internecie znaleźć serwis pośredniczący, umożliwiający bezpłatne korzystanie z serwisu Weblint. Serwis ten ma adres: http://www.ews.uiuc.edu/
cgi-bin/weblint. Jedynym utrudnieniem związanym z jego wykorzystaniem, jest fakt iż nie pozwala on na sprawdzanie poprawności podanych fragmentów kodu, a jedynie całych stron WWW, których adres URL należy podać. Oznacza to, że aby sprawdzić stronę, będziemy musieli ją najpierw opublikować.

782 Część 9. Publikowanie na WWW

Rozdział 27. Testowanie, poprawianie i aktualizowanie stron WWW 781

---