Felieton
Wbrew pozorom, cuda animowanej skryptotechniki wcale nie tak trudno jest pogodzić z dobrem użytkowników nieco bardziej "statycznego" oprogramowania. Najlepszą metodą jest zaczęcie od zbudowania tego, co dostępne jest dla wszystkich.
Numer 16 (2/2006) • 31 maja 2006
Patryk Zawadzki. Dynamiczna (nie)dostępność
Ilustracja: Nicholas Di Genova
Odeszły w niepamięć czasy, kiedy skrypty w przeglądarce służyły do generowania falujących napisów, podążających za kursorem myszy po całej stronie i skutecznie utrudniających czytanie znajdującej się pod spodem treści. Dziś język JavaScript stał się potężnym narzędziem do zwiększania wygody internautów odwiedzających nasze strony.
Pozornie niezauważalny dodatek może decydować o opinii serwisu. Wszakże najważniejsze jest pierwsze wrażenie i nawet, jeśli czytelnik zdecyduje się opuścić nasze progi i zajrzeć do konkurencji, to istnieje szansa, że po chwili zdecyduje się wrócić. Z naszych stron korzystało mu się zwyczajnie wygodniej.
Wygoda na poziomie interfejsu jest niemal tak samo ważna jak łatwość nawigacji. Z drugiej strony, interfejs powinien być dostępny także dla tych, którzy z różnych przyczyn nie zamierzają bądź nie mogą cieszyć się dobrodziejstwami skryptowanej dynamiki. Nie chcemy bowiem, by potencjalny klient odszedł dziś z kwitkiem, jak miało to niejednokrotnie miejsce kilka lat temu, w dobie przypowieści o przeglądarce, co ramek nie chciała
.
Nie każdy pomysł na uskryptowienie serwisu jest tak samo dobry, tak jak nie wszystko złoto, co się świeci. Zatem, jeśli już zdecydowaliśmy się odnowić poręcze przy schodach, to nie smarujmy przy okazji tłuszczem podjazdu dla inwalidów. Nie ma nic bardziej frustrującego, jak świadomość, że poszukiwana treść znajduje się gdzieś tam, za barierą nowoczesnych technologii, które rozwijane są przecież po to, by jak najwięcej barier znosić.
Wbrew pozorom, cuda animowanej skryptotechniki wcale nie tak trudno jest pogodzić z dobrem użytkowników nieco bardziej "statycznego" oprogramowania. Najlepszą metodą jest zaczęcie od zbudowania tego, co dostępne jest dla wszystkich. Zaprojektuj serwis bez użycia szczypty choćby JavaScriptu. Upewnij się, że wszystko działa i do każdego zakamarka można się dostać.
Klient zamówił rozwijane menu o zmiennej przezroczystości? Nie myśl o tym, to będzie Twoje ostatnie zmartwienie. Teraz powinieneś upewnić się, że wszystkie elementy przeznaczone dla ludzi są widoczne i czytelne.
Mniejsza o to, że jeden z boksów powinien pojawiać się dopiero po kliknięciu któregoś z odnośników, jego ukrywanie to nie zadanie dla arkusza stylów. To nic, że przecież opis usługi podmieni się automatycznie za pomocą technologii AJAX. Na nic zdadzą się asynchroniczne wywołania, kiedy ja będę stał sfrustrowany na lotnisku, przy jednym z internetowych kiosków. Nie wspomnę nawet o tym, co o oferowanych usługach będą w stanie powiedzień innym Google.
Podstawową zasadą powinno być zbudowanie nieoskryptowanego prototypu, który choć może nieco mniej wygodny od docelowego produktu, zachowa jego pełną funkcjonalność. Dopiero po jego przetestowaniu można zajmować się okraszaniem swojego dzieła javascriptowymi cudami.
Jeśli coś musi zniknąć, to ukryj to za pomocą odpowiedniego wywołania JS w zdarzeniu załadowania dokumentu. Obawiasz się, że strona może się ładować na tyle długo, że zauważalne stanie się nieprzyjemne repozycjonowanych elementów? Nic prostszego, tuż pod rzeczonym elementem dodaj krótki skrypt, który natychmiast go ukryje. Jeśli skorzystasz z dobrodziejstw bibliotek takich, jak Prototype, całość sprowadzi się do napisania:
$('idelementu').hide();
Któryś z odnośników powinien wywoływać zdarzenie AJAX albo otwierać nowe okienko? Upewnij się, że posiada prawidłowy atrybut href, a całą dodatkową mechanikę umieść w obsłudze zdarzenia kliknięcia. Serwis stanie się przyjaźniejszy nie tylko dla odwiedzających go internautów. Szczególnie wdzięczne będą ci wyszukiwarki takie jak Google, którym idea skryptów JS jest zupełnie obca. To z kolei przełoży się na wyższą pozycję w rankingach, a pośrednio także na większe zyski.
Ale zgodność z przestarzałymi przeglądarkami to nie wszystko. Tak samo ważna, jeśli nie ważniejsza, jest zgodność z oprogramowaniem o którym może jeszcze nie słyszałeś, a może ono wcale jeszcze nie istnieje. To jeden z powodów, dla których wykrywanie przeglądarek w kodzie JavaScript jest bardzo, ale to bardzo złym pomysłem. Jest to równie niedorzeczne, jak pytanie o markę samochodu w celu ustalenia jego koloru.
Być może masz pewność, że Internet Explorer w wersji 4.0 nie potrafił czegoś zrobić, możesz być także głęboko przekonany, że serwis działa prawidłowo w Operze 8.52. Co miałoby jednak sprawić, że inaczej zachowa się pod kontrolą zupełnie nieznanego ci programu? Obawa przed nieznanym? JavaScript oferuje wiele metod na upewnienie się, że przeglądarka udostępnia pełen zestaw niezbędnych funkcji. Ich dostawca nie powinien mieć dla ciebie znaczenia, tak jak pytając o godzinę nieznajomego przechodnia, nie upewniasz się, że ma na ręce złotego Roleksa.
Pamiętaj, że o ile prezentację dla klienta zamawiającego serwis możesz przeprowadzić na własnym komputerze, o tyle spektrum konfiguracji sprzętowo-programowych, za pomocą których internauci będą do informacji docierać, jest znacznie szersze niż jesteś w stanie ogarnąć. Dywersyfikacja platform to jedna z pozytywnych zmian w Sieci od czasu dominacji Internet Explorera 4.0 i wszyscy musimy przejść nad tym do porządku dziennego.
W sieci szerzej znany jako Patrys, z komputerami pracuje od dziecka. Początkowo jako programista, od sześciu lat związany jest z siecią. Obecnie pracuje jako webdeveloper dla Internet Center Polska i prowadzi poświęconego standardom bloga.