Szablon Osam

Dzisiaj przyjrzymy się bliżej kolejnemu szablonowi od Template Monster, tym razem przeznaczonemu dla panelów administracyjnych – Osam.

Szablon dostałem do oceny dzięki uprzejmości Template Monster.

Ogólne uwagi

• Do szablonu dołączona jest dokładna dokumentacja wraz ze wszystkimi użytymi obrazkami i skryptami. Duży plus za to.

• Szablon imponuje mnogością dostępnych komponentów: kalendarze, rozsuwane menu, animowane przyciski, wykresy, edytory WYSIWYG (w tym jedyny i niepowtarzalny CKEditor 4!), Bootstrap… Słowem wszystko, co ktoś mógłby chcieć od tego typu szablonu. I sporo, sporo więcej. Tu naprawdę jest wszystko – i to skomponowane w spójną całość. I za to naprawdę duży szacun.

  Oczywiście nie byłbym sobą, gdybym nie miał żadnego „ale”: taka mnogość opcji sprawia, że panel wczytuje na start bardzo sporą ilość JS-a, co sprawia, że całość jest dość ciężka.

• Bardzo podoba mi się fakt, że szablon zawiera praktycznie wszystkie podstrony potrzebne do stworzenia aplikacji opartej na takim panelu: rejestracja, logowanie, sam panel, przykładowe czy wbudowane aplikacje (jak cały klient pocztowy!). Na dobrą sprawę większość rzeczy można stworzyć kopiując kod z przykładowych stron, co znacząco przyśpieszy pracę.

• Nie bardzo rozumiem sens istnienia osobnego wariantu fluid. Jego nazwa wskazywałaby na to, że jako jedyny jest w pełni responsywny, niemniej nie jest to prawdą. Wszystkie warianty wyglądają podobnie na małych ekranach (nie licząc wariantu hmenu, na którym pokazuje się dodatkowy, poziomy pasek przewijania).

Landing

• Szablon nie przestrzega ustawień użytkownika w zakresie ograniczenia ruchu. Mimo włączenia tego ustawienia, wszelkie animacje pojawiania się i poruszania się elementów wciąż są obecne. W chwili popularyzacji prefers-reduced-motion urasta to do miana dość sporego niedopatrzenia.

• Dodatkowo sposób przygotowania strony do animowania sprawia, że treść ta staje się niedostępna dla użytkowników czytników ekranowych czy robotów sieciowych. Cała treść jest bowiem ukryta przy pomocy visibility: hidden. To sprawia, że np. użytkownik czytnika ekranowego nie będzie w stanie przeskakiwać pomiędzy kolejnymi nagłówkami na stronie.

• Pozycje w menu ani nie zmieniają adresu strony, poprzez dodanie hasha, ani nie przenoszą focusu do sekcji, do której następuje przewinięcie. To sprawia, że np. przejście do formularza kontaktowego przy pomocy klawiatury wymaga i tak przejścia przez całą stronę.

• Część elementów na stronie nie ma widocznego focusu, przez co czasami trudno się zorientować, gdzie obecnie jesteśmy na stronie. Jest to specjalnie widoczne w sekcji Our team, w której linki do profilów pracowników w sieciach społecznościowych pokazywane są wyłącznie po najechaniu myszką Ten problem można obecnie łatwo rozwiązać, wykorzystując :focus-within.

• Przyciski na stronie nie posiadają żadnego efektu powiązanego z kliknięciem, co sprawia, że wyglądają na niedziałające.

• Część tekstu ma zdecydowanie za niski kontrast w stosunku do tła, jak np. tekst w stopce.

• Część obrazków (np. ikonki w sekcji cennika) są pozbawione atrybutu [alt], przez co część czytników ekranowych przeczyta zamiast niego adres obrazka.

• Formularzowi brakuje label. Dodatkowo obecna walidacja nie jest w pełni dostępna. Błędy powinny być przypięte do pól przy pomocy [aria-describedby], a same pola na start oznaczone jako poprawne przez [aria-invalid=false] (puste pola z [required] są z automatu traktowane jako niepoprawnie wypełnione).

Panel

• Podobnie jak landing, panel również nie respektuje preferencji użytkownika względem ograniczenia animacji.

• Ciemny wariant panelu administracyjnego ma bardzo poważne problemy z kontrastem. Niemal cały tekst znajdujący się w nim jest praktycznie nieczytelny z powodu swojego niskiego kontrastu.

• Dodatkowo ciemny wariant można by obecnie rozegrać przy pomocy nowego media query, prefers-color-scheme.

• Nie jestem zwolennikiem preloaderów. Przy obecnych możliwościach optymalizacji aplikacji internetowych (HTTP/2 z server pushem, preloading zasobów, requestIdleCallback, możliwość doczytywania modułów w tle…) nie są potrzebne. Można tak zaprojektować aplikację, żeby wczytywała się na tyle szybko, żeby preloader nie był potrzebny.

• Bardzo dużo przycisków jest zrobionych przy pomocy a[href=javascript:void()]. To sprawia, że technologia asystująca nie jest w stanie poprawnie rozpoznać takich elementów jako przyciski, mylnie identyfikując je jako linki. Równocześnie takie zastosowanie linków sprawia, że obniżane jest bezpieczeństwo całego panelu, bo wyklucza użycie rygorystycznego CSP.

• Niektóre informacje są pozbawione odpowiedniego kontekstu dla technologii asystującej, np. etykiety z liczbą wiadomości. Sama liczba może nie być zrozumiała, stąd warto dodać odpowiednią informację:

  <a href="app-inbox.html">
  	<i class="icon-envelope"></i>
  	<span>Email</span>
  	<span class="badge badge-default float-right mr-0">12 <span class="sr-only">e-mails</span></span>
  </a>

• Niektórym elementom brakuje dodatkowych informacji o ich stanie, np. nie wszystkie rozsuwane elementy są oznaczane przy pomocy [aria-expanded].

Szablon imponuje swoją złożonością i liczbą elementów. Duży plus także za dokumentację. Głównym zarzutem jednak, który dyskwalifikuje ten szablon do moich zastosowań, jest fakt, że nie jest dostępny. Bez wprowadzenia niezbędnych poprawek nie zastosowałbym go. Poza tym (sporym) zastrzeżeniem szablon wygląda na kawał porządnej roboty. No, może jeszcze lekko stonować niektóre, zbyt bombastyczne animacje…