Szablon Intense

Po raz kolejny dostałem od firmy Template Monster Polska szablon do oceny. Tym razem jest to szablon Intense, który reklamowany jest jako najbardziej zaawansowany szablon do wszystkiego. Cóż, wypada zatem sprawdzić, czy aby na pewno jest najbardziej zaawansowany i do wszystkiego, a nie – jak to zwykle bywa – do niczego.

• Zacznijmy od samego procesu kupowania szablonu. Tutaj zdecydowanie się poprawiło od ostatniego czasu. Strona została całkowicie przebudowana, dzięki czemu stała się o wiele przyjaźniejsza dla użytkownika. Jedynym zastrzeżeniem, jakie mogę mieć, to fakt, że pole do wpisania kodu promocyjnego na szablon nie jest odpowiednio wyeksponowane.
• Po kupieniu szablonu, dostajemy na maila link do jego ściągnięcia. Tutaj nic się nie zmieniło: wciąż dostajemy szablon wraz ze wszystkimi plikami źródłowymi (szablony w Jade, style w SASS oraz PSD) oraz obszerną dokumentacją. Spory plus.
• Przejdźmy zatem do szablonu. Jak ostatnio, bez żadnych zmian wgrałem go na serwer (oczywiście skrypty PHP nie działają).
• Gdy odpaliłem szablon w Chrome (wersja developerska, z lekko zmienioną konfiguracją), nie działał scroll przez kółko myszy. To de facto dyskwalifikuje szablon. Niemniej w stabilnej wersji Chrome wszystko działa jak należy. Mam zatem jedynie nadzieję, że gdy obecna wersja developerska stanie się stabilną, ten problem nie będzie już istniał.

• Odpaliłem zatem stronę w Firefoksie, w którym mam zainstalowany dodatek NoScript (żeby sprawdzać działanie tworzonych przez siebie stron, gdy nie ma JS) i… całą stronę przysłaniał preloader. Gdy udało mi się go pozbyć (nie włączając JS, rzecz jasna), okazało się, że… na stronie brakuje menu i części treści! A wszystko dlatego, że menu jest chamsko ukryte w CSS, co oznacza, że wystarczy mały błąd w JS lub wręcz chwilowy zastój sieci i strona jest bezużyteczna.

  Strona nie jest zaawansowaną aplikacją webową i nie widzę sensu uzależniania działania jej od obecności JS – zwłaszcza elementów, które go nie potrzebują. Menu to lista linków – tutaj nie jest potrzebny żaden skrypt! Naprawdę, istnieje na tyle dużo powodów niedziałania JS, że newralgiczne elementy strony wręcz nie mogą zależeć od jego obecności! Filozofia PE nie powstała bez powodu.

  Sytuacja jest inna w przypadku aplikacji internetowych, gdzie często nie da się zrobić nic sensownego bez JS. Ale w przypadku stron – da się. I należy to zrobić.

  Co do preloadera – nie widzę jego sensu. Znów: tego typu efekt (choć na pewno efektowny) jest efektywny tylko w aplikacjach. Na stronach za to warto użyć lepszych sposobów albo przynajmniej naprawić niedziałanie przy wyłączonym JS.

• Po włączeniu JS-a mogę przystąpić do dalszej oceny. Liczba podstron, jakie są dostępne jest naprawdę imponująca. Ocenię raptem kilka z nich: stronę główną, About me, Contact me, Pricing oraz jedną z wersji portfolio.
• Nie widać, gdzie jest obecnie focus. Co więcej: menu w ogóle nie jest dostępne z poziomu klawiatury! Przez to strona jest dla mnie nieużywalna. Możliwość sprawnej nawigacji przy pomocy klawiatury jest podstawowym elementem dostępności. Tutaj go zabrakło.
• Wyszukiwarka i koszyk w menu to kolejne nie do końca dostępne rzeczy. Z punktu widzenia semantyki, w ich obecnej formie, to są przyciski, nie linki. To powoduje, że czytniki ekranowe są wprowadzane w błąd. Co więcej: te elementy znów nie zadziałają bez włączonego JS – a wyszukiwarka bez JS musi działać (bo to obok nawigacji podstawowy element nawigacyjny).
• Pomijając duże błędy w dostępności, strona główna robi naprawdę dobre wrażenie. Jest bardzo efektowna – nie wiem, czy aż nie za bardzo.
• Po przejściu na podstronę Contact me pierwsze, co rzuca się w oczy, to niezwykłe uproszczenie strony w stosunku do strony głównej. Na tyle duże, że osobiście odnoszę wrażenie, że trafiłem na całkowicie inną stronę. Chyba nie do końca o to chodziło.
• Formularz jest zrobiony źle. Etykiety pól nie są do nich podpięte, co sprawia, że tracą całkowicie sens!
• No i: formularz wymaga JS. Co prawda bez niego można go wysłać, ale użytkownik jest przekierowywany do surowej strony wyświetlającej kody błędów… przez co formularz jest tak czy inaczej nieużywalny. A przecież wystarczy zastosować filozofię Taunusa – zwłaszcza, że nie wiadomo do czego taki szablon będzie wykorzystywany!
• Przejdźmy zatem do oceny kodu. Na początek walidacja. Jak widać, outline nie jest do końca poprawny. Niemniej to jedyny problem z walidacją na stronie głównej. Zresztą na innych też.
• W przypadku testu prędkości nie jest już tak różowo. Od razu widać, że mimo wszystko przedłożono efektowność nad efektywność. Co ciekawe, na podstronach jest zdecydowanie lepiej.
• W przypadku testu dostępności też nie jest dobrze. I znów na podstronach jest lepiej.
• Przejdźmy do oceny kodu. Tutaj skupię się de facto wyłącznie na stronie głównej, z podstron opisując jedynie interesujące fragmenty. Zacznijmy od plusa: mamy określony język strony.
• Deklaracja kodowania de facto musi być pierwsza w head, a metatag [http-equiv="X-UA-Compatible"] – drugi albo całkowicie przerzucony do konfiguracji serwera.
• Wyłączanie skalowania dla stron to zwykle bardzo zły pomysł. Dopóki nie tworzymy aplikacji skrojonej specjalnie dla platformy mobilnej, lepiej tego nie robić (oficjalna dokumentacja Bootstrapa odradza tego typu rozwiązanie!).
• Odnośnie ikonki strony, może warto rozbudować?

• <link rel="stylesheet" type="text/css" href="//fonts.googleapis.com/css?family=Montserrat:400,700%7CLato:300,300italic,400,700,900%7CYesteryear">

  Zawsze należy wymuszać HTTPS. A jeszcze lepiej – korzystać z SRI.

• Czemu serwowany CSS nie jest domyślnie minifikowany? Zwłaszcza, że przecież jest dostęp do plików źródłowych!
• Fajnie, że jest ostrzeżenie dla starych IE. Osobiście zrobiłbym je do wersji 11 włącznie.

• <div class="page-loader page-loader-variant-1">
  	<div><img class='img-responsive' style='margin-top: -20px;margin-left: -18px;' width='330' height='67' src='images/intense/logo-big.png' alt=''/>
  		<div class="offset-top-41 text-center">
  			<div class="spinner"></div>
  		</div>
  	</div>
  </div>

  W tym krótkim kodzie są 2 poważne błędy!

  • Element nie ma treści, więc jest bezsensowny dla czytników ekranowych. Jeśli natomiast jest tylko efektem wizualnym, to tym bardziej podważa sens jego istnienia.
  • Style inline nie lubią się z CSP, które jest coraz częściej wymogiem – zwłaszcza w dobie upowszechniania się HTTP/2.0 i tym samym HTTPS!

• <button data-rd-navbar-toggle=".rd-navbar, .rd-navbar-nav-wrap" class="rd-navbar-toggle"><span></span></button

  Pusty element = bezsensowny element. Widać od razu, że szablon nie był testowany z czytnikami ekranowymi! A wystarczy śćiągnąć JAWS-a i… posłuchać.

• <div class="rd-navbar-brand"><a href="index.html"><img style='margin-top: -5px;margin-left: -15px;' width='138' height='31' src='images/intense/logo-light.png' alt=''/></a></div>

  Tutaj jest dokładnie ten sam problem, co wyżej, tylko, że ciut gorszy. Wszystko dlatego, że w tym wypadku mamy do czynienia z linkiem! Co więcej, to powinien być główny nagłówek strony.

• <div class="rd-navbar-mobile-brand"><a href="index.html"><img style='margin-top: -5px;margin-left: -15px;' width='138' height='31' src='images/intense/logo-light.png' alt=''/></a></div>

  Jeśli już bawimy się w stronę RWD, róbmy to dobrze. Duplikowanie w kodzie elementów dla dużych ekranów i dla urządzeń mobilnych po prostu zabija sens RWD.

• Liczba divów jest przytłaczająca. Jestem niemal pewien, że dużo z nich można wywalić.
• Wyszukiwarce przydałoby się [role=search].

• <button type="submit" class="form-search-submit"><span class="mdi mdi-magnify"></span></button>

  Kolejny pusty element. Ikonka to nie treść!

• Logo strony oraz wyszukiwarka nie są częściami nawigacji! Dlatego nie powinny być w nav.

• <a href="#"><span class="text-middle">Home Types</span></a>

  Tego typu linki są po prostu zepsute. Osobiście zrobiłbym z tego przyciski. To pozwoli także w sensowny sposób obsłużyć rozwijane menu dla czytników ekranowych.

• <a data-rd-navbar-toggle=".rd-navbar-inner,.rd-navbar-search" href="#" class="rd-navbar-search-toggle mdi"><span></span></a>

  Kolejny bezsensowny element. I znów: to przycisk, nie link. Link służy do przechodzenia do innej podstrony/innego miejsca na stronie. Natomiast do odpalania wszelkich akcji w obrębie jednej strony służy przycisk (button).

• <h6 class="rd-navbar-product-title"><a href="shop-single-product-left-sidebar.html">Fashion model new</a></h6>

  W kodzie nie ma wcześniej żadnych innych nagłówków i nagle pojawia się to… Miałoby to sens, gdyby koszyk był sekcją, miał odpowiedni nagłówek, a nazwy produktów – były nagłówkami odpowiedniego poziomu.

• <h1><span data-caption-animate="fadeInUp" data-caption-delay="700" class="big text-uppercase">Welcome to Intense</span></h1>
  […]
  <h4 data-caption-animate="fadeInUp" data-caption-delay="900" class="hidden reveal-sm-block text-light">
  	The smartest and most flexible bootstrap template by TemplateMonster you've ever seen.
  	Create exactly what you need with our powerful bootstrap toolkit.
  </h4>

  Tutaj znów zaburzona jest hierarchia nagłówków (jest to o tyle ważne, że czytniki się nią posługują do tworzenia dodatkowej nawigacji!). Co więcej, podtytułów nie oznacza się przez nagłówki.

• <a href="#" data-custom-scroll-to="home-section-welcome" data-caption-animate="fadeInUp" data-caption-delay="1200" class="btn btn-default btn-lg btn-anis-effect"><span class="btn-text">Start a journey</span></a>

  Kolejny zepsuty link. Można to zrobić lepiej.

• h1 występuje kilkukrotnie, co zaburza hierarchię nagłówków!
• To, że obrazek jest wsadzony w svg nie zwalnia nas od oznaczania, że to tylko ozdobnik ([role=presentation]/[aria-hidden=true]) albo dodania opisu ([aria-label]/aria-labelledby).
• Sekcja z ficzerami powinna mieć nagłówek mówiący, że to sekcja z ficzerami. Zwłaszcza, że Bootstrap udostępnia prosty do użycia mechanizm, oparty na obecnym best practice.

• Interfejs odtwarzacza wideo jest kolejnym niedostępnym elementem. Zamiast dobrze zrobionych przycisków po raz kolejny zastosowano bezsensowne puste linki:

  <div class="rd-video-controls-buttons">
  	<!-- Play\Pause button--><a href="#" class="rd-video-play-pause mdi mdi-play"></a>
  </div>

• <li><a data-isotope-filter="*" data-isotope-group="gallery" href="#" class="text-bold active">All</a></li>

  Tutaj faktycznie, przydałyby się linki… gdyby było to wykonane dobrze. Każda grupa filtrów powinna mieć odpowiadający jej section[id] (lub div[id]) i link powinien do niego odsyłać. A jeśli jest JS, to wówczas robić to w efektowny sposób. Ba, bez JS-a też się to da zrobić efektownie, uzywając :target w CSS!

• <li data-owl-item='0' class="owl-dot-custom img-circle img-bordered-white"><img width="90" height="90" src="images/users/user-kira-force-90x90.jpg" alt="" class="img-circle"></li>

  Nawigacja slidera to przyciski/linki (w zależności od tego, jak działa). Warto zapamiętać, że w HTML mamy tak naprawdę 2 elementy klikalne: link i przycisk. Każdy inny element, choć może być klikalny, będzie zachowywał się niepoprawnie! Co więcej, jeśli treścią elementu klikalnego jest wyłącznie obrazek, to czytniki ekranowe jako treść stosują wówczas [alt] tego obrazka. W tym wypadku wyrażnie widać, że treści nie ma!

• Sekcja z ostatnimi newsami w stopce powinna być… no właśnie, sekcją.

• <input placeholder="Type your E-Mail" type="email" name="email" data-constraints="@Required @Email" class="form-control">

  Ehhh… To już po prostu tradycja na WK. Piszę to chyba w każdej recenzji, więc trzeba napisać i tutaj: każde pole formularza, które nie jest przyciskiem, MUSI MIEĆ label! I nie, [placeholder] go nie zastępuje, o czym wspomina sama specyfikacja:

  Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control’s label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.

  4.10.5.3.10 The placeholder attribute

• <a href="#" class="icon fa fa-facebook icon-xxs icon-circle icon-darkest-filled"></a>

  Kolejne puste, bezsensowne linki…

• Spoglądam do pliku JS, a tam… kilkadziesiąt zmiennych globalnych! Serio? Mamy 2016 rok, za chwilę będziemy mieli natywne wsparcie dla modułów z ES6, a tutaj zmienne globalne? I to w takiej liczbie?
• Dodatkowo przeprowadzany jest UA sniffing zamiast feature detection, co jest bardzo złym pomysłem w 98% przypadków.

• Otwieram konsolę i co widzę?

  JQMIGRATE: Logging is active

  jQuery 1.11 jest od lat na rynku, a i tak jest tutaj używane narzędzie do „łagodnego” przejścia między starymi wersjami a nową… Niemniej nie to jest największym problemem. Większym jest logowanie wszystkiego do konsoli. To nie ma prawa mieć miejsca na produkcji!

• Przeszedłem na podstronę Contact me i ze zdziwieniem stwierdziłem, że label są dobrze przypięte… Niemniej klikanie na nie nie powodowało przejścia do odpowiedniego pola. Poszukałem przyczyny problemu i doszedłem do tego, że .form-label ma nadane… pointer-events: none (czyli wyłączenie obsługi myszki). To jest tak debilna decyzja, że nie wiem jak ją skomentować… Przecież to zepsucie jednego z podstawowych elementów dostępności i użyteczności. Dla czegoś takiego nie ma uzasadnienia.
• Zastanowiłbym się także, czy dla breadcrumbs nie dodać etykiety przy pomocy [aria-describedby].
• Patrząc także na rozmiar menu (zajmuje 500+ linii!), wręcz konieczny jest link typu „Skip to content”.
• Na podstronie Pricing te tabelki mogłyby być tabelkami. A jak już chcemy się pobawić z section, to opis każdego pakietu pasuje jak ulał do article.

Mam dylemat. Gdy otworzyłem w przegladarce ten szablon, to miałem ostry efekt „Wow!”… do czasu aż nie dotarłem do kodu. Tam widziałem straszne rzeczy…

Gdybym miał oceniać szablon tylko pod względem designu, byłaby to najlepsza strona na WK. Niemniej na tym blogu skupiam się głównie na kwestiach technicznych. A tutaj jest na chwilę obecną cienko. Dlatego – mimo pewnego bólu serca (hej, to naprawdę najładniejsza strona na WK!) – na razie najniższa kategoria… Na szczęście Template Monster zapewnia, że szablon jest nieustannie poprawiany, więc może doczekamy się także i poprawienia niezwykle palących problemów z dostępnością, o jakich wspominałem. I byłoby dobrze, bo ogrom pracy, jaki został włożony w ten szablon naprawdę imponuje. Szkoda by było, żebym przez kwestie techniczne nie mógł go polecać.