Netgo.pl/Mobilizacja

Jak wszyscy wiemy, 21 kwietnia 2015 roku Google szykuje wielką rewolucję mobilną! Doskonała okazja, żeby uświadomić ludziom znaczenie wciąż rosnącego rynku mobilnego i… trochę zarobić, wprowadzając odpowiednie modyfikacje do stron wciąż nieprzystosowanych do wyświetlania na telefonach komórkowych. Nic zatem dziwnego, że powstają wszelkiego rodzaju kampanie zachęcające klientów, taka jak Mobilizacja 2015 od Netgo.pl. Jak wypada strona tej akcji? Zobaczmy!

• Strona bez JS wygląda znośnie, ale widać wyraźnie, że strona bez JS nie jest w pełni funkcjonalna. Najdobitniej pokazuje to okaleczony slider z realizacjami oraz niedziałający przycisk do sprawdzenia strony w wersji mobilnej.

• Sprawdzanie strony zasługuje wręcz na odrębny artykuł, bo sama jego idea, jak i wykonanie, są po prostu fatalne.

  Jak to powinno się odbywać? Na serwerze powinna być instancja narzędzia, które pozwoliłoby nam wykonać screenshota strony przy odpowiednim viewport i po prostu zwrócić go naszej usłudze jako obrazek. Coś takiego jest możliwe do wykonania choćby przy pomocy PhantomJS. Napisanie przy jego pomocy skryptu robiącego screenshoty trwa tyle, ile… skopiowanie oficjalnego przykładu. Tym samym dostaniemy screenshota zawsze… chyba że wyglebi się nam serwer.

  A jak to zostało zrobione? Przy pomocy iframe. Strona jest po prostu wczytywana do ramki z ustalonymi rozmiarami i skalowana do odpowiedniego rozmiaru przy pomocy transform z CSS3. Dzięki takiej a nie innej decyzji moja strona jest nietestowalna. Wszystko z powodu nagłówka X-Frame-Options: SAMEORIGIN, który zwiększa bezpieczeństwo stron przez uniemożliwianie wczytywania ich w ramkach z innych domen (i tym samym utrudnia choćby clickjacking). Oczywiście problem nie dotyczy tylko mojej strony, bo np. taki Facebook również wysyła ten nagłówek, przez co wygląda jak zepsuta strona.

  Sama implementacja również pozostawia wiele do życzenia. Wpisuję adres w pole i automatycznie naciskam Enter… i nic się nie dzieje. Poważny błąd usability – użytkownicy są przyzwyczajeni do obsługi formularzy z poziomu klawiatury. No ale to nie jest formularz, tylko kaleka marionetka dla JS. W przypadku generowania screenshotów po stronie serwera bez problemu sprawdzanie responsywności strony można by przeprowadzić przy pomocy normalnego formularza.

  Jakby tego było mało, sama walidacja wpisywanych adresów również pozostawia wiele do życzenia. Wpisanie przed adresem protokołu https:// powoduje wysłanie żądanie pod adres http://https://adresstrony.pl. Akurat agencja interaktywna powinna wiedzieć, że wcześniejsza aktualizacja Google położyła nacisk właśnie na SSL i niewspieranie go w kampanii SEO-wej po prostu śmieszy. A do walidacji URIs są specjalne regexy, które nie popełniają takich głupot.

• Powyżej przycisku włączającego „sprawdzacza” stron znajduje się ładnie ostylowany formularz kontaktowy… którego walidacja jest przeprowadzana przy pomocy natywnego mechanizmu HTML5, co psuje cały efekt. Skoro już wkładamy tyle wysiłku w stworzenie tak ładnie wyglądającego formularza, to zróbmy też ładną i użyteczną walidację. Jednak nie to jest największym grzechem tego formularza. Brakuje w nim bowiem label, zatem jest całkowicie niedostępny i nieużywalny.

  ŁADNE OSTYLOWANIE BEZ ZADBANIA O DOSTĘPNOŚĆ I UŻYTECZNOŚĆ JEST JEDYNIE ZBĘDNYM EFEKCIARSTWEM!

• Powyżej tego formularza znajduje się mała tarcza z napisem Uchroń pozycję Twojej strony w wyszukiwarce. Jest to pewna nadinterpretacja. Owszem, strony niedostosowane do telefonów komórkowych stracą swoją pozycję, ale jedynie w mobilnych wynikach wyszukiwania.

  Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results.

  Finding more mobile-friendly search results

• Strona jest nieobsługiwalna z poziomu klawiatury. A wystarczy zapewnić odpowiedni outline.
• I na sam koniec „testów integracyjnych” odpaliłem stronę na komórce i okazała się w pełni responsywna. Jednak w kwestii wydajności nie jest już tak różowo.
• Zanurzmy się w kod. Pierwsze, co rzuca się w oczy, to klasa .no-js na html. Jednak nie jest ona używana, o czym świadczy wygląd strony przy wyłączonym JS, ani… nie zostaje usunięta przez JS. Innymi słowy: jest tam sobie, żeby być. To mógłby być świetny sposób na podniesienie użyteczności strony, ale coś nie wyszło.
• Konsekwencja stylu pisania HTML-a jest zachwiana: raz mamy styl XML-owy, raz nie.
• Zablokowano skalowanie strony poprzez odpowiedni wpis w meta[name=viewport]. Nie jest to aż tak uciążliwe, bo strona jest responsywna, ale mimo wszystko nienawidzę takich ograniczeń. W przypadku stron moim zdaniem nie mają sensu. Co innego w przypadku aplikacji internetowych, w których interfejs ma jak najbardziej przypominać ten z natywnych aplikacji.
• 5 arkuszy stylów – o 4 za dużo. Pomijam już fakt, że @import się nie używa, a czcionki obecnie inaczej się wczytuje.

• <meta name="description" content="" />
  <meta name="keywords" content="" />

  Wieszczę duże sukcesy w SEO.

• <div class="bg-mobile-white"></div>
  <div class="bg-mobile-orange"></div>

  Te elementy świetnie nadają się na pseudoelementy (np. body::before, body::after).

• Oto co znalazłem w kodzie:

  <img class="netgo-logo" src="img/netgo.png" alt="NETGO">

  Ale przecież na stronie nie ma żadnego logo… Aż w końcu patrzę w style CSS – visibility: hidden !important;. Ten element jest po prostu niepotrzebny na tej stronie, więc po co w ogóle go wprowadzać do kodu?

• <img src="img/white_bg.png" class="top-center-left-bg" alt="bg top white effect super hiper">

  Całkowicie bezsensowny [alt]. W tym przypadku powinien być pusty. Idealnie ten obrazek powinien znaleźć się jako tło w CSS.

• Główny nagłówek jest strasznie rozwalony w kodzie. Znajduje się w dwóch całkowicie osobnych komórkach grida, przez co staje się całkowicie niesemantyczny. Ba, nie jest nawet nagłówkiem.

  <p class="top-p-yellow">
  	MOBILIZACJA
  </p>
  […]
  <p class="top-p-white">2015</p>

  Widać tu także klasy silnie zespolone z prezentacją tego elementu, co nie należy do dobrych praktyk (klasy powinny być abstrakcyjne i opisywać strukturę lub przeznaczenie elementu, nie jego prezentację). Jest także krzyk, który można zastąpić przez text-transform: uppercase.

• <img src="img/ask_price.png" alt="zapytaj o cenę">

  To również powinno być nagłówkiem.

• <img src="img/tarcza.svg" class="shield" alt="ochrona pozycji">

  Tak wygląda tarcza z napisem Uchroń pozycję Twojej strony w wyszukiwarce w kodzie. Dziwią mnie tu dwie rzeczy: czemu [alt] nie oddaje treści, która jest na obrazku oraz czemu tekst na obrazku jest niezaznaczalny, skoro to SVG?

• Później w kodzie powtórzone są wszystkie te elementy dla urządzeń mobilnych. To raczej nie jest RWD. W przypadku takiego powtarzania kodu po prostu zrobiłbym osobną wersję mobilną.

• <img src="img/phone-rotate.png" alt="p1" class="phone-rotate">
  <img src="img/ipad-big.png" class="ipad-big" alt="ipad duży">

  Kolejne obrazki i kolejne bezsensowne [alt]. To są jedynie ozdobniki, więc atrybuty te powinny być puste.

• <div class="before-form">
  	+48 32 441 76 29
  </div>

  Ten numer to oczywiście numer telefonu. Tyle, że w żaden sposób nie wynika to z kodu. Przydałaby się chociaż prosta etykietka ([aria-label]), która wyjaśniałaby na co patrzymy.

• <div class="site-info">
  	<input type="text" class="site-name" placeholder="Tu wpisz adres Twojej strony">
  	<button class="site-submit">SPRAWDŹ</button>	
  </div>

  A oto i „formularz” do sprawdzania responsywności naszej strony.

• Slider to kolejne miejsce, gdzie mamy źle użyte [alt]. Nie dość, że obrazki składające się na nawigację mają angielskie opisy, to wszystkie pozostałe obrazki mają dokładnie ten sam, bzdurny [alt="iphone"].
• Nawigacja w sliderze jest o tyle ciekawa, że składają się na nią… same obrazki, które przesuwają slider przy zdarzeniu mouseover. Osobiście tego typu efekt mnie drażni i widziałbym tutaj tradycyjne przyciski.
• Stopka to kolejny zły [alt]. Obrazek przedstawia napis Google Partner, podczas gdy w kodzie mamy [alt="google"], co sugeruje, że jest to logo Google.
• Kod to jeden wielki divitis. W divy upchnięto tutaj wszystko, w ogóle nie przejmując się semantyką kodu.
• Po zerknięciu do pliku global.js w oczy rzuca się użycie zmiennych i funkcji globalnych, mimo zastosowania $(document).ready.
• Okazuje się, że [action] znajdujące się w formularzu kontaktowym na stronie to pic na wodę, fotomontaż. Formularz wysłany normalnie, przy wyłączonym JS, odsyła w niebyt, podczas gdy prawdziwy adres do backendu podany jest jedynie w kodzie JS go obsługującym. Warto pamiętać, że część osób nie ma JS – i to najczęściej nie z własnej winy! Tym samym w pełni świadomie się odcina takich klientów od podstawowej funkcjonalności naszego produktu, podczas gdy można ją minimalnym (lub wręcz zerowym!) nakładem sił zapewnić.
• W kodzie CSS dla transform raz prefiksy są, a raz nie. Trochę konsekwencji! Poza tym tam, gdzie występują wersje z prefiksami, powinny być one umieszczone w kodzie przed wersją bez prefiksów. Prefiksy oznaczają bowiem eksperymentalną implementację danej funkcjonalności w przeglądarce i nie muszą być zgodne ze standardami. Umieszczenie w kodzie wersji z prefiksami po bezprefiksowej może nam nadpisać zachowanie zgodne ze standardami zachowaniem typowym dla danej przeglądarki, a tego nie chcemy.
• I na koniec: warto odpalić konsolę JS, żeby… zobaczyć informację z debugowania. Takie rzeczy raczej nie powinny się znaleźć na produkcji.

Widać, że strona powstawała na szybko i nikt nawet nie próbował zadbać o jej aspekty semantyczny i dostępności. Niby wszystko wygląda ładnie i zachęcająco, ale jak się temu przyjrzeć i spróbować użyć, to czar niestety pryska.