Lab98.pl

Dawno już nic nie pisałem, więc wypada to nadrobić. Tym razem przyjrzę się stronie Lab98.pl, która jest portfolio młodego i ambitnego zespołu z Wrocławia.

• Pierwszym testem, który zazwyczaj wykonuję, jest otwarcie strony w Firefoksie z włączonym dodatkiem NoScript. Niestety, coraz więcej stron całkowicie ten test oblewa. Nie inaczej jest i tym razem. Jest to tym bardziej dziwne, że nie ma absolutnie żadnych podstaw, aby ta strona nie działała bez JS – zwłaszcza, że mówimy tutaj o stronie w pełni informacyjnej, która JS używa wyłącznie do… bombastycznych efektów specjalnych. Cóż, jeśli powodem niedziałania strony bez JS jest całkowicie zbędna animacja wjazdu treści, to jest to po prostu zrobione źle. Przy minimalnym nakładzie środków (przerzucenie przypięcia animacji do JS i dodanie klasy .no-js) można to zrobić w sposób całkowicie dostępny.

• Kolejnym niezwykle dziwnym zjawiskiem jest… przycisk otwierający menu, który wygląda i zachowuje się inaczej w różnych przeglądarkach. W Firefoksie jest pionowy z animacją do trójkątnego kształtu, natomiast w Chrome jest poziomy z animacją lekko rozszerzającą kropki.

  Jeszcze innym ciekawym faktem związanym z menu jest ten, że nie zastosowano tutaj standardowego oznaczania menu, co może sprawić duży problem użytkownikom, szukającym tradycyjnego przycisku z „hamburgerem”. Zwłaszcza, że trzy kropki jakoś niespecjalnie nasuwają skojarzenia z menu.

• Samo otwarte menu również nie zachowuje się prawidłowo. Otwarcie menu nie powinno ucinać treści. Co więcej: offcanvas na stronie niemobilnej raczej wskazuje na fakt, że strona była projektowana bez uwzględnienia miejsca na menu, które w tym wypadku jest ewidentnie wepchnięte na chama.

• Chociaż strona po otwarciu prezentuje się w widoku SPA, to już kliknięcie dowolnego odnośnika w menu ukrywa całą stronę, pozostawiając wyłącznie wybraną sekcję. Co więcej, są sekcje dostępne wyłącznie z menu/innych linków, które nie są uwzględnione w „widoku SPA”. Zatem ta strona nie jest SPA.

  Niemniej architektura linków została zaprojektowana właśnie pod SPA, przy użyciu hashy, nie zaś pełnoprawnych URL-ów. Żeby było śmieszniej, poszczególne projekty w portfolio są źle zalinkowane (do wszystkich odsyła ten sam hash #project). Wszystko to razem wzięte powoduje, że do strony praktycznie nie da się linkować. Mam wrażenie, że autorzy za bardzo chcieli zrobić aplikację i zapomnieli, że piszą dla Sieci.

  Jakie jest moim zdaniem idealne rozwiązanie tego problemu? Przestać udawać, że pisze się SPA i zrobić normalną stronę (która sprawdza się w 98% przypadków) – zwłaszcza, że i tak do niektórych sekcji prowadzi wyłącznie menu/link. Bombastyczne efekty przejścia można po prostu wywalić, a jak już chcemy je mieć – zrobić lepiej, przy pomocy History API. Dzięki temu dla Ajaksa będzie można serwować same dane strony (która będzie składana na kliencie) a dla reszty – serwować całą stronę. Wymaga to naprawdę prostego skryptu w backendzie, ale sprawi, że strona będzie działać naprawdę wszędzie… i będzie miała prawdziwe URL-e (czyli to, co decyduje o tym, że Sieć jest Siecią).

• Żeby było jeszcze śmieszniej, menu jest dostępne z klawiatury nawet wówczas, gdy jest zamknięte i niewidoczne na ekranie. To bardzo duży błąd usability i accessibility!
• I jeszcze jedna ciekawa rzecz o menu: przy mojej rozdzielczości (1366×768) w Chrome ostatnia pozycja menu jest poza ekranem (odkryłem ją wyłącznie przez przypadek, używając klawiatury).
• Nie umiem skończyć o tym menu… Strzałka w prawo za linkiem do aktualnie wyświetlanego fragmentu strony to raczej średni znacznik aktywnego linka. Prawdę mówiąc wziąłem to za przycisk zamknięcia menu (strzałka przejścia do treści)… który nie istnieje. Muszę jechać myszką na drugi koniec strony (do przycisku otwierania menu), by zamknąć menu. Trochę to nieintuicyjne.
• Jeszcze jedna ciekawa rzecz odnośnie menu: jeśli coś znajduje się w tej samej linii, co logo i przycisk otwierający menu, staje się nieklikalne (niewidoczny topbar to przykrywa).

• Ogólnie nawigacja po stronie klawiaturą jest źle zaimplementowana. Po przejechaniu niewidocznego menu mój Tab ugrzązł w… niewidocznym panelu FB. To, czego nie widać, nie ma prawa kraść focusa!

  Jakby tego było mało, przeważająca część elementów interaktywnych (jak choćby przyciski w sekcji Jak działamy?) są niedostępne z poziomu klawiatury – co jest podstawowym błędem dostępności! Natomiast reszta elementów interaktywnych jest pozbawiona outline’u, co sprawia, że nie wiadomo, gdzie znajduje się focus. Strona z góry zakłada, że użytkownik będzie w pełni sprawny i/lub posiadał urządzenie wyposażone w mysz (lub inne urządzenie wskazujące). A to po prostu pobożne życzenie.

• A wracając do menu… Znajdują się tam linki do szablonów briefów, które są w formacie .doc. Utarło się, że standardowym formatem wymiany dokumentów w Sieci jest .pdf (choćby z powodu samej nazwy – Portable Document Format). Czemu nie .doc? Bo on jest niekompatybilny nawet między różnymi wersjami Microsoft Office.

  A tak na marginesie: plik tekstowy zawierający 15 prostych pytań odnośnie strony waży 2 MB?

• Co do samego briefu: na samym początku znajduje się zwrot do klienta na Ty:

  Prosimy o odpowiedź na pytania poniżej, które dadzą nam podgląd na Twoje oczekiwania dotyczące projektu.

  Natomiast już w 1. pytaniu nastepuje przeskok do formy Państwo:

  Czym zajmuje się Państwa firma i jaki cel chcą Państwo osiągnąć dzięki nowej stronie internetowej?

  Jak dla mnie jest pewnego rodzaju faux pas rozpoczęcie kontaktu z klientem na Ty a później przeskok do formy Państwo. Albo cały czas jesteśmy totalnymi luzakami, albo cały czas jesteśmy kulturalni – taki przeskok raczej nie jest w dobrym tonie.

• Sam kontrast poszczególnych sekcji strony (a zwłaszcza formularza kontaktowego) jest po prostu tragiczny. Osoby ze słabszym wzrokiem (np. ja) nie mają szans przeczytać tekstu. Jasnozielony (i w dodatku małą, chudą czcionką fontem) na białym? Nie widzę. Polecam poczytać zalecenia WCAG 2.0 odnośnie kontrastu wizualnego.

• Pobawiłem się też chwilę formularzem kontaktowym i walidacja jest totalnie źle zaimplementowana. Zachodzi wyłącznie po próbie wysłania formularza i sprawdza po jednym polu. W najgorszym wypadku zatem będę musiał poprawiać formularz 5 razy.

  Co więcej, sama walidacja również pozostawia wiele do życzenia. ≠²¢ okazuje się być poprawnym imieniem i nazwiskiem, a -1 – poprawnym numerem telefonu.

  Żeby było jeszcze zabawniej, nie wiadomo jaki błąd się popełniło. W chwili wystąpienia błędu, pojawia się jedynie ikonka przy odpowiednim polu, która nie dostarcza żadnych informacji (choćby w postaci głupiego dymka).

• Przejdźmy w końcu do kodu. Tradycyjnie zaczniemy od walidacji, która nie zachwyca. Natomiast wyniki z PageSpeed są zdecydowanie lepsze.
• Plus za poprawne zastosowanie html[lang]. Mimo wszystko wciąż jest to dość rzadkie.
• meta[name=viewport] nie zezwala na skalowanie strony. To błąd! Zawsze się może bowiem zdarzyć, że jakiś użytkownik nie będzie czegoś widział i zechce powiększyć stronę. Blokada skalowania strony przydaje się tylko w przypadku bardzo specyficznego typu aplikacji webowych (gdzie interfejs jest dostosowany w sposób perfekcyjny do użytkownika). W przypadku stron, których podstawową funkcją jest dostarczanie informacji, design jest zawsze mniej ważny od przekazywanej treści.
• link[rel="shortcut icon"] można spokojnie zamienić na link[rel=icon]. A jak już się faktycznie chcemy w to bawić, to dostarczmy wszystkie potrzebne ikonki.
• Własny arkusz stylów należy dołączać na końcu. Inaczej narażamy się na możliwoć nadpisania naszych stylów przez style o tej samej specyficzności, znajdujące się w innych arkuszach stylów.
• I tu ciekawostka: wygląda na to, że na serwerze produkcyjnym znajdują się też wersje developerskie plików. Wystarczy wyrzucić .min z nazwy arkusza stylów, by dobrać się do niezminifikowanej wersji arkusza. To nie powinno mieć miejsca.
• script[async]:not([src]) nie ma żadnego sensu. Atrybut [async] określa bowiem sposób, w jaki przeglądarka ma wczytać i uruchomić zewnętrzny skrypt. W przypadku skryptów inline wykonanie zawsze odbywa się tu i teraz.
• Menu to nieodpowiednie miejsce na logo.

• <li data-page="main" class="nav-btn">
  	<a href="#main" class="menu-item-link">strona główna</a>
  	<img class="menu-active-img" alt="active-item" src="images/hover.jpg">
  </li>

  Odnoszę wrażenie, że w Polsce nie istnieje jakakolwiek świadomość spraw związanych z dostępnością. Tym sposobem czytniki ekranowe do każdego linka w menu dostają bezsensowny obrazek z nic niemówiącym atrybutem [alt] – zwłaszcza, że przy „nieaktywnych” elementach menu te obrazki nie są ukryte (jedynie wypozycjonowane poza ekran).

• ul > hr najlepiej zamienić na li::after lub pusty li[role=separator].

• <a href="brief/brief_strona.doc" class="menu-item">
  	<figure class="download-ico">
  		<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" x="0px" y="0px" width="537.794px" height="537.795px" viewBox="0 0 537.794 537.795" style="enable-background:new 0 0 537.794 537.795;" xml:space="preserve">
  			<g>
  				<path d="M463.091,466.114H74.854c-11.857,0-21.497,9.716-21.497,21.497v28.688c0,11.857,9.716,21.496,21.497,21.496h388.084    c11.857,0,21.496-9.716,21.496-21.496v-28.688C484.665,475.677,474.949,466.114,463.091,466.114z"/>
  				<path d="M253.94,427.635c4.208,4.208,9.716,6.35,15.147,6.35c5.508,0,11.016-2.142,15.147-6.35l147.033-147.033    c8.339-8.338,8.339-21.955,0-30.447l-20.349-20.349c-8.339-8.339-21.956-8.339-30.447,0l-75.582,75.659V21.497    C304.889,9.639,295.173,0,283.393,0h-28.688c-11.857,0-21.497,9.562-21.497,21.497v284.044l-75.658-75.659    c-8.339-8.338-22.032-8.338-30.447,0l-20.349,20.349c-8.338,8.338-8.338,22.032,0,30.447L253.94,427.635z"/>
  			</g>
  		</svg>
  	</figure>
  	<span></span>
  	Brief - strona www
  </a>

  W tym elemencie ikonka jest jedynie ozdobnikiem, zatem figure całkowicie tutaj nie pasuje. To nie jest samodzielny obrazek! Co więcej, jestem przekonany, że pusty span można z powodzeniem zamienić na ::before

• nav > footer? Stopka nawigacji? Pierwsze słyszę.
• Czemu przycisk do otwierania menu jest otoczony nav? To nie jest element nawigacyjny.
• Jeśli jedyną treścią przycisku jest obrazek (normalny czy SVG) lub kilka pustych elementów (ikonek), to dany przycisk musi mieć tekstową treść alternatywną dla czytników ekranowych. Do tego służy w Bootstrapie klasa .sr-only, która gdzie indziej znana jest pod pierwotną nazwą .visuallyhidden.

• <article class="main">
  	<section class="module slogan">
  		<figure class="triangle-container">
  			<img src="images/triangle.png" class="triangle" alt="trojkat">
  		</figure>
  		<figure class="parallax">
  			<img src="images/bird_top.png" class="bird-top" alt="ptak">
  			<img src="images/bird_bottom.png" class="bird-bottom" alt="ptak">
  			<img src="images/triangle_blur.png" class="triangle-blur" alt="trojkat">
  		</figure>
  		<header>
  			<h1 class="slogan-title">Design <br> w formie.</h1>
  			<hr class="slogan-separator">
  		</header>
  	</section>
  	[…]
  </article>

  Ten kod aż roi się od błędów:

  • h1 powinno być zarezerwowane wyłącznie dla głównego nagłówka strony. Jeśli spojrzymy na aktualny outline strony, to zobaczymy, że strona zwie się „Design w formie”. Raczej nie o to chodziło.
  • Co więcej, wsadzenie tego nagłówka w section powoduje, że article.main zostaje pozbawione nagłówka, co przeczy sensowi tworzenia artykułu… który i tak nie musi istnieć, bo jest wsadzony w main.
  • Wszystkie obrazki w .module.slogan są pozbawionymi semantyki ozdobnikami, więc nie mają prawa być w figure i mieć niepustych atrybutów [alt]!
  • Cała sekcja jest tak naprawdę… nagłówkiem artykułu (zawartość section > header) to potwierdza.
  • hr nie jest separatorem wizualnym a semantycznym! Stąd tutaj nie pasuje. Tutaj pasuje po prostu h1::after.
  • Tak po prawdzie użycie br wiąże treść strony z konkretnym designem. Gdy design się zmieni, trzeba będzie zmieniać treść.
• W Naszych pasjach poszczególne div z nagłówkami mogą być spokojnie section.

• <img class="module-ico" src="images/service_1.png" alt="webdesing">
  <h3 class="module-subtitle">Webdesign</h3>

  Widać wyraźnie, że obrazek duplikuje treść z nagłówka. Z tego też powodu powinien mieć pusty [alt]. Tym samym czytniki ekranowe nie będą czytać dwa razy tego samego.

• Powyższe uwagi dotyczą de facto wszystkich sekcji na stronie.

• <section class="module portfolio-small">
  	<figure class="tile main-tile">
  		<h2 class="module-title">Portfolio</h2>
  		<hr class="separator">
  		<a href="#portfolio" data-page="portfolio" class="nav-btn full-portfolio-btn">Zobacz całe portfolio<span></span></a>
  	</figure>
  	<figure class="tile">
  	</figure>
  	<figure class="tile">
  	</figure>
  	<figure class="tile">
  	</figure>
  	<figure class="tile">
  	</figure>
  	<figure class="tile">
  	</figure>
  	<figure class="tile">
  	</figure>
  	<figure class="tile">
  	</figure>
  	<figure class="tile">
  	</figure>
  </section>

  Całkowicie bezsensowny kod… Jeśli to szablon, to od tego jest choćby template.

• <button class="filtr-button">
  	<p class="filtr-box-selected">Wybierz typ projektu...</p>
  	<img src="images/filtr-arrow-down.png" alt="strzalka">
  </button>

  Ten atrybut [alt] jest po prostu tragiczny… Tutaj znów mamy do czynienia z ozdobnikiem, który nie wnosi żadnej wartości dodanej – a więc ten atrybut powinien być pusty!

• <figure class="contact-data">
  	<img src="images/coding_sign.png" class="contact-data-ico" alt="coding sign">
  	<h3 class="module-subtitle">Sławomir Przybylski</h3>
  	<p class="module-subtext">+48 698 169 393</p>
  	<p class="module-subtext">s.przybylski@lab98.pl</p>
  	<p class="module-subtext-heading">zalecam kontakt w godz.:</p>
  	<p class="module-subtext">14:00 - 21:00</p>
  </figure>

  Danych adresowych nijak się nie da pogodzić z figure. Tutaj najlepiej byłoby zastosować address > dl + mikrodane ze słownika Schema.org (jak np. na mojej stronie domowej).

  Co do obrazka: znów mamy do czynienia z ozdobnikiem, więc jedyny słuszny [alt] to pusty [alt]!

• <article class="review visible-review">
  	<img src="reviews-logo/opal.png" class="review-logo">
  	<p class="review-text">Podjęłam wspólpracę z chłopakami z Lab98. i jestem bardzo zadowolona. Bezproblemowy kontakt oraz szybka rekacja na potrzeby klienta to wielkie plusy. Strona, którą stworzyli jest czytelna i estetyczna co pozwoli mi pozyskać nowych klientów. Polecam.</p>
  	<p class="review-signature">Anna Świder</p>
  </article>

  Kolejny fragment, który jest de facto w całości źle:

  • Obrazek nie ma atrybutu [alt]! Tutaj powinien być nim nazwa firmy.
  • Rekomendacja to cytat – zatem powinna być oznaczona jako cytat!

  Ten kod powinien wyglądać mniej więcej tak:

  <blockquote>
  	<cite>
  		<img src="reviews-logo/opal.png" class="review-logo" alt="EkoOpał">
  	</cite>
  	<p class="review-text">Podjęłam wspólpracę z chłopakami z Lab98. i jestem bardzo zadowolona. Bezproblemowy kontakt oraz szybka rekacja na potrzeby klienta to wielkie plusy. Strona, którą stworzyli jest czytelna i estetyczna co pozwoli mi pozyskać nowych klientów. Polecam.</p>
  	<cite class="review-signature">Anna Świder</cite>
  </blockquote>

  Podwójne cite jest tutaj, by zaznaczyć, że autorem rekomendacji jest konkretna firma (cite > img) a równocześnie – osoba (cite.review-signature).

• Inna rzecz, że rekomendacja typu:

  A piszcie sobie co tam chcecie, ja się podpisuje.

  raczej podważa sens rekomendacji…

• <div class="copy-sender">
  	<button class="copy-checkbox"></button>
  	<p class="copy-sender-text">Wyślij kopię wiadomości na maila</p>
  </div>

  Bezsensowna atrapa checkboxa! Zwłaszcza, że checkboxa można ładnie ostylować (dzięki sztuczce z :checked + label).

• <div class="main-field-container">
  	<input type="text" class="main-field" name="name" placeholder="Imię i nazwisko">
  	<img class="field-alert" src="images/form_error.png">
  </div>

  Całkowicie źle zrobiony formularz! Obrazek błędu jest zawsze widoczny dla czytników ekranowych. Co gorsza, nie ma atrybutu [alt]. Jeśli tego mało, to dodatkowo pole formularza nie ma label! Żeby było jeszcze śmieszniej, to dla czytnika ekranowego obrazek nie jest w żaden sposób związany z polem. Wszystkie podstawowe błędy dostępności w trzech liniach kodu…

  Jak to powinno wyglądać?

  <div class="main-field-container">
  	<label class="visuallyhidden" for="name">Imię i nazwisko</label>
  	<input type="text" class="main-field" name id="name" placeholder="Imię i nazwisko">
  </div>

  Natomiast po popełnieniu błędu w polu:

  <div class="main-field-container">
  	<label class="visuallyhidden" for="name">Imię i nazwisko</label>
  	<input type="text" class="main-field main-field--invalid" name id="name" placeholder="Imię i nazwisko" aria-invalid="true" aria-describedby="name-error">
  	<p id="name-error">Imię i nazwisko musi składać się z co najmniej 3 liter.</p>
  </div>

  Gdzie obrazek? Doczepiany jako tło dla pola z klasą .main-field--invalid.

• <figure class="employee-interest">
  	<img class="module-ico" src="images/employee_fantasy.png" alt="fantasy">
  	<h3 class="module-subtitle">fantasy</h3>
  	<p class="description">Od wielu lat pasjonuje się szeroko pojętą fantastyką, od grania w MTG i brania udziału w sesjach RPG.<p>
  </figure>

  To są sekcje, nie samodzielne semantyczne załączniki do treści. Oczywiście wymienione wcześniej uwagi tyczą się także i tego fragmentu kodu.

• Przejdźmy do kodu JS, do pliku main.js (tak, na serwerze leży wersja niezminifikowana). Od razu widać, że są jakieś problemy z kodowaniem polskich znaków:

  SĹ‚awomir Przybylski

• Dodatkowo dostajemy również zmienne globalne:

  var briefVisible = false;
  var facebookVisible = false;
  var disableContact = false;
  var menuMobile = false;
  var checkbox = 'unsend';

  W dobie de facto całkowitej modularyzacji JS-a i szerokiej popularności technik zapewniających hermetyzację kodu JS, zmienne globalne nie mają prawa bytu.

• Analiza pliku JS wskazuje także, że nie da się skontaktować z autorami bez włączonego JS-a – formularz bowiem jest na chama wysyłany z poziomu kodu JS. Sam skrypt backendowy obsługujący wysyłkę z kolei… zwraca pojedynczy błąd lub komunikat sukcesu. Sama obsługa błędów sprowadza się z kolei do dopasowywania konkretnych komunikatów błędów do pól.

  Dobrze zaprojektowany formularz powinien mieć poprawne atrybuty [action] i [method], a samo wysyłanie Ajaksem powinno się opierać na nadpisaniu zdarzenia submit. Natomiast serwer powinien zwracać odpowiedź w formacie JSON zawierającą identyfikator pola oraz komunikat błędu. Tym samym całą walidację można przeprowadzić od razu, przy o wiele mniejszej ilości kodu JS i – co najważniejsze – użyć tego kodu do jakiegokolwiek formularza.

• Przechodząc do kodu CSS i porównując wersję zminifikowaną z developerską, można rzec, że wykorzystują Autoprefixer. Bardzo dobrze!
• Równocześnie jest wykorzystywana stara wersja resetu Meyera, z wciąż obecną całkowicie niezrozumianą regułą outline: none.

• .outline {
  	position: absolute;
  	clip: rect(0px 0px 0px 0px);
  	*clip: rect 0 0 0 0; }

  Wygląda to na bardzo ubogą wersję .visuallyhidden, która może źle działać w przeglądarkach opartych na Blinku. Co więcej, ten kod zawiera hack na martwe od lat wersje Internet Explorera.

Kolejna strona, która robi bardzo dobre pierwsze wrażenie, które niestety bardzo szybko pryska. A szkoda.