JavaScript - nie zawsze warto

JavaScript - nie zawsze warto

Kiedyś słowo AJAX było kojarzone z tym, czym rzeczywiście powinno być. Dzisiaj AJAX 'udostępnia' oprócz standardowych funkcji także możliwość stworzenia animowanego menu, prostej mini-galerii dla trzech zdjęć swojego kota, czy też zaawansowanego edytora tekstu zamieniającego podczas pisania tekstowe emotikony na animowane żółte gify.

Dawniej nazywano to po prostu DHTML'em. Jednak zdanie "Menu wykonane w technologii AJAX" brzmi bardziej atrakcyjnie niż "Rozwijane menu w JavaScriptcie". Obecnie mało osób wie czym tak naprawdę jest, a czym nie jest AJAX. Tyle samo osób nie wie jak powinno korzystać się dostępnych technologii niezależnie od tego, czy nazwiemy je Ajaksem, DHTML'em, czy też zwyczajnie: JavaScriptem.

Jeśli ktoś chce robić błędy, to należy zaplanować je tak, aby psuły tylko tą część za które są odpowiedzialne, a nie całość.

JavaScript ma zazwyczaj na celu dodawać nową funkcjonalność. Jeśli coś nie zadziała pod daną przeglądarką, to użytkownik powinien stracić tylko nową funkcjonalność, a nie całość (pomijając sytuacje 'ekstremalne').

Załóżmy, że mamy nową funkcjonalność dodaną w JavaScripcie: wszystko przetestowaliśmy, zoptymalizowaliśmy kod - wszystko jest ok. Ale czy jest tak zawsze?

Niektórzy potrafią lekko przesadzić z wykorzystaniem swoich umiejętności zapominając przy tym czym tak właściwie ma być ich strona www.

Slalom między zdjęciami
Zobaczmy na pierwszy przykład: jest to podstrona portalu Tvn24.pl.
Typowy artykuł z kilkoma fotkami między tekstem. Jeśli nasza przeglądarka obsługuje JavaScript to napotkamy niezbyt użyteczny 'bajer'. Zdjęcia umieszczone w artykule powiększają się gdy nad nimi znajdzie się kursor myszki. Przypisanie zdarzenia do onmousemove nie było najlepszym pomysłem. Teraz czytanie artykułów przypomina bardziej grę w której musimy unikać kontaktu naszego kursora z wrogimi obiektami. Oczywiście czytelnik nie będzie zastanawiał się nad tym - zajmie się treścią. 'Walkę' z ruchomymi zdjęciami przejmie podświadomość czytelnika. Przeciętny internauta który nie korzysta z programów blokujących reklamy jest przyzwyczajony do takich sytuacji. Na dużych portalach często możemy spotkać reklamy wykonane w technologii Flash które po najechaniu na nie kursorem powiększają się zasłaniając przy tym treść. Tak samo jest i w tym przypadku.

Kontakt ze stroną Tvn24.pl będzie równał się z uaktywnieniem podświadomego, naturalnego AdBlocka - o tym, że lepiej unikać takich sytuacji nie muszę chyba mówić.

Możesz powiedzieć, że w podanym przeze mnie artykule zdjęcia stanowią najważniejszą jego część - będziesz miał racje. Ale nawet to nie zmienia faktu, że raczej warto pomyśleć nad innym rozwiązaniem. Nawet jedno takie zdjęcie może zirytować czytelnika.

Warto pomyśleć nad tym, co twórcy tego portalu powinni zastosować w zamian?
Moim zdaniem najlepiej zrezygnować z przypisaniem zdarzenia do onmousemove. Jeśli czytelnik będzie zainteresowany zdjęciem, to wykorzysta doświadczenie zdobyte na innych stronach gdzie jedno kliknięcie zupełnie wystarcza.

Kliknięcie które irytuje
Jeśli już jestem przy temacie zdjęć które trzeba powiększyć kliknięciem... Gdy trafiam na zdjecia które można powiększyć (kursor - pointer), oczywiście klikam środkowym przyciskiem myszki aby otworzyć obrazek w nowej karcie nie tracąc przy tym obecnej strony.

Jednak często zdarza się, że po kliknięciu dostaje tylko pustą nową kartę. Okazuje się, że twórca witryny był tak pomysłowy, że wykorzystał mniej więcej taki kod: href="javascript:pop()"

Właśnie takimi niespodziankami wita czytelników portal Gazeta.pl. Administratorzy z góry założyli, że odwiedzający ich portal będzie wolał sobie otworzyć nowe malutkie okienko.

Klikaj, klikaj ...
W obu powyższych przypadkach mogę zrozumieć jaki cel miał twórca strony. W pierwszym została dodana nowa funkcjonalność powiększania zdjeć bez konieczności opuszczania strony i otwierania nowym kart, czy okien. W drugim przypadku funkcjonalność podobna, tylko że zdjęcie otwierane było w nowym oknie zamiast w nowej warstwie bezpośrednio nad treścią strony. Jednak nie mogę zrozumieć, jaki cel jest w ukrywaniu komentarzy na stronach poprzez JavaScript, czy poprzez CSS (nie wszystkich razem, tylko każdego z osobna).

Przykład możemy odnaleźć na tej stronie (pod artykułem). Aby przeczytać komentarz należy najpierw kliknąć aby go rozwinąć. Ta 'nowa funkcjonalność' to wynik pomysłowości twórcy wtyczki do Joomli odpowiedzialnej za możliwość komentowania.

Jakie to może mieć zastosowanie?
Jedyne co przychodzi mi do głowy to teoria która mówi, że warto oddzielić komentarze o niskiej wartości merytorycznej od wpisu po to, aby czytelnik nie przypisywał automatycznie niskiej wartości wypowiedzi autorowi artykułu na podstawie komentarzy.

W tym przypadku raczej nie o to chodzi. Jakie to może mieć zastosowanie? Masz pomysł - napisz :)

Przepraszam, czy tu można klikać?
Kolejnym przykładem nieużytecznego zastosowania JavaScriptu będzie Dziennik Internautów. Spójrzmy na tą podstronę z artykułem. Aby dodać komentarz musimy kliknąć w napis "Dodaj nowy komentarz (rozwiń)" pod artykułem. Czy tutaj można kliknąć? Element wydaje się być jedynie zwykłym tekstem. Nie spróbowano tutaj użyć jakiegokolwiek sposobu, aby pokazać że ten element strony można kliknąć (zmiana stylu, lub zastosowanie cursor: pointer;)

Taki błąd często spotykam na wielu stronach. Jeśli Ty wiesz gdzie można 'klikać', a gdzie nie, to nie myśl że ja też będę o tym wiedział wiedział.

Oczywiście możesz powiedzieć, że użytkownik domyśli się co trzeba zrobić. Tak, ale czy warto go zmuszać go do myślenia nad elementami nieistotnymi? Nie każ mi myśleć ...

Po drugie: dlaczego niektórzy traktują użytkowników bez włączonej obsługi JavaScriptu w przeglądarce jako kogoś podrzędnej kategorii? W tym przypadku nie dodamy komentarza (na DI można to obejść przechodząc na inną podstronę). W przypadku opisanym wyżej nie przeczytamy nawet komentarzy ...

JavaScript jest bardzo użyteczny i potrafi znacząco ułatwić i umilić użytkownikowi kontakt z witryną, ale w niektórych przypadkach najlepiej z niego zrezygnować.

Komentarze 124:

  • » SpeX: 15.08.2008 o 11:43

    @Gazeta stosuje te linki tylko w przypadku jak w artykule jest jedno zdjęcie. Jak w materiale jest więcej zdjęć to podają normalny link do gallery z powiększonym tym zdjęciem.

  • » Mike: 15.08.2008 o 11:47

    Ukrywanie treści nie jest zbyt dobre patrząc z punktu pozycjonera. Powinno działać to tak: najpierw wczytanie treści, a następnie ukrycie jej przez js, wtedy nie będzie problemów ani z wyszukiwarkami, ani z gośćmi bez js.

  • » Mike: 15.08.2008 o 11:49

    Coś strona wolno działa. I dlaczego mam przy nicku [www] z nieswoim adresem? :)

  • » Adriano: 15.08.2008 o 12:02

    @SpeX, racja, ale poprawienie tego (żeby choć link wskazywał sam obrazek) nie byłoby żadnym problemem (biorąc pod uwagę nawet to, że adres miniaturki i oryginalnego zdjęcia różni się jedynie jedną literą).

    @Mike: co do pierwszego komentarza - zgadzam się.

    Blog wolno chodzi bo prawdopodobnie OVH ma jakieś problemy z łączem/jego przepustowością. Strona generowana jest jak zazwyczaj dość szybko.
    Co do adresu - poprawione, teraz powinno być ok. Majstrowałem trochę przy kodzie ;)

  • » Olek Nowodziński: 15.08.2008 o 13:05

    Uważam, że traktowanie użytkowników, których przeglądarki nie obsługują JS, jako podrzędnej kategorii, jest bardzo prawidłowym zjawiskiem.
    JS to standard, obecny od wielu lat i obsługiwany przez wszystkie popularne przeglądarki.
    Równie dobrze można by napisać: "dlaczego niektórzy traktują użytkowników bez włączonej obsługi CSS w przeglądarce jako kogoś podrzędnej kategorii?"
    A przecież takie przeglądarki są (ot - choćby tekstowe), choć wiadomo, że bez CSS na stronie, to jak bez ręki. Standardy trzeba wprowadzać ofensywnie!
    A kto z premedytacją wyłączył sobie JS - niech liczy się z tym, że straci funkcjonalność, bo równie dobrze mógłby wyłączyć CSS, albo obrazki.

  • » Adriano: 15.08.2008 o 13:19

    @Olek Nowodziński: zauważ, że nie każdy obecnie używa tylko komputera do korzystania z internetu. Obecnie ludzie coraz częściej korzystają z urządzeń mobilnych.

    Przypadki które opisałem wyżej da się bez problemu poprawić tak, aby w każdej sytuacji user bez JS, cz z JS mógł dostać podstawowe funkcje (bez ukrywania formularzy, tekstu, itp).

    Porównanie JS do CSS'a jest trochę nietrafione. Będę korzystał z przeglądarki:

    - bez JS: nie zobaczę komentarzy, nie powiększę obrazka, nie dodam komentarza
    = stracę funkcje dodatkowe (zależne od JS) + funkcje podstawowe (niezależne od JS)

    - bez CSS'a: zobaczę komentarze, powiększę obrazek, dodam bez problemów komentarz.
    = stracę funkcje dodatkowe (zależne od CSS'a) i tylko tyle.

  • » Grzesiek: 15.08.2008 o 13:42

    Adriano,

    a obadaj ten motyw - domena sekcji detalicznej Citi Handlowego - www.online.citibank.pl - jest przekierowywana JS!!! czyli jak nie mam wlaczonego JS i wejde na to strone to zobacze pusty ekran! :D

    to samo w przypadku domeny citifinancial.pl :D

    pozdrawiam

  • » Adriano: 15.08.2008 o 14:14

    @Grzesiek: w takim przypadku powinni oprócz skryptu zamieścić na tej stronie przekierowującej linki. Użytkownik z JS niczego by nie zauważył, a ten bez JS mógłby sobie bez problemu poradzić.

  • » RoB: 15.08.2008 o 14:17

    Olek Nowodziński, przeczytaj to http://perfectionorvanity.com/2007/11/07/kto-normalny-wylacza-javascript/

  • » Olek Nowodziński: 16.08.2008 o 21:55

    @RoB - zgadzam się, to co można zrobić bez JS należy wykonać innymi sposobami.
    Też nie da się ukryć, że wszystko zależy od trzeźwości kodera. Ale nie odpuszczę tego, że należy silnie naciskać użytkowników (w konsekwencji programistów przeglądarek), aby JS działał dobrze i był powszechnie dostępny. Inaczej technologie www będą rozwijać się wciąż ślimaczym tempem.

  • » procek: 17.08.2008 o 00:37

    Już śpieszę z wyjaśnieniem o co chodzi na procku... Ukrycie komentarzy chroni przed przepychankami w komentarzach. Ktoś głupi napisze:
    - To jest białe
    Inny dopisze:
    -Nieprawda bo czarne
    Kolejny:
    -Takie szare w kropki raczej

    A artykuł był o DTP. I takie sytuacje mnie rozwalają...

    @Olek Nowodziński - masz po części rację, ale jak zauważył Adriano nie wszystkie urządzenia mogą używać Javy Scriptu (i nie piszcie JS, bo to co innego). Ciągle jeszcze się piszę strony specjalnie pod IE6 - głupota, prawda? Ale dużo osób ma jeszcze to cholerstwo. I to na nas (mniejszych czy większych webmasterach) spoczywa zasmarkany obowiązek, aby dogodzić wszystkim. Jest to o tyle niewdzięczne, że koderzy gier nie przejmują się sprzętem graczy, tylko lecą z wymaganiami gier do góry, a webmasterka kieruje się tym, aby szanować wszystkich.

  • » pio: 31.08.2008 o 18:36

    Pytanie do autora:

    Załóżmy, że mamy formularz składający się z 10 select'ów. Dostępne opcje dla kilku z nich zależą od wybranej opcji pozostałych (np. select z miastami zależy od wyboru państwa).
    Ten formularz to 'podstawowa funkcjonalność' serwisu.
    Jakie jest dla Ciebie najlepsze rozwiązanie funkcjonalności formularza bez Javascript'u?

  • » Adriano: 31.08.2008 o 22:55

    @pio: Rozwiązanie jest proste:

    - użytkownik z obsługą JavaScriptu dostaje formularz gdzie wybrane opcje zależą od powyżej wybranych, itd.

    - dla użytkowników z przeglądarkami bez obsługi JS należy przygotować kilka etapów wypełniania formularza(y), gdzie użytkownik najpierw wybiera przykładowo 'państwo', wysyła formularz przechodząc do następnego etapu z wyborem 'województwa', itd.
    Prostszego rozwiązania nie widzę dla użytkowników bez JavaScriptu.

    Dostarczenie alternatywnego rozwiązania dla użytkowników bez JS wymaga zwiększenia nakładów pracy przy tworzeniu danego serwisu, ale należy pamiętać, że te nakłady mogą prowadzić do zwiększenia zysków.

    Oczywiście nie zawsze opłaca się tworzenie alternatywy dla części serwisu działającej tylko z JavaScriptem - wszystko zależy od stopnia rozbudowania, kosztów pracy, i tym podobnych.

  • » pio: 01.09.2008 o 18:33

    No właśnie rozwiązanie nie jest takie proste. Widziałeś kiedyś formularz z dziesięcioma krokami? usability na poziomie 0. ja bym już na drugim kroku zrezygnował. Czym byłby Gmail czy Google Reader bez JS'a? - męczarnią.

    Moje zdanie jest następujące: javascript zawsze warto, ale z głową. Dla komórek i reszty urządzeń z okrojonymi przeglądarkami - okrojone wersje stron.

  • » Adriano: 01.09.2008 o 19:48

    Widziałeś kiedyś formularz z dziesięcioma krokami? usability na poziomie 0. ja bym już na drugim kroku zrezygnował.

    Myślę, że lepiej dać użytkownikowi takie coś, niż całkowicie go olać.
    Użytkownik z JavaScriptem zobaczy jeden pełny, funkcjonalny formularz, więc nic na tym nie straci.

    Czym byłby Gmail czy Google Reader bez JS\'a? - męczarnią.

    Dla mnie Gmail bez JS jest idealnym rozwiązaniem - często go używam gdy nie mam dostępu do przeglądarki z obsługa JavaScriptu.
    Wystarczy mi komórka i mogę przeczytać wiadomość i odpowiedzieć na nią.

    Moje zdanie jest następujące: javascript zawsze warto, ale z głową. Dla komórek i reszty urządzeń z okrojonymi przeglądarkami - okrojone wersje stron.

    Zgadzam się, idealnym przykładem jest właśnie Gmail:
    - Twoja przeglądarka obsługuje JavaScript? - dostajesz całą funkcjonalność
    - Twoja przeglądarka nie obsługuje JavaScriptu? - dostajesz tylko podstawową funkcjonalność

  • » Daniel: 06.10.2008 o 20:21

    Formularz z dziesięcioma krokami to po prostu kreator :) Trzeba go tylko ładnie przygotować graficznie, dołożyć trochę tekstu z opisem poszczególnych kroków i nikt nie zauważy. A dla tych z włączonym JS można zrobić wszystko na jednej stronie z automatycznym przeładowywaniem albo ajaxem, albo jak ktoś chce to kreator na zakładkach.

  • » Chris Trynkiewicz: 05.02.2009 o 05:17

    Wlasnie ze wzgledow, ktore opisales w artykule, zaczalem bardziej przychylnie patrzyc na lightboxy. Lepsze juz to, niz target="_blank" albo js w hrefie otwierajacy nowe okno...

  • » Adam: 27.02.2009 o 00:39

    Dlatego ja java script używam w ostateczność. Myślicie, że takie rozwijane menu jest źle odbierane przez googla? Podobno google czyta js, ale chyba nie zawsze.

  • » JQuery: 28.07.2009 o 17:15

    Adam: Zalezy czy menu bedzie zapisane w kodzie html, a javascriptem bedziesz je tylko rozwijal, czy moze caly kod wygenerujesz przez js. W pierwszym przypadku google nie bedzie mial zadnych problemow

Dodaj komentarz:

Dostępne tagi: [link]http://adres-www[/link] [quote]cytat[/quote] [code]kod[/code] [pre]tekst preformowany[/pre] [b]bold[/b]