Nadszedł czas, by po raz kolejny pochylić się nad szablonem od Template Monster, tym razem będzie to Monstroid2.
- System kupowania nie zmienił się od ostatniego razu, co akurat oznacza bardzo dobre wieści, bo działa to tak, jak powinno. No i mamy zawsze dostęp do swoich szablonów z panelu użytkownika. Jeśli się nam gdzieś zapodzieje na dysku, po prostu ściągniemy go raz jeszcze i tyle.
-
Paczka z szablonem waży ponad 520 MB, niemniej na tę wagę składa się absolutnie wszystko, co tylko możemy sobie wymarzyć w szablonie:
- sam szablon zakodowany w HTML w 10 różnych wersjach,
- kreator stron,
- szczegółowa dokumentacja,
- pliki PSD i inne pliki źródłowe.
-
Jak już wyżej wspomniałem, szablon posiada aż 10 rożnych wersji:
- „domyślną” (ogólnego użytku) – na niej jest oparta ta recenzja,
- dla hotelu,
- dla firmy budowlanej,
- dla korporacji
- dla siłowni/innego przybytku związanego z fitnessem,
- dla firmy produkującej meble,
- dla bloga modowego (tak, nawet taka wersja jest),
- dla firmy prawniczej,
- dla firmy
lichpożyczkowej, - dla restobaru.
Każda z tych wersji posiada kilkadziesiąt różnych szablonów poszczególnych stron. Jak widać Monstroid2 faktycznie jest uniwersalnym szablonem.
- Jak na razie wrażenie jest przytłaczająco pozytywne, zatem pora na przyjrzenie się szablonowi. A tam pierwsza przykra niespodzianka: scroll kółkiem myszy nie działa w Chrome dev – to kolejny szablon od TM cierpiący na tę przypadłośc.
- Szablon posiada preloader, który jednak jest źle wykonany i w chwili, gdy JS z różnych przyczyn nie zadziała (albo będzie wyłączony), nie pokaże ani skrawka strony. Jest to dość niezrozumiałe działanie, ponieważ strona prawie działa przy niedziałającym JS-ie. No i inna rzecz jest taka, że nie mam pojęcia po co tu ten preloader. Jeśli strona wczytuje się na tyle długo, żeby był potrzebny preloader, to raczej lepiej po prostu zoptymalizować stronę.
- Napisałem wyżej, że strona prawie działa przy niedziałającym JS-ie. Prawie, bo… nie działa wówczas menu. A szkoda, bo cała reszta sprawuje się poprawnie.
- Nawigacja klawiaturą jest praktycznie niemożliwa. Co prawda kolory poszczególnych elementów się zmieniają przy ich focusowaniu, ale jest to bardzo niewyraźne (no i WCAG 2.0 raczej by stwierdziło, że przekazywanie informacji wyłącznie przy pomocy koloru jest niewystarczające). Do tego odpowiednie podmenu się nie rozwijają, gdy się je sfocusuje, a duża część linków w treści nie reaguje w żaden sposób, przez co przez większość czasu nie wiemy, gdzie jesteśmy.
- Przejdźmy do kodu. Walidacja co prawda zaliczona, ale niepokoi brak nagłówków w wielu sekcjach. Hierarchia treści też mogłaby być ładniejsza.
- Zarówno deklaracja kodowania jak i
meta[http-equiv="X-UA-Compatible]
powinny być jako pierwsze whead
. - Nie ma sensu zabraniać użytkownikowi powiększania strony. Niektórzy naprawdę mają wadę wzroku i mogą czegoś nie zobaczyć.
-
<link rel="stylesheet" type="text/css" href="//fonts.googleapis.com/css?family=Libre+Franklin:200,300,500,600,300italic">
Nie powinno się używać relatywnego protokołu, należy zawsze wymuszać HTTPS.
- Style można by zminifikować. Zwłaszcza, że przecież jest kreator!
-
<div id="page-loader"> <div class="cssload-container"> <div class="cssload-speeding-wheel"></div> </div> </div>
Jak już robimy preloader, to porządnie. Przydałoby się trochę ARIA (
[role=progress]
+ może[aria-busy]
dlahtml
) i jakaś tekstowa etykieta, co się dzieje. -
<nav class="rd-navbar" data-layout="rd-navbar-fixed" data-sm-layout="rd-navbar-fixed" data-sm-device-layout="rd-navbar-fixed" data-md-layout="rd-navbar-static" data-md-device-layout="rd-navbar-fixed" data-lg-device-layout="rd-navbar-fixed" data-lg-layout="rd-navbar-static" data-stick-up-clone="false" data-sm-stick-up="true" data-md-stick-up="true" data-lg-stick-up="true" data-md-stick-up-offset="69px" data-lg-stick-up-offset="1px" data-body-class="rd-navbar-default-linked">
Ja rozumiem zamysł, ale to wygląda… monstroidalnie.
-
<button class="rd-navbar-toggle" data-rd-navbar-toggle=".rd-navbar-nav-wrap"><span></span></button>
Tak stworzony przycisk jest całkowicie niedostępny. Czytnik ekranowy po napotkaniu go nie będzie miał co przeczytać. Swego czasu przygotowałem przykładową implementację.
- Menu jest tak wielkie, że brak linku typu „przejdź do treści” to zbrodnia.
- Divitis jest niesamowity… Aż oczopląsu dostaję.
-
<h1 data-caption-animate="fadeInUpSmall"><span>Monstroid</span><sup class="text-primary">2</sup></h1> <h3 data-caption-animate="fadeInUpSmall" data-caption-delay="200">New HTML Templates Generation</h3>
-
<p class="blurb__title">Pixel Perfect Typography</p>
Tego typu elementy powinny być nagłówkami – zwłaszcza, że znajdują się w sekcjach/artykułach.
- Sekcja „Blurbs” nie posiada nagłówka, a powinna.
-
<li><a class="icon icon-sm fa-facebook" href="#"></a></li>
- Nieco inaczej zakodowałbym te zdjęcia pracowników, bo z punktu widzenia dostępności byłoby lepiej najpierw usłyszeć imię, nazwisko i stanowisko pracownika, a dopiero potem linki do sieci społecznościowych.
- Zastanowiłbym się, czy aby na pewno to
figure
jest aż tak niezbędne w galerii. No i otwarcie zooma raczej powinno być wywoływane z poziomu linku, ewentualnie przycisku (gdy nie chcemy linkować do pełnej wersji obrazka). -
<time datetime="2017">Jan.20, 2016</time>
Fatalne użycie
[datetime]
. To powinna być pełna data w formacie ISO-8601. -
Cytaty powinny być oznaczone przez
blockquote
, ewentualnie dodatkowo przezfigure
:<figure class="quote-default"> <blockquote class="quote-default__text"> <p class="q">I love to use your ready-made and beautifully looking templates. They are available at very affordable prices and they save me a lot of time, and deliver from a lot of sweat and tears!</p> </blockquote> <figcaption class="quote-default__cite"> <cite>Jane Smith</cite> </figcaption> </figure>
-
<input class="form-input" id="contact-email" type="email" name="email" data-constraints="@Email @Required"> <label class="form-label" for="contact-email">Enter please your e-mail</label>
Niby wszystko ok, bo
label
jest, niemniej jest za polem, a powinien mimo wszystko być przed (taka kolejność jest logiczniejsza). -
<div class="cell-xs-10 cell-sm-6 cell-md-4 cell-lg-3"> <h6>Contacts</h6> <ul class="list-xs"> <li> <dl class="list-terms-minimal"> <dt>Address</dt> <dd>4578 Marmora Road, Glasgow, D04 89GR</dd> </dl> </li> <li> <dl class="list-terms-minimal"> <dt>Phones</dt> <dd> <ul class="list-semicolon"> <li><a href="callto:#">(800) 123-0045</a></li> <li><a href="callto:#">(800) 123-0045</a></li> </ul> </dd> </dl> </li> <li> <dl class="list-terms-minimal"> <dt>E-mail</dt> <dd><a href="mailto:#">info@demolink.org</a></dd> </dl> </li> <li> <dl class="list-terms-minimal"> <dt>We are open</dt> <dd>Mn-Fr: 10 am-8 pm</dd> </dl> </li> </ul> </div>
Prawie. Tak,
dl
się tu przyda, ale jedno i bez wpakowania w listę. Widziałbym to raczej tak:<div class="cell-xs-10 cell-sm-6 cell-md-4 cell-lg-3"> <h6>Contacts</h6> <address> <dl> <dt>Address</dt> <dd>4578 Marmora Road, Glasgow, D04 89GR</dd> <dt>Phones</dt> <dd> <a href="callto:#">(800) 123-0045</a> </dd> <dd> <a href="callto:#">(800) 123-0045</a> </dd> <dt>E-mail</dt> <dd><a href="mailto:#">info@demolink.org</a></dd> <dt>We are open</dt> <dd>Mn-Fr: 10 am-8 pm</dd> </dl> </address> </div>
- Bardzo przeszkadza też wymieszanie konwencji nazewniczych w kodzie. Jak już wdepnęliśmy w BS-a, to róbmy po ichniejszemu (albo przepiszmy to na własne klasy, wykorzystując mixiny), a nie pchajmy nagle BEM.
- A w pliku JS pełno zmiennych globalnych. W erze ES6 i modularyzacji takie rzeczy należy po prostu piętnować.
Kolejny szablon od TM, kolejny raz dokładnie ten sam dylemat: od strony „normalnego” użytkownika końcowego to jest po prostu wow, cud, miód, orzeszki: kreator, miliard kombinacji wyglądu, grafiki, PSD, fonty… No wszystko, po prostu wszystko. Od strony takiego użytkownika końcowego jak ja jest za to ładny, schludny wygląd, ale pod spodem wciąż taki sam burdel jaki był wcześniej… A szkoda.